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

[Eric Johnson <[e-mail]>]

I've a current interest in this, because I'm trying to craft language 
around IANA registration at pretty much the exact time that this draft 
came up.

One thought below:

On 10/25/10 10:08 AM, John C Klensin wrote:

[snip]
 >
 > 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).

That just about describes what I want to see out of registration, with 
minimal overhead to the person defining the extension.

[snip]

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

Please excuse me for any mistakes of protocol in contributing the 
following, since I'm still very much unfamiliar with the 
workings/culture of the IETF.

My brain immediately leapt to wondering whether the following make sense:

vnd.____.mumble

dns.____.mumble

If you want something in the "personal" category, it is so simple to get 
a DNS name (either as a sub-domain, or as a "top-level"), then why not 
just collapse those scenarios?

Also, being a long time Java programmer, I find it easier to read 
reverse-DNS names, as in "dns.org.ietf.mumble", rather than 
"dns.ietf.org.mumble".  In this case, the more general info comes at the 
front, and the more specific at the end, which a human reader might find 
easier?

"dns.com.foo.mumble"
"dns.uk.co.foo.mumble"
"dns.com.foo.mumble2"
"dns.uk.co.foo.mumble3"

as compared to:
"dns.foo.com.mumble"
"dns.foo.co.uk.mumble"
"dns.foo.com.mumble2"
"dns.foo.co.uk.mumble3"

-Eric.