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

[Peter Saint-Andre <[e-mail]>]

On 8/17/11 8:53 AM, 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.

Agreed. However, I think a paragraph like this would be appropriate in
the IANA Considerations section:

   This document does not modify registration procedures currently in
   force for various application protocols.  However, such procedures
   might be updated in the future to incorporate the best practices
   defined in this document.

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

Ned, you are right. I've removed that clause from point 3 in Section 4:

   SHOULD identify a convention to allow local or implementation-
   specific extensions, and reserve delimeters as necessary.

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

Agreed.

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

+1.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/