Re: [apps-discuss] [happiana] draft-freed-media-type-regs-01 comments

Ned, all,

Some additional (to Julian's) comments.

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

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.

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.

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.

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>

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?

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

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

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

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

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.

Thanks,
Mykyta Yevstifeyev

06.11.2011 15:40, Julian Reschke wrote:
> On 2011-11-05 20:17, Ned Freed wrote:
>> The revised media type registration procedure document:
>>
>> http://tools.ietf.org/html/draft-freed-media-type-regs-01
>>
>> is in need of review. In particular, comments are solicited on 
>> exactly how the
>> process should be modified to remove the IESG from the review process 
>> for
>> standards tree types. (Note that the IESG needs to retain the 
>> authority to
>> determine what external organization are qualified standards bodies 
>> and what
>> ones are not.)
>> ...
>
> Hi Ned,
>
> below are notes from a quick top-to-bottom read I just did...:
>
> Comments:
>
> - 4.2 - reg-name; it would be good to state how exactly it is more 
> restrictive, to reference the actual subsection of 2045 (5.1), and 
> maybe say why.
>
> - 4.2 - "X-" prefixes - this obviously should be coordinated with 
> Peter's document.
>
> - 4.2.2 - "specifies one or more separate images that require 
> appropriate hardware to display" - sounds a bit fine-tuned for a time 
> where graphics hardware was something special. (Also, what about audio 
> and video?? :-)
>
> - 4.2.8 - Structured Syntax Name Suffixes - would it make sense to 
> relax the standards-tree registration requirements for types that use 
> an existing structured syntax? (given the fact doing so makes it much 
> harder to do things wrong)
>
> - 4.3 - parameter-name; this repeats the warning about the change from 
> 2045, but adds "amended by RFC2231". Optimally have this in a single 
> place and be consistent.
>
> - 4.3 - maybe repeat the requirements from 2045 about 
> case-insensitivity and ordering?
>
> - 4.3 - the question about the validity to *repeat* parameters comes 
> up from time to time. My understanding is that it's understood to be 
> invalid, but I don't think any spec says that yet. Maybe it should be 
> noted here because it affects definitions of new parameters?
>
> - 4.11 - Mac OS File Type - is this still useful information? 
> Minimally, to avid confusion, it should be stated that this only 
> affects ancient versions of MacOS (right?)
>
> - 5.8 - "When review is required, a change request may be denied if it 
> renders entities that were valid under the previous definition invalid 
> under the new definition." - see 
> <http://www.w3.org/html/wg/tracker/issues/53> - two questions:
>
> 1) Is "valid" to be read as "processable" or as "conforming"? For 
> instance, HTML5 makes many things invalid that were valid before, but 
> recipients still need to process them.
>
> 2) "may be denied" is very vague? What are the guidelines? Do we have 
> any?
>
> - References - The spec has a normative reference to RFC 3023, which 
> in turn has a reference to RFC 2048, which this document is obsoleting 
> (via 4288); do we really need a normative reference here? (maybe this 
> can be fixed by processing this one in sync with 3023bis)?
>
>
> Editorial:
>
> - Boilerplate - Maybe move the "Historical Note" down into the 
> "Introduction" section? (not only for being easier to cite in the future)
>
> - Boilerplate - I always recommend to have an Editorial Note on the 
> front page telling reviewers where to send feedback.
>
> - 5.2 - do items 1) and 2) apply to "Specification Required" process? 
> The way it's formatted is slightly confusing.
>
> - Throughout - The spec mixes uppercase and lowercase RFC2119 terms, 
> and it's not totally clear what the "force" of the lowercase ones is. 
> In many cases this can be avoided by substituting "MAY" by "can" etc.
>
>
> Nits:
>
> - 5.2 - s/[RFC2026] section 6.5.4/Section 6.5.4 of [RFC206]/
>
> - References - RFC4234 -> RFC 5234
>
> - References - in the reference for RFC2231, there's a line break that 
> shouldn't be there (this may be a problem in the 
> xml.resource.org-supplied reference, but still...)
>
>
> Best regards, Julian
> _______________________________________________
> happiana mailing list
> happiana@ietf.org
> https://www.ietf.org/mailman/listinfo/happiana
>