Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt

[Mykyta Yevstifeyev <[e-mail]>]

Hi all,

Looking through this document again...

I don't really know whether comments from
http://www.ietf.org/mail-archive/web/happiana/current/msg00184.html have
been considered (at least, no response from authors have been received so
far), but here is what I see in the current version with respect to the
issues these comments concerned:

--citing begins (my comments in-line starting with "MY>")--

Ned, all,

Some additional (to Julian's) comments.

In Abstract, it must be mentioned that the document obsoletes RFC 4288.

MY> Still relevant.

I find the current text in Introduction very confusing (or irrelevant), as
it is very generic and not related to media types. It should be rewritten
to make clear the goal of the doc. I also concur with Julian that
Historical Note should be moved in the Introduction section.

MY> Now Introduction seems fine.

In Section 3.1: when specifying the procedures for registration media types
in Standards Tree, you mentioned (in terms of RFC 5226): IESG approval,
Specification Required, IETF Consensus, RFC Required with IESG Approval,
i.e. 4 different registration policies. Whereas they serve a variety of
possible cases, I think we would benefit from a single policy which would
cover all of them. I suppose it is "Specification Required with IESG
Approval" that would cover the following cases: (1) IESG-approved document,
(2) specification of other standards body; registration undergoing IESG
approval, (3) non-IESG-approved RFCs, registration of which also undergo
IESG approval. The possible cases may also be discussed, though.

MY> Also relevant in this version.

Section 3.3: the "vanity" naming. I may be wrong cause it may be some sort
of stylistic choice, but I actually think that "personal" is enough to
characterize this tree. Whereas English native speakers would understand
such naming, this would be frankly difficult for those who speak English as
a foreign lang. I can't manage to find Russian or Ukrainian translation of
RFC 4288 to prove, but I'm sure that the said formulation is applicable in
English language only, and isn't appropriate for the international-scoped
document.

MY> Relevant as well.

Section 3.4: this is what Julian has already mentioned for Section 4.2.
APPSAWG is obliged to bring the draft deprecating x- to BCP, so if we
revising the procedures docs, we need to take it into account. I propose
you remove Section 3.4 and naming convention from Section 4.2 but put a
note in Appendix B referring to the RFC-to-be. <later when="after reading
reply to Julian's message">I think that if we produce new version of the
doc we should take into account the current practice documented as BCP (and
I hope it will get BCP). At least you should note that their registration
is not absolutely prohibited; I also agree that in exceptional cases they
can be registered, but only if wide use is demonstrated.</later>

MY> Current WG draft on deprecating x- says nothing on this, so I think we
still should mention something in this document.  Let'as consider my above
proposal.

Section 4.2: Shouldn't it explain the differences between RFC 2045 and the
given ABNF?

Section 4.10: "Proposals for media types registered in the standards tree
by the IETF itself MUST be published as RFCs.". Do you really mean
"proposal"? Also, do we need to encourage publishing RFCs for vnd and prs
registrations?

MY> This is ok in the current version.

Section 5.1: "Registrations in other trees MAY be sent to the list for
review as well." Maybe SHOULD?

MY> Fixed; thanks.

Section 5.9: Do we need to leave mail-style lines in the template (I mean
To: and Subject:)?

MY> (Now s5.7), and fixed in the doc.

Ibid:  Please move the para about MacOS file types into Section 4.11.

MY> Now moved, I see.

Section 6: s/RFC 3978/RFC 5378/ (and in References)

MY> This is fixed.

Sections 6 and 8: As your document sets up the registry for +suffixes, it
should contain the description as required by RFC 5226, which it currently
doesn't have.

MY> This comment still applies.

--citing ends--

These are my November comments, and so I suppose there could be more while
discussing the document.

Mykyta Yevstifeyev

2012/2/4 <[e-mail]>

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Applications Area Working
> Group Working Group of the IETF.
>
>        Title           : Media Type Specifications and Registration
> Procedures
>        Author(s)       : Ned Freed
>                          John C. Klensin
>                          Tony Hansen
>        Filename        : draft-ietf-appsawg-media-type-regs-00.txt
>        Pages           : 29
>        Date            : 2012-02-03
>
>   This document defines procedures for the specification and
>   registration of media types for use in HTTP, MIME and other Internet
>   protocols.
>
>
> A URL for this Internet-Draft is:
>
> http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
>
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-00.txt
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>