Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01

[John C Klensin <[e-mail]>]

--On Monday, October 25, 2010 11:50 -0400 Eric Burger
<[e-mail]> wrote:

> Well... Is not the problem that a proprietary extension
> becomes standard?

The problem may be that there is no consensus yet on what
problem we are trying to solve :-(

> What is the difference between X-mumble and Eric-mumble?  Does
> private namespaces really help the fundamental problem?

The problem I'd like to solve is to be able to bind every header
field name to a definition of that header and to be sure those
definitions are unique (i.e., exactly one definition per header
field name), either via registration of the field name or via
one level of indirection (knowing whom to ask).

>From that perspective, X-mumble was intended to solve a
differentm but collateral, problem, i.e., providing a specific
warning that there was no reliable name <-> definition binding,
at least in the absence of significant out-of-band information.
I think there is little or no disagreement that "X-" has not
been successful in meeting that objective.  The controversy
appears only to be (1) whether it is enough worse than nothing
to be considered harmful and deprecated without another plan to
address the definition binding or warning issues and (2) whether
we do have a plan to replace it.   I read Tony's proposal and
Nathaniel's earlier remarks as the beginnings of such a plan.

As far as whether Eric-mumble would be significantly better, the
answer in the general case is "no".  But Tony's comment was
about the mechanism used for media types.  The vendor and
personal namespaces there have a very specific structure.  If we
adopted that model (plus or minus fine-tuning):

	o X-mumble would essentially be invalid on its face,
	because it could not be registered.
	
	o Eric-mumble would be invalid unless you conformed to
	the registration procedure (if we followed the general
	media type model, that would require standards action or
	formal IESG recognition, presumably supported by an RFC
	or stable, public, document)
	
	o vnd.eric.mumble would be valid if "eric" were
	registered and pointed to you so that (i) you could be
	consulted about what "mumble" meant and (ii) no one else
	would use "vnd.eric."
	
	o pers.eric.mumble would be valid with or without
	registration, but would effectively carry the same
	disclaimer than "X-" has tried to carry, i.e., that I'd
	better be very confident that I know who "eric" is
	before assuming that I can interpret "mumble".

Ignoring the obvious small issues with syntax, using
vnd.URI.field-name or vnd.FQDN.field-name would have the
advantage over vnd.Registered-Vendor-Name.field-name of not
requiring an IANA registry... and the disadvantage of being
somewhat less stable.  Of course, we could punt that tradeoff by
having both Registered-Vendor-Name and something URI or
DNS-based with different first-facet prefixes and letting the
vendor choose between long-term stability and the convenience of
avoiding dealing with IANA at all.

    john