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 |