Skip to main content

JavaScript Object Notation (JSON) Text Sequences
draft-ietf-json-text-sequence-13

Revision differences

Document history

Date Rev. By Action
2015-02-20
13 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-02-11
13 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-01-28
13 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-01-12
13 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-01-12
13 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2015-01-12
13 (System) IANA Action state changed to In Progress from Waiting on Authors
2015-01-08
13 (System) IANA Action state changed to Waiting on Authors
2015-01-08
13 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-01-08
13 (System) RFC Editor state changed to EDIT
2015-01-08
13 (System) Announcement was received by RFC Editor
2015-01-08
13 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2015-01-08
13 Cindy Morgan IESG has approved the document
2015-01-08
13 Cindy Morgan Closed "Approve" ballot
2015-01-08
13 Cindy Morgan Ballot approval text was generated
2015-01-08
13 Pete Resnick IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2015-01-08
13 Richard Barnes [Ballot Position Update] Position for Richard Barnes has been changed to No Objection from Discuss
2014-12-23
13 Nicolás Williams New version available: draft-ietf-json-text-sequence-13.txt
2014-12-19
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-12-19
12 Nicolás Williams IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-12-19
12 Nicolás Williams New version available: draft-ietf-json-text-sequence-12.txt
2014-12-18
11 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Carl Wallace.
2014-12-18
11 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2014-12-18
11 Barry Leiba
[Ballot comment]
I've asked that the media type registration request be posted to the media-types@iana.org list for comment.  That's been done, and there's been a …
[Ballot comment]
I've asked that the media type registration request be posted to the media-types@iana.org list for comment.  That's been done, and there's been a little discussion that's resulted in some suggestions for a couple of minor changes, but nothing major.  I consider this point cleared, knowing that the minor changes are coming.
2014-12-18
11 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2014-12-18
11 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-12-17
11 Alia Atlas [Ballot comment]
I see others have noticed the glaring typo (0x1E for LF) in the abstract...
2014-12-17
11 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2014-12-17
11 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-12-17
11 Richard Barnes
[Ballot discuss]
Section 2.4.: The logic for having a terminator character here seems pretty fishy to me.  Can you explain the scenario in which this …
[Ballot discuss]
Section 2.4.: The logic for having a terminator character here seems pretty fishy to me.  Can you explain the scenario in which this setup actually results in truncated texts being detected?  What is the piece of software that recognizes the truncation and chooses to omit the terminator?  It seems like in the obvious design (source of JSON texts feeding into sequence encoder), you just end up with (RS  LF) anyway.  In order for this not to be the case, you need to have something in front of the sequence encoder that recognizes truncation and signals it to the encoder

Section 2.4.: If you're going to have a terminator character, why 0x0A in particular?  That character is valid in JSON texts, so using that as a terminator requires special processing on the JSON texts.  As with the above, this seems to require an architecture in which the source of JSON texts cannot be independent of the sequence encoder (which kind of defeats the purpose of this supposedly lightweight sequence encoding).
2014-12-17
11 Richard Barnes [Ballot comment]
Section 2.2.: "textm"
2014-12-17
11 Richard Barnes [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes
2014-12-16
11 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-12-16
11 Ted Lemon
[Ballot comment]
I'm not going to raise this as a DISCUSS because I'm on vacation and can't respond, but I am a bit concerned by …
[Ballot comment]
I'm not going to raise this as a DISCUSS because I'm on vacation and can't respond, but I am a bit concerned by the following text in the document:

  Multiple consecutive RS octets do not denote empty sequence elements
  between them, and can be ignored.

The concern I have is that this document appears to suggest that a large dataset can be transferred as a series of json text sequences.  But nowhere in the document (that I noticed) is it explained how each chunk of text is identified.  It could be that they do not need to be identified: that each chunk stands alone.  But suppose you are transferring array elements, rather than database tuples.  In order to avoid a mis-count, it would have to be the case that each tuple contains the index of the array element that it represents.

I suspect that the intention is actually that these sequences never be used this way, but it would be nice to state that explicitly, e.g. something like this:

  This document does not define a mechanism for reliably identifying
  text sequence by position (for example, when sending individual
  elements of an array as unique text sequences.  Each json text
  sequence should therefore contain sufficient information that
  it is meaningful regardless of the order in which it appears
  in a stream of text sequences.
2014-12-16
11 Ted Lemon Ballot comment text updated for Ted Lemon
2014-12-16
11 Ted Lemon
[Ballot comment]
I'm not going to raise this as a DISCUSS because I'm on vacation and can't respond, but I am a bit concerned by …
[Ballot comment]
I'm not going to raise this as a DISCUSS because I'm on vacation and can't respond, but I am a bit concerned by the following text in the document:

  Multiple consecutive RS octets do not denote empty sequence elements
  between them, and can be ignored.

The concern I have is that this document appears to suggest that a large dataset can be transferred as a series of json text sequences.  But nowhere in the document (that I noticed) is it explained how each chunk of text is identified.  It could be that they do not need to be identified: that each chunk stands alone.  But suppose you are transferring array elements, rather than database tuples.  In order to avoid a mis-count, it would have to be the case that each tuple contains the index of the array element that it represents.

I suspect that the intention is actually that these sequences never be used this way, but it would be nice to state that explicitly, e.g. something like this:

  This document does not define a mechanism for reliably identifying         
  text sequence by position (for example, when sending individual
  elements of an array as unique text sequences.  Each json text             
  sequence should therefore contain sufficient information that
  it is meaningful regardless of the order in which it appears               
  in a stream of text sequences.
2014-12-16
11 Ted Lemon Ballot comment text updated for Ted Lemon
2014-12-16
11 Ted Lemon
[Ballot comment]
I'm not going to raise this as a DISCUSS because I'm on vacation and can't respond, but I am a bit concerned by …
[Ballot comment]
I'm not going to raise this as a DISCUSS because I'm on vacation and can't respond, but I am a bit concerned by the following text in the document:

  Multiple consecutive RS octets do not denote empty sequence elements
  between them, and can be ignored.

The concern I have is that this document appears to suggest that a large dataset can be transferred as a series of json text sequences.  But nowhere in the document (that I noticed) is it explained how each chunk of text is identified.  It could be that they do not need to be identified: that each chunk stands alone.  But suppose you are transferring array elements, rather than database tuples.  In order to avoid a mis-count, it would have to be the case that each tuple contains the index of the array element that it represents.

I suspect that the intention is actually that these sequences never be used this way, but it would be nice to state that explicitly, e.g. something like this:

  This document does not define a mechanism for reliably identifying text sequence
  by position (for example, when sending individual elements of an array as unique text
  sequences.  Each json text sequence should therefore contain sufficient information
  that it is meaningful independent of the order in which it appears in a stream of text
  sequences.
2014-12-16
11 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2014-12-16
11 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-12-15
11 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2014-12-15
11 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-12-15
11 Gunter Van de Velde Request for Telechat review by OPSDIR Completed: Ready. Reviewer: David Black.
2014-12-15
11 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to David Black
2014-12-15
11 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to David Black
2014-12-15
11 Pete Resnick Changed consensus to Yes from Unknown
2014-12-15
11 Stephen Farrell
[Ballot comment]


- abstract: 2nd 0x1E should be 0x0A I guess. That really
needs fixing so could well be a DISCUSS but is probably
so …
[Ballot comment]


- abstract: 2nd 0x1E should be 0x0A I guess. That really
needs fixing so could well be a DISCUSS but is probably
so obvious it'll happen without that:-) But let me know
if you prefer this be a DISCUSS for tracking purposes.

- 2.1 doesn't say anything about 0x00 which often creates
security issues. Worth a note? Not sure myself.

- 2.2: thanks for the  ctrl-^ info - that's good. Would it be
worth adding that in e.g. vim/vi you should precede that
ctrl-^ with ctrl-v so as to get the right value into your
file?

- 2.3: I think SHOULD NOT abort is too strong - did the wg
consider saying they SHOULD or MAY abort and giving the log
example as a counter example? It just seems safer to me if
the default behaviour is to abort. However, I'm not that
certain of this point, so this isn't a discuss.

- section 3: 2nd sentence, I think what you really should be
saying is that parsing one of these does not necessarily give
you a good input to a MAC or signature verification process
as you might or might not still have canonicalisation issues.

- section 3: I think you ought mention the potential here for
careless code to be vulnerable to buffer overruns. We've seen
that too often to ignore it I'd argue.

- Most of the above plus a few others are also noted in
the secdir review [1]. I'm sure the author/shepherd/AD
will engage with the reviewer there too.

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05300.html
2014-12-15
11 Stephen Farrell Ballot comment text updated for Stephen Farrell
2014-12-15
11 Stephen Farrell
[Ballot comment]


- abstract: 2nd 0x1E should be 0x0A I guess. That really
needs fixing so could well be a DISCUSS but is probably
so …
[Ballot comment]


- abstract: 2nd 0x1E should be 0x0A I guess. That really
needs fixing so could well be a DISCUSS but is probably
so obvious it'll happen without that:-) But let me know
if you prefer this be a DISCUSS for tracking purposes.

- 2.1 doesn't say anything about 0x00 which often creates
security issues. Worth a note? Not sure myself.

- 2.2: thanks for the  ctrl-^ info - that's good. Would it be
worth adding that in e.g. vim/vi you should precede that
ctrl-^ with ctrl-v so as to get the right value into your
file?

- 2.3: I think SHOULD NOT abort is a too strong - did the wg
consider saying they SHOULD or MAY abort and giving the log
example as a counter example? It just seems safer to me if
the default behaviour is to abort. However, I'm not that
certain of this point, so this isn't a discuss.

- section 3: 2nd sentence, I think what you really should be
saying is that parsing one of these does not necessarily give
you a good input to a MAC or signature verification process
as you might or might not still have canonicalisation issues.

- section 3: I think you ought mention the potential here for
careless code to be vulneable to buffer overruns. We've seen
that too often to ignore it I'd argue.

- Most of the above plus a few others are also noted in
the secdir review [1]. I'm sure the author/shepherd/AD
will engage with the reviewer there too.

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05300.html
2014-12-15
11 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2014-12-15
11 Benoît Claise [Ballot comment]
Thanks for addressing the OPS-DIR review in a timely manner.
2014-12-15
11 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-12-13
11 Barry Leiba
[Ballot discuss]
I've asked that the media type registration request be posted to the media-types@iana.org list for comment, and we're still awaiting that... but Paul …
[Ballot discuss]
I've asked that the media type registration request be posted to the media-types@iana.org list for comment, and we're still awaiting that... but Paul has asked Nico to do that, and I'm confident that all will work out.  I'll clear this when the request has been posted and there's been some time for comment.
2014-12-13
11 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2014-12-12
11 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2014-12-12
11 Pete Resnick IESG state changed to IESG Evaluation from Waiting for Writeup
2014-12-12
11 Pete Resnick Ballot has been issued
2014-12-12
11 Pete Resnick [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick
2014-12-12
11 Pete Resnick Created "Approve" ballot
2014-12-12
11 Pete Resnick Ballot writeup was changed
2014-12-11
11 David Black Request for Last Call review by GENART Completed: Ready. Reviewer: David Black.
2014-12-11
11 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2014-12-11
11 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2014-12-11
11 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: David Black.
2014-12-11
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to David Black
2014-12-11
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to David Black
2014-12-11
11 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Withdrawn'
2014-12-11
11 Nicolás Williams New version available: draft-ietf-json-text-sequence-11.txt
2014-12-09
10 Nicolás Williams IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-12-09
10 Nicolás Williams New version available: draft-ietf-json-text-sequence-10.txt
2014-12-05
09 David Black Request for Last Call review by GENART Completed: On the Right Track. Reviewer: David Black.
2014-12-05
09 (System) IESG state changed to Waiting for Writeup from In Last Call
2014-11-28
09 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2014-11-28
09 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2014-11-27
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Carl Wallace
2014-11-27
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Carl Wallace
2014-11-25
09 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2014-11-25
09 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-json-text-sequence-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-json-text-sequence-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there is a single action IANA must complete.

In the Application Media Type registry located at:

https://www.iana.org/assignments/media-types/

a new application media type will be registered as follows:

Name: json-seq
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.
2014-11-24
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mahalingam Mani
2014-11-24
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mahalingam Mani
2014-11-21
09 Pete Resnick Placed on agenda for telechat - 2014-12-18
2014-11-21
09 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-11-21
09 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (JavaScript Object Notation (JSON) Text …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (JavaScript Object Notation (JSON) Text Sequences) to Proposed Standard


The IESG has received a request from the JavaScript Object Notation WG
(json) to consider the following document:
- 'JavaScript Object Notation (JSON) Text Sequences'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-12-05. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the JSON text sequence format and associated
  media type, "application/json-seq".  A JSON text sequence consists of
  any number of JSON texts, each prefix by an Record Separator
  (U+001E), and each ending with a newline character (U+000A).


This document makes a normative downref to RFC 20.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ballot/


No IPR declarations have been submitted directly on this I-D.


2014-11-21
09 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-11-21
09 Pete Resnick Notification list changed to json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org from json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org
2014-11-21
09 Pete Resnick Last call was requested
2014-11-21
09 Pete Resnick Ballot approval text was generated
2014-11-21
09 Pete Resnick Ballot writeup was generated
2014-11-21
09 Pete Resnick IESG state changed to Last Call Requested from AD Evaluation::Point Raised - writeup needed
2014-11-21
09 Pete Resnick Last call announcement was changed
2014-11-21
09 Pete Resnick Last call announcement was generated
2014-10-27
09 Nicolás Williams New version available: draft-ietf-json-text-sequence-09.txt
2014-10-23
08 Nicolás Williams New version available: draft-ietf-json-text-sequence-08.txt
2014-10-19
07 Pete Resnick Waiting for response from WG.
2014-10-19
07 Pete Resnick IESG state changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation
2014-10-16
07 Pete Resnick IESG state changed to AD Evaluation from Publication Requested
2014-09-27
07 Paul Hoffman
Shepherd writeup for draft-ietf-json-text-sequence

1. Summary

Paul Hoffman (co-chair of the JSON WG) is the document shepherd, and Pete Resnick is the responsible
Area Director. …
Shepherd writeup for draft-ietf-json-text-sequence

1. Summary

Paul Hoffman (co-chair of the JSON WG) is the document shepherd, and Pete Resnick is the responsible
Area Director.

This document describes the JSON text sequence format. A JSON text sequence is specifically not a
JSON text itself, but it is composed of (possible) JSON texts.  JSON text sequences can be parsed
(and produced) incrementally without having to have a streaming parser (nor streaming encoder). This
allows easy coding of extremely large datasets, logs, and so on. Because it is a format, it is
appropriate for standards track.

2. Review and Consensus

The WG had some problems with early drafts of the document, but came to rough consensus at the end.
There was disagreement about what character(s) should be used to delimit text sequences, but there
was fairly extensive discussion and most of the participants agreed that the sequence chosen in the
latest draft is the best of the alternatives discussed.

There was not a huge amount of interest in the format in the WG, but there was definite interest
from some users of JSON, particularly those who want to write out JSON texts in logs.

3. Intellectual Property

The document author is unaware of any patents on the idea or trademarks on the name.

IPR on this draft was not discussed in the WG.

4. Other Points

There is an IANA consideration, requesting a new MIME media type, which looks pretty bog-standard.
2014-09-27
07 Paul Hoffman
Shepherd writeup for draft-ietf-json-text-sequence

1. Summary

Paul Hoffman (co-chair of the JSON WG) is the document shepherd, and Pete Resnick is the responsible
Area Director. …
Shepherd writeup for draft-ietf-json-text-sequence

1. Summary

Paul Hoffman (co-chair of the JSON WG) is the document shepherd, and Pete Resnick is the responsible
Area Director.

This document describes the JSON text sequence format. A JSON text sequence is specifically not a
JSON text itself, but it is composed of (possible) JSON texts.  JSON text sequences can be parsed
(and produced) incrementally without having to have a streaming parser (nor streaming encoder). This
allows easy coding of extremely large datasets, logs, and so on. Because it is a format, it is
appropriate for standards track.

2. Review and Consensus

The WG had some problems with early drafts of the document, but came to rough consensus at the end.
There was disagreement about what character(s) should be used to delimit text sequences, but there
was fairly extensive discussion and most of the participants agreed that the sequence chosen in the
latest draft is the best of the alternatives discussed.

There was not a huge amount of interest in the format in the WG, but there was definite interest
from some users of JSON, particularly those who want to write out JSON texts in logs.

3. Intellectual Property

[[ TBD, but I can't imagine that the author knows of any IPR on this. ]]

IPR on this draft was not discussed in the WG.

4. Other Points

There is an IANA consideration, requesting a new MIME media type, which looks pretty bog-standard.
2014-09-27
07 Paul Hoffman IETF WG state changed to Submitted to IESG for Publication from WG Document
2014-09-27
07 Paul Hoffman IESG state changed to Publication Requested from AD is watching
2014-09-27
07 Paul Hoffman
Shepherd writeup for draft-ietf-json-text-sequence

1. Summary

Paul Hoffman (co-chair of the JSON WG) is the document shepherd, and Pete Resnick is the responsible
Area Director. …
Shepherd writeup for draft-ietf-json-text-sequence

1. Summary

Paul Hoffman (co-chair of the JSON WG) is the document shepherd, and Pete Resnick is the responsible
Area Director.

This document describes the JSON text sequence format. A JSON text sequence is specifically not a
JSON text itself, but it is composed of (possible) JSON texts.  JSON text sequences can be parsed
(and produced) incrementally without having to have a streaming parser (nor streaming encoder). This
allows easy coding of extremely large datasets, logs, and so on. Because it is a format, it is
appropriate for standards track.

2. Review and Consensus

The WG had some problems with early drafts of the document, but came to rough consensus at the end.
There was disagreement about what character(s) should be used to delimit text sequences, but there
was fairly extensive discussion and most of the participants agreed that the sequence chosen in the
latest draft is the best of the alternatives discussed.

There was not a huge amount of interest in the format in the WG, but there was definite interest
from some users of JSON, particularly those who want to write out JSON texts in logs.

3. Intellectual Property

[[ TBD, but I can't imagine that the author knows of any IPR on this. ]]

IPR on this draft was not discussed in the WG.

4. Other Points

There is an IANA consideration, requesting a new MIME media type, which looks pretty bog-standard.
2014-09-17
07 Nicolás Williams New version available: draft-ietf-json-text-sequence-07.txt
2014-08-21
06 Nicolás Williams New version available: draft-ietf-json-text-sequence-06.txt
2014-08-19
05 Nicolás Williams New version available: draft-ietf-json-text-sequence-05.txt
2014-05-23
04 Nicolás Williams New version available: draft-ietf-json-text-sequence-04.txt
2014-05-22
03 Nicolás Williams New version available: draft-ietf-json-text-sequence-03.txt
2014-05-19
02 Pete Resnick Intended Status changed to Proposed Standard
2014-05-19
02 Pete Resnick IESG process started in state AD is watching
2014-05-09
02 Nicolás Williams New version available: draft-ietf-json-text-sequence-02.txt
2014-05-08
01 Nicolás Williams New version available: draft-ietf-json-text-sequence-01.txt
2014-04-28
00 Paul Hoffman Document shepherd changed to Paul E. Hoffman
2014-04-28
00 Nicolás Williams New version available: draft-ietf-json-text-sequence-00.txt