Media Type Specifications and Registration Procedures
draft-ietf-appsawg-media-type-regs-14
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-11-26
|
14 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-11-25
|
14 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2012-11-15
|
14 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-10-28
|
14 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2012-10-26
|
14 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-07-23
|
14 | Barry Leiba | Ballot writeup was changed |
2012-07-11
|
14 | (System) | IANA Action state changed to In Progress from Waiting on ADs |
2012-07-09
|
14 | (System) | IANA Action state changed to Waiting on ADs from In Progress |
2012-06-28
|
14 | Samuel Weiler | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Vincent Roca. |
2012-06-26
|
14 | (System) | IANA Action state changed to In Progress |
2012-06-26
|
14 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-06-25
|
14 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-06-25
|
14 | Amy Vezza | IESG has approved the document |
2012-06-25
|
14 | Amy Vezza | Closed "Approve" ballot |
2012-06-25
|
14 | Amy Vezza | Ballot approval text was generated |
2012-06-22
|
14 | Barry Leiba | State changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2012-06-22
|
14 | Barry Leiba | Ballot writeup was changed |
2012-06-21
|
14 | Barry Leiba | Ballot writeup was changed |
2012-06-21
|
14 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2012-06-21
|
14 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2012-06-21
|
14 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-06-21
|
14 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-06-21
|
14 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-06-20
|
14 | Ned Freed | New version available: draft-ietf-appsawg-media-type-regs-14.txt |
2012-06-20
|
13 | Robert Sparks | [Ballot comment] (Updating to reflect email discussion, clearing the discuss point. The list discussion already describes resolution for the remaining comments below) In paragraph 5 … [Ballot comment] (Updating to reflect email discussion, clearing the discuss point. The list discussion already describes resolution for the remaining comments below) In paragraph 5 of section 4.2.1 where it says "all text/* registrations", should it say "all new text/* registrations"? (Similar to how mime-default-charset allowed for existing registrations that didn't follow these instructions.) Very minor nits: There are a few uses of RFC2119 keywords carried forward from RFC4288 that you might consider removing. The SHOULDs in the first paragraphs of section 4.5 are what motivated this comment. I understand if you don't want to make such a low-yield change at this point in the process though. The historical note (section 1.1) was copied forward from the introduction to rfc4288 without modification. It says things like "has now been moved" and "this revision" where "now" and "this" were written with 4288 in mind. Please grammar check the last sentence of 4.2.7 |
2012-06-20
|
13 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to Yes from Discuss |
2012-06-20
|
13 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-06-19
|
13 | Pete Resnick | [Ballot comment] A fresh look is always nice. This looks pretty darn reasonable. A few questions: 3.1: Standards-tree registrations from recognized standards bodies may … [Ballot comment] A fresh look is always nice. This looks pretty darn reasonable. A few questions: 3.1: Standards-tree registrations from recognized standards bodies may be submitted directly to the IANA, where they will undergo Expert Review [RFC5226] prior to approval. Why is it "may be" in the above? Ought it be "should be" or "are"? 5.1 and 6: I know there was some discussion about having IANA take care of posting to ietf-types, in particular for standards-tree non-IETF registrations. Was it decided that this was *not* going to be done? Or was it simply idle chatting about a potential change but nothing ever came of it? Just curious. 5.2.1 The mechanism for abandoning provisional registrations was not clear to me. Do you mean they are considered abandoned after some period of time, or an applicant can explicitly abandon them, or something else? It's not spelled out. |
2012-06-19
|
13 | Pete Resnick | [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick |
2012-06-19
|
13 | Robert Sparks | [Ballot discuss] The motivation for the change from MUST send to SHOULD send types to a mailing list for review isn't captured, at least not … [Ballot discuss] The motivation for the change from MUST send to SHOULD send types to a mailing list for review isn't captured, at least not near where the change is made in section 5.1. Could we add a little text supporting why that's not MUST now? I understand that one of the main motivations was to make the registration process more palatable for other organizations, but want to make sure we are saying what we really mean for IETF registrations. When would it be OK to skip this review for an IETF registration in the standards tree? |
2012-06-19
|
13 | Robert Sparks | [Ballot comment] Should paragraph 5 of section 4.2.1 point to rfc-to-be-ietf-appsawg-mime-default-charset? Also, where it says "all text/* registrations", should it say "all new text/* registrations"? … [Ballot comment] Should paragraph 5 of section 4.2.1 point to rfc-to-be-ietf-appsawg-mime-default-charset? Also, where it says "all text/* registrations", should it say "all new text/* registrations"? (Similar to how mime-default-charset allowed for existing registrations that didn't follow these instructions.) Very minor nits: There are a few uses of RFC2119 keywords carried forward from RFC4288 that you might consider removing. The SHOULDs in the first paragraphs of section 4.5 are what motivated this comment. I understand if you don't want to make such a low-yield change at this point in the process though. The historical note (section 1.1) was copied forward from the introduction to rfc4288 without modification. It says things like "has now been moved" and "this revision" where "now" and "this" were written with 4288 in mind. Please grammar check the last sentence of 4.2.7 |
2012-06-19
|
13 | Robert Sparks | [Ballot Position Update] New position, Discuss, has been recorded for Robert Sparks |
2012-06-19
|
13 | Sean Turner | [Ballot discuss] We sometimes publish drafts directly to historic. Is there a chance that a historic document might register a media type, and if it … [Ballot discuss] We sometimes publish drafts directly to historic. Is there a chance that a historic document might register a media type, and if it did what tree would it go in? (btw - if the answer is we'll never ever, ever do this - that's okay I'm just wondering if anybody can think of a time when this might happen and we couldn't use the procedures.) |
2012-06-19
|
13 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2012-06-18
|
13 | Russ Housley | [Ballot comment] Section 6 says: > > 2. If there is no entry for their suffix scheme, fill out the > … [Ballot comment] Section 6 says: > > 2. If there is no entry for their suffix scheme, fill out the > template (specified in Section 6.2) and include that with the > media type registration. The template may be contained in an > Internet Draft, alone or as part of some other protocol > specification. The template may also be submitted in some other > form (as part of another document or as a stand-alone document), > but the contents will be treated as an "IETF Contribution" under > the guidelines of BCP 78 [RFC5378]. > If a document other than an Internet-Draft is used, how do the authors acknowledge that an IETF contribution is being made? |
2012-06-18
|
13 | Russ Housley | Ballot comment text updated for Russ Housley |
2012-06-18
|
13 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-06-18
|
13 | Stephen Farrell | [Ballot comment] - "faceted name" could be defined more clearly, I didn't get the "tree.subtree...subtype" notation in section 3. The draft is readable even so, … [Ballot comment] - "faceted name" could be defined more clearly, I didn't get the "tree.subtree...subtype" notation in section 3. The draft is readable even so, but that was a bit confusing. - Just wondering, if another SDO or a vendor registers a media-type and then updates their specification for that, is there an expectation of backwards compatibility? Is that something the designated expert ought take into account? - 3.4, typo s/considered to members/considered to be members/ - 4.1, "better thought of as..." is a bit vague, but I guess this was thrashed by the appsawg. If not, (and only if not), would this be better with a more objective definition of what's not allowed, and with some 2119 language for the designated expert to follow? - 4.2 says that different names for the same thing "is discouraged." Why isn't that a SHOULD NOT with the exception being legacy stuff and things that escape into the wild and get too big to ignore? - 4.6 says "MUST NOT be confused with" which isn't really meaningful 2119 language - if you want to outlaw saying there are "no security issues" then just saying that might be a good, if odd, MUST NOT. I'd say you could strike the 2119 lanaguage here though. - 4.12 refers to MacOSFileTypes, when you go there it says Apple no longer update that page, so a) is that the best reference? b) should this draft say that those file type codes are legacy stuff (if that's the case, I'm not a Mac user:-). - 5.3 doesn't actually say how the media types reviewer makes the decision public which I think it ought (presumably via a mail to IANA and some mailing list?). It also doesn't specify any time limits or goals for responsiveness, which would be nice. - 5.6 could usefully reference a "good" example registration (maybe as a pointer to somewhere or a new appendix). I think that'd help people who read this later. (Same for section 6, if one exists.) - section 6 assumes (I think), but doesn't say that the same expert does this, is appointed by apps ADs etc. Worth adding? - section 7 might usefully provide a reference to some known vulnerabilities that have been seen in complex media types. For example, saying something like: "As noted earlier, complex media types can and have caused real security problems, for an example see [CVE-2010-3116]." That [1] was just the first related CVE I saw in a search, anything similar would do fine. The idea is just to emphasise that these are real problems in real systems. [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3116 |
2012-06-18
|
13 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-06-18
|
13 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-06-18
|
13 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-06-18
|
13 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-06-15
|
13 | Adrian Farrel | [Ballot comment] Thank you for Appendix B which made reviewing a lot easier. |
2012-06-15
|
13 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-06-15
|
13 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-06-15
|
13 | Barry Leiba | Placed on agenda for telechat - 2012-06-21 |
2012-06-15
|
13 | Barry Leiba | Ballot has been issued |
2012-06-15
|
13 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2012-06-15
|
13 | Barry Leiba | Created "Approve" ballot |
2012-06-12
|
13 | Ned Freed | New version available: draft-ietf-appsawg-media-type-regs-13.txt |
2012-06-12
|
12 | Ned Freed | New version available: draft-ietf-appsawg-media-type-regs-12.txt |
2012-06-04
|
11 | Ned Freed | New version available: draft-ietf-appsawg-media-type-regs-11.txt |
2012-05-30
|
10 | Francis Dupont | Request for Last Call review by GENART Completed. Reviewer: Francis Dupont. |
2012-05-24
|
10 | Ned Freed | New version available: draft-ietf-appsawg-media-type-regs-10.txt |
2012-05-22
|
09 | Pearl Liang | IANA has reviewed draft-ietf-appsawg-media-type-regs-07.txt and has the following comments: Where do we populate the "list of IESG-recognized standards bodies who are allowed to register types … IANA has reviewed draft-ietf-appsawg-media-type-regs-07.txt and has the following comments: Where do we populate the "list of IESG-recognized standards bodies who are allowed to register types in the standards tree"? Should this be a public list or something that IANA keeps track of privately? Section 5.2.1 tells us to set up a separate provisional registry, but the IANA Considerations section doesn't mention it. As this is a new registry, should it be mentioned there? Also, is there an expiration or renewal date on provisional registrations? 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. |
2012-05-21
|
09 | Barry Leiba | Ballot writeup was changed |
2012-05-21
|
09 | Barry Leiba | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-05-21
|
09 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-05-18
|
09 | Ned Freed | New version available: draft-ietf-appsawg-media-type-regs-09.txt |
2012-05-16
|
08 | Ned Freed | New version available: draft-ietf-appsawg-media-type-regs-08.txt |
2012-05-11
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Vincent Roca |
2012-05-11
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Vincent Roca |
2012-05-10
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2012-05-10
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2012-05-07
|
07 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Media Type Specifications and Registration Procedures) … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Media Type Specifications and Registration Procedures) to Best Current Practice The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Media Type Specifications and Registration Procedures' as Best Current Practice 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 2012-05-21. 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 defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-05-07
|
07 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-05-07
|
07 | Barry Leiba | Last call was requested |
2012-05-07
|
07 | Barry Leiba | Ballot approval text was generated |
2012-05-07
|
07 | Barry Leiba | State changed to Last Call Requested from AD Evaluation::AD Followup |
2012-05-07
|
07 | Barry Leiba | Last call announcement was generated |
2012-05-07
|
07 | Barry Leiba | Ballot writeup was changed |
2012-05-07
|
07 | Barry Leiba | Changed protocol writeup |
2012-05-07
|
07 | Barry Leiba | Ballot writeup was generated |
2012-05-04
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-05-04
|
07 | Ned Freed | New version available: draft-ietf-appsawg-media-type-regs-07.txt |
2012-04-27
|
06 | Barry Leiba | State changed to AD Evaluation::Revised ID Needed from AD Evaluation |
2012-04-27
|
06 | Barry Leiba | State changed to AD Evaluation from Publication Requested |
2012-04-27
|
06 | Barry Leiba | PROTO writeup: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type … PROTO writeup: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The document is seeking BCP status, since it defines media type registration procedures. It is replacing RFC4288 which also has BCP status. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. Working Group Summary Nothing of note. The document was developed by seasoned experts in terms of media types, and the process has been smooth. Document Quality The document updates media type registration procedures based on experience since the publication of RFC4288. The procedures created there and in its antecedent have been around for a long time; this document merely refines them. Personnel Murray Kucherawy is the Document Shepherd. Barry Leiba is the responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed the document alongside RFC4288 and observed the discussion on the apps-discuss mailing list. I have no concerns. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? None. It received almost entirely supportive comments on apps-discuss over the past few months. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No such reviews are required for this BCP. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no such concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes; there are none. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? A comfortable number of supporters have posted to apps-discuss in favour of moving this document forward, with mostly reasonable questions and suggestions that have been answered by the authors. The consensus is solid. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) There are no appeal threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. IDnits complained about things like a reference to RFC2048 (which is obsolete) but this is used correctly to give extended history of the subject matter. No other concerns were identified. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such formal reviews are required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? There is a normative reference to draft-ietf-appsawg-mime-default-charset, and it will reach the IESG shortly after this one does. There is also a normative reference to draft-hansen-media-type-suffix-regs that is being processed by appsawg, but is not ready for IESG evaluation. It is not expected to take long. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No; all normative references other than the drafts named above are either Standards Track or BCP. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. RFC4288 is obsoleted by this specification. This is called out in the Abstract. An appendix further describes all the changes since RFC4288. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA Considerations section is brief but well-formed and consistent with the remainder of the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The new registry created by this document uses the same Designated Expert as is currently used for media type registries. No new selection is needed. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. In addition to a thorough IDnits check, a BNF parser came up clean for the small amount of ABNF this document uses. |
2012-04-27
|
06 | Barry Leiba | Changed protocol writeup |
2012-04-27
|
06 | Barry Leiba | State changed to Publication Requested from AD is watching |
2012-04-26
|
06 | Murray Kucherawy | IETF state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2012-04-26
|
06 | Murray Kucherawy | Annotation tags Awaiting External Review/Resolution of Issues Raised, Revised I-D Needed - Issue raised by WGLC cleared. |
2012-04-26
|
06 | Murray Kucherawy | New post-WGLC version available. Requesting publication. |
2012-04-26
|
06 | Ned Freed | New version available: draft-ietf-appsawg-media-type-regs-06.txt |
2012-04-20
|
05 | Murray Kucherawy | Annotation tag Waiting for Referenced Document cleared. |
2012-04-17
|
05 | Murray Kucherawy | Annotation tag Doc Shepherd Follow-up Underway cleared. |
2012-04-17
|
05 | Murray Kucherawy | Changed protocol writeup |
2012-04-17
|
05 | Murray Kucherawy | Annotation tag Waiting for Referenced Document set. |
2012-04-15
|
05 | Murray Kucherawy | WGLC on referenced document has completed. |
2012-04-15
|
05 | Murray Kucherawy | Will submit with draft-ietf-appsawg-mime-charset-default, which completes WGLC on 4/20. |
2012-04-15
|
05 | Ned Freed | New version available: draft-ietf-appsawg-media-type-regs-05.txt |
2012-04-13
|
04 | Murray Kucherawy | Annotation tag Awaiting External Review/Resolution of Issues Raised set. |
2012-04-12
|
04 | Murray Kucherawy | Annotation tag Revised I-D Needed - Issue raised by WGLC set. |
2012-04-12
|
04 | Murray Kucherawy | Annotation tag Doc Shepherd Follow-up Underway set. |
2012-04-12
|
04 | Murray Kucherawy | IETF state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2012-04-12
|
04 | Murray Kucherawy | Changed protocol writeup |
2012-04-11
|
04 | Murray Kucherawy | Changed protocol writeup |
2012-04-01
|
04 | Murray Kucherawy | IETF state changed to In WG Last Call from WG Document |
2012-04-01
|
04 | Murray Kucherawy | W3C wants to suggest some text. |
2012-04-01
|
04 | Murray Kucherawy | Also a couple of minor IDnits need to be resolved. |
2012-04-01
|
04 | Murray Kucherawy | (see previous) |
2012-04-01
|
04 | Murray Kucherawy | WGLC has completed. Awaiting responses to a couple of last-minute review comments, and will then submit it to the IESG. |
2012-04-01
|
04 | Murray Kucherawy | WGLC ends April 13th. |
2012-04-01
|
04 | Ned Freed | New version available: draft-ietf-appsawg-media-type-regs-04.txt |
2012-03-30
|
03 | Barry Leiba | Responsible AD changed to Barry Leiba from Pete Resnick |
2012-03-30
|
03 | Barry Leiba | Intended Status changed to Best Current Practice from None |
2012-03-28
|
03 | Murray Kucherawy | Changed shepherd to Murray Kucherawy |
2012-03-12
|
03 | Ned Freed | New version available: draft-ietf-appsawg-media-type-regs-03.txt |
2012-03-12
|
02 | Ned Freed | New version available: draft-ietf-appsawg-media-type-regs-02.txt |
2012-02-19
|
01 | Pete Resnick | Draft added in state AD is watching |
2012-02-04
|
01 | (System) | New version available: draft-ietf-appsawg-media-type-regs-01.txt |
2012-02-04
|
00 | (System) | New version available: draft-ietf-appsawg-media-type-regs-00.txt |