Skip to main content

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