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

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 12 Aug 2011 07:09:27 +0300

Peter,

I think your document should be clear whether it affects the "vnd." 
construction, used, eg., as I remember, in MIME media types and elsewhere.

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.  
However, when the "X-" convention is deprecated, new protocols will not 
need to set such policy; so no changes for IANA are necessary now.

Mykyta Yevstifeyev

26.07.2011 15:59, Peter Saint-Andre wrote:
> FYI. The authors have yet to incorporate any of the feedback from the
> APPSAWG meeting yesterday.
>
> -------- Original Message --------
> Subject: I-D Action: draft-saintandre-xdash-03.txt
> Date: Tue, 26 Jul 2011 05:50:42 -0700
> From: [email-masked]
> Reply-To: [email-masked]
> To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> 	Title           : Deprecating Use of the&quot;X-&quot; Prefix in
> Application Protocols
> 	Author(s)       : Peter Saint-Andre
>                            D. Crocker
>                            Mark Nottingham
> 	Filename        : draft-saintandre-xdash-03.txt
> 	Pages           : 12
> 	Date            : 2011-07-26
>
>     Historically, there has often been a perceived distinction between
>     &quot;standard&quot; and&quot;non-standard&quot; parameters (such as
> media types and
>     header fields), by prefixing the latter with the string&quot;X-&quot; or
>     similar constructions (e.g.,&quot;x.&quot;).
>
>     In practice, this convention causes more problems than it solves.
>     Therefore, this document deprecates the&quot;X-&quot; convention for
> most
>     application protocol parameters.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-saintandre-xdash-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-saintandre-xdash-03.txt
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Ned Freed <[email-masked]>
Date: Sat, 13 Aug 2011 08:52:53 -0700 (PDT)

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

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

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

				Ned

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 17 Aug 2011 17:42:06 +0300

> is 100% disjoint from the vendor, personal, and standard trees.

So this could and should be mentioned in the document.

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

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

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.

Mykyta

---

From: Ned Freed <[email-masked]>
Date: Wed, 17 Aug 2011 07:53:33 -0700 (PDT)

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

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

> their registration.

Yes, that's the current state of affairs.

> The I-D was uploaded on 13 June, and even if such

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.

> 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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 17 Aug 2011 18:26:46 +0200

Apropos xdash-03, checking various things I missed in 2009 and 2010
I stumbled over draft-yevstifeyev-ion-report, from there I found
the new home page of the [PROCDOCS] -- BTW, it is very good that
[TAObis] and [PROCDOCS] are still updated, no matter what happens
with FYIs or IONs as a series -- and somehow eventually arrived at
draft-iab-extension-recs section 3.1, or rather the predecessor of
this I-D (= draft-carpenter-extension-recs).

IOW, there is some "prior art" for X-issues by Brian Carpenter not
yet mentioned in the xdash draft, and if the IAB still works on the
extension-recs I hope that their conclusions match saintandre-xdash
when both are finished.

-Frank

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 18 Aug 2011 08:59:39 +0300

> 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 are unambiguously associated with a single format would be 

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

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

> we handle extant registries is out of scope and necessarily will be 

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

---

From: Tony Hansen <[email-masked]>
Date: Thu, 18 Aug 2011 09:11:47 -0400

On 8/18/2011 1:59 AM, Mykyta Yevstifeyev wrote:
> parameters are used in the meaning of vendor-specific.  So I think, 
> for the sake of clarity, this should be mentioned.

There are some vnd types that are extremely widely used. vnd has never 
implied limited use. It has a well defined meaning that is extremely 
dissimilar to x-. Trying to equate or draw analogies between 
experimental use and vendor-specific is simply erroneous.

I'm with Ned here.

     Tony Hansen

---

From: Ned Freed <[email-masked]>
Date: Thu, 18 Aug 2011 08:36:29 -0700 (PDT)

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

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

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

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

> as they are

I have no idea what you mean by this.

> 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

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 19 Aug 2011 14:11:51 -0700

> ways, and disjoint in some ways.

This specification covers X- usage.  It covers nothing else.  That includes not 
covering its "neighbors".

In the most literal sense, those are out of scope.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 20 Aug 2011 08:10:24 +0300

20.08.2011 0:11, Dave CROCKER wrote:
> This specification covers X- usage.  It covers nothing else.  That 
> includes not covering its "neighbors".
>

OK, after all, I don't insist.

Mykyta

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Aug 2011 10:20:46 -0600

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

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

> nothing resembling a consensus to make such a change at this time.

Agreed.

> we handle extant registries is out of scope and necessarily will be

+1.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Aug 2011 10:28:04 -0600

> this I-D (= draft-carpenter-extension-recs).

Do you mean Section 2.3? That's the only section mentioning "X-" at
http://tools.ietf.org/id/draft-carpenter-extension-recs-04.txt (as far
as I can see).

> extension-recs I hope that their conclusions match saintandre-xdash

Yes, it would be good to keep these two documents in sync. I'll reach
out to the authors of draft-iab-extension-recs in this matter.

Peter

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

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 30 Aug 2011 19:51:55 +0300

>     defined in this document.

I agree with such text.

>     specific extensions, and reserve delimeters as necessary.

I'm fine with this change as well.

> [ . . . ]