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

[Ned Freed <[e-mail]>]

> 17.08.2011 17:53, Ned Freed wrote:
> >> 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.

> But x. convention and vnd. convention are quite contiguous;

I don't know what this is suppposed to mean. These are separate namespaces,
each with it's own rules. They are adjacent in some ways, opposites in some
ways, and disjoint in some ways.

> they both
> imply that the parameter has a limited use as an experimental/vendor
> specific;

They imply no such thing. x./x- currently means the type is unregistered;
nothing more. vnd. means it's registered according to a certain set of
rules that are intended for vendor use. Nothing more.

The fact that vnd. types (a) Includes many types far more widely and
interoperably used that most standards tree types and (b) Each vnd type has a
usage field that doesn't always have value "limited" (in fact most do not)
shows what you're saying here is just plain wrong.

> herewith the first often covers the latter - I mean that x.
> parameters are used in the meaning of vendor-specific.

Except that they aren't.

> So I think, for
> the sake of clarity, this should be mentioned.

I disagree. Again, what this draft says is incorrect and it needs to be
changed. This is demonstrable.

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

> The essence of x- parameter actually makes this impossible;

It does no such thing. Hint: Exceptions can and have been made.

> as they are
> specially reserved for non-registered use, one cannot claim for sure
> that a specific parameter isn't used else as compared to "wide-spread use".

I have no idea what you mean by this.

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

> If the document really deprecates such thing as x. convention, it should
> either (1) have no retroactivity, which would mean that the deprecation
> affect those protocols which are or will be under development, or (2)
> deprecate actual use of x. parameters, which would mean that those
> vendors that deploy them will be encouraged to migrate to non-x; the
> latter will create interoperability problems, though.  In the first case
> IANA won't be allowed to assign x- if such restriction takes place;
> neither should such registrations be allowed in the second case.

There are plenty of alternatives besides what you describe here. But since (a)
This is not an appropriate time and place to discuss those alternatives and (b)
You seem to have multiple, fundamental misunderstandings of how media type
registrations work and how they can be handled, I see no point in discussing
this further.

				Ned