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

[Julian Reschke <[e-mail]>]

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