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

[Ned Freed <[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.

Adding the section 5.1 reference is a good idea and I'll do that. But I really
don't want to get into where all the restrictions originate - the point behind
writing this using descriptive rather than proscriptive ABNF was to make it
very easy for people to tell what characters they can use without having to
wade through a lot of unncessary distractions.

Remember: We're trying to make it easier for folks to figure out how to
register stuff. Understanding the historical reasons why things are the way
they are is a secondary goal at best.

> - 4.2 - "X-" prefixes - this obviously should be coordinated with
> Peter's document.

Er, actually, it rather obviously should not. Peter's draft is focused on
preventing *new* uses of the X- convention. It doesn't address the issue of
what to do about existing x- usage, which is a rather naunced and tricky area.

Now, if you want to argue that Peter's draft should address how to deal with
existing x- usage in various places, well, that's a discussion you need to have
to have elsewhere. If and when that happens it may make sense to refer to
such a document. Or not - it would depend on what it said.

In any case, the current approach taken to the X- issue here is to:

(1) Strongly discourage the use of such names.
(2) In the event such a name gets widely deployed in spite of it's lack
    of registration, allow it to be registered in the vnd. tree.

This wasn't noted in the changes since the last version list and I have
addressed that.

> - 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?? :-)

The point of the "separate image" line was to distinguish it from video. That
said, I take your point about the hardware reference and will remove it.

> - 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)

Not sure what you're getting at here. Stuctured syntax name suffixes are
available to all types in all registration trees and always have been. If
there's text that says or implies otherwise let me know where it is and I'll
fix it.

If you're saying that the requirements for a structured syntax are
too strict - they're currently that there be a referencable description
of that syntax, preferably in some sort of standards document - then I quite
simply disgree that that's a good iea.

> - 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.

It's a different change and for different reasons. And the amendment made
by RFC 2231 applies here but not to media type names, so it cannot be
collapsed without making it incorrect.

> - 4.3 - maybe repeat the requirements from 2045 about case-insensitivity
> and ordering?

Can't hurt.

> - 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?

I'll add a note about it.

> - 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?)

Nope. The actual situation under Mac OS is rather complex, but suffice it to
say that Mac OS still supports and uses these codes. (And yes, it also uses
file extensions. As I say, it's complicated.)

> - 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?

The concern here is that someone may attempt to use the change procedure as a
means of attack - for no good reason change a type in such a way that someone's
software is now incompliant.

This has never happened and this procedure has never been invoked. If and when
it ever does, then maybe at that point we'll be able to come up with some
better guidelines. But until then... I'm not comfortable trying to specify
anything more and I'm not comfortable removing this either.

That said, the part of this section that does bother me is the part about only
making changes when there's a serious error. I'm going to qualify that to say
significant changes to a definition should only be made to correct a serious
error. (I may actually not have gone far enough on this one.)

> - 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)?

You need to understand the rules that apply specifically to XML types to
register one and those rules are for better or worse, in RFC 3023. So IMO the
reference is normative.

As for trying to sync with another specification, that's almost always a really
bad idea. The reality is specifications are both interdependent and get
updates, so such situations are going to happen whether we like it or not.

> Editorial:

> - Boilerplate - Maybe move the "Historical Note" down into the
> "Introduction" section? (not only for being easier to cite in the future)

Seems reasonable.

> - Boilerplate - I always recommend to have an Editorial Note on the
> front page telling reviewers where to send feedback.

I don't really see the point in this case.

> - 5.2 - do items 1) and 2) apply to "Specification Required" process?
> The way it's formatted is slightly confusing.

This part is incomplete, pending input on exactly how the process should be
modified to allow registration of standards tree types without involving the
IESG.

> - 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.

A lower case must, may, or should is by definition not a RFC 2119 term. And the
choices for all of these have been made rather carefully over a prolonged
period. I'm not about to start making further changes willy-nilly along the
lines you suggest.

> Nits:

> - 5.2 - s/[RFC2026] section 6.5.4/Section 6.5.4 of [RFC206]/

OK.

> - References - RFC4234 -> RFC 5234

Fixed.

> - 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...)

I'll leave that one for the RFC Editor. Fixing XML resource stuff is above
my pay grade.

				Ned