Re: [apps-discuss] Fwd: I-D Action: draft-saintandre-xdash-03.txt

[Ned Freed <[e-mail]>]

> 13.08.2011 18:52, Ned Freed wrote:
> >> I think your document should be clear whether it affects the "vnd."
> >> construction, used, eg., as I remember, in MIME media types and
> >> elsewhere.
> >
> > The answer to that is "no", by definition. The unregistered (x-/x.) tree
> > is 100% disjoint from the vendor, personal, and standard trees.

> So this could and should be mentioned in the document.

Not sure I see why. Listing all the extant things the document doesn't apply to
is going to be a long list.

That said, I actually object to what this document currently says about media
types: It is flatly incorrect to characterize the vnd. tree as being for
"local or implementation-specific extensions". On the contrary, vnd. exists so
that vendors can define formats with some degree of interoperability and some
understanding of the security considerations, but without having to fully
standardize them. As such, they aren't local, they aren't
implementation-specific, and they aren't extensions.

> >> With respect to existing IANA policies regarding assignment and
> >> registration values beginning in "X-".  I suppose IANA should continue
> >> to follow those policies which were set by the corresponding documents,
> >> in order not to create the influx of registrations of "X-" values.
> >
> > Actually, there has been some sentiment that we should actually allow
> > and encourage such registrations.

> As previously "x-" parameters weren't allowed to be registered,
> interoperability problems may arise when such parameter has several
> real-life usages and only one is registered.  I suspected the document
> not to have a retroactivity.

First of all, nobody has suggested or even implied that such registrations
would be unconditionally allowed. It goes without saying that only x- types
that are unambiguously associated with a single format would be eligible for
registration.

Second, I rather suspect that a significant fraction of the x- media types in
use have essentially only one real-life usage. And it is usually pretty easy to
tell when this is the case.

But it remains to be seen whether or not we decide to do something about this
or not. The present draft doesn't contain any changes in this area and there is
nothing resembling a consensus to make such a change at this time.

> >
> >> However, when the "X-" convention is deprecated, new protocols will not
> >> need to set such policy; so no changes for IANA are necessary now.
> >
> > Given that the media types registration procedures document is currently
> > being revised, any changes to x-/x. in that context should be dealt
> > with in that update. Putting it in a separate general document would
> > be both confusing and inappropriate.

> Your I-D which I found and which positions itself as 4288bis
> (http://tools.ietf.org/html/draft-freed-media-type-regs-00) does contain
> provisions regarding non-registered x. media types and prohibition of
> their registration.

Yes, that's the current state of affairs.

> The I-D was uploaded on 13 June, and even if such
> restriction is going to disappear, the new version of I-D should point
> to draft-saintandre-xdash to reflect x. being are deprecated; it also
> has to deal with existing-and-unregistered x. media types.

If and when we decide to change the semantics associated with x- in some way,
it may become appropriate to reference this I-D. Or not - it's difficult
to predict whether or not it makes sense to include such a reference until
the specifics of the change are known.

> I believe that deprecation should only concern new protocols and have no
> retroaticity; so those registries which don't currently allow x. or x-
> registrations, should continue doing so; those which are only being
> created, should take the discussed doc into account.

Exactly - this specifiction is focused on *new* parameters. How
we handle extant registries is out of scope and necessarily will be determined
on a case-by-case basis.

				Ned