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

[Mykyta Yevstifeyev <[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; they both 
imply that the parameter has a limited use as an experimental/vendor 
specific; herewith the first often covers the latter - I mean that x. 
parameters are used in the meaning of vendor-specific.  So I think, for 
the sake of clarity, this should be mentioned.

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

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

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

Well, but some generic principles should be determined, if we want to 
allow such assignments.  But here I agree - let's wait until the 
document gets some stability of what action it performs.

Mykyta

>
>                 Ned
>