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

From: Alfred Hönes <[email-masked]>
Date: Thu, 21 Oct 2010 22:30:45 +0200 (MESZ)

[[ shortening the Subject to make it more concise ]]

In the whole discussion so far I observe an overly strong focus
on email header field names, and consequentially some degree of
neglection of bad experiences with X-* names in other namespaces.
But if I understand the subject draft correctly, this was not the
primary, or exclusive target namespace for the considerations.

I strongly suspect the origin of the draft has been in
    <http://tools.ietf.org/html/draft-hoehrmann-urlencoded-01> ,
which relates the trouble of standardizing and deploying the
Internet media type  "application/www-form-urlencoded"  as a
successor for the media type  "application/x-www-form-urlencoded"
once specified in the (now Historic[al]) RFC 1866.

The latter is deployed at large scale (no experiment!) and
cannot be registered (or have the registry entry updated)
under the present rules via a new Standards Track document,
where it is actually needed.

(Note that application/[x-]gzip is similar, but nobody tries to
include the non-X- form as a component of a revised Standard so far.
The much more severe trouble with compression etc. relates to the
matter of fact that the concept of Internet media types does not
allow structured nesting -- as with CMS content types --, and it
has always been controversial whether compression should be
regarded as some kind of [transfer] encoding, although it is
also used for storage.
But I go astray a bit; hence back to the primary topic ...)

I also note that the concept of P-* ("private") header field names
in SIP has also been declared a mis-invention now, because these
actually were intended for independent, interoperable implementations
targeting specific, yet kinda generic deployments.

So could we please widen the focus of the discussion accordingly?
Thanks in advance!

A quick observation and a rough thought based on it
(and I try to be neutral below regarding the namespace):

It looks like the seminal event for trouble with an X-* name is
when a *second* implementation starts to _generate_ that  X-* name.

As long as only a single implementation of an application/protocol
generates the name, there are no interoperability concerns and
arguably the purpose is not ripe for standardization -- independent
of the possibility that there _might_ happen to be several
implementations _consuming_ the entity identified by that name.
But as soon as the idea behind such entity and name gains traction
and multiple implementations are wanted, that should qualify for a
'normal' registration in the regular namespace.

So would it make sense to consider a change in the usage rules
for X-* names that STRONGLY RECOMMENDS to change track and register
a non-X-* name once more than one implementation considers making
active use of a particular X-* name ?

Adoption of such rules for specific namespaces should at least
help avoid trouble with new X-* names in the future, but it
cannot undo the sins of the past, of course.

As an ancillary measure, having a simple sub-registry (with FCFS
policy) for the respective parent namespace to help avoid name
collisions for X-* names might be considered, maybe with automatic
aging and removal after a given time span absent active renewal --
IANA reportedly is able to generically support timed events in
registries.

Just a thought ...

Opinions?

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Eric Burger <[email-masked]>
Date: Fri, 22 Oct 2010 13:50:33 -0400

Rock and hard place.

We want to encourage people to register these sorts of tags, whether for email, SIP, or fugel-frotz.  We want the bar to be very low.  Back "in the day," X-mumble was a free way of getting tags registered: you didn't have to register them at all.  That did cause all sorts of problems.

So what do we do now?  One of the value propositions for the Internet is the ability to experiment and try new things with very low overhead.  That would indicate we should make these registries first-come, first-served.  On the other hand, if something gets an IANA tag, the industry _assumes_ the IETF has blessed it.  The IETF wants interoperable, well-documented, open standards.  The problem is, if we even say "Informational RFC Required," that is a 4-year process, which basically makes the registry irrelevant.

I'm more in the free-love camp, let folks register what they want.  However, I may be in a minority on that point.

On Oct 21, 2010, at 4:30 PM, Alfred HÎnes wrote:

>  Alfred HÎnes.
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 22 Oct 2010 13:03:38 -0500

On Fri, Oct 22, 2010 at 01:50:33PM -0400, Eric Burger wrote:
> So what do we do now?  One of the value propositions for the Internet
> is the ability to experiment and try new things with very low
> overhead.  That would indicate we should make these registries
> first-come, first-served.  On the other hand, if something gets an
> IANA tag, the industry _assumes_ the IETF has blessed it.  The IETF
> wants interoperable, well-documented, open standards.  The problem is,
> if we even say "Informational RFC Required," that is a 4-year process,
> which basically makes the registry irrelevant.

Registries can require documentation in forms other than RFCs.  Although
I'd prefer to have RFCs.  For many X- headers the documentation would be
simple enough (a few paragraphs) while others require significant
documentation effort.

> I'm more in the free-love camp, let folks register what they want.
> However, I may be in a minority on that point.

I'd be OK with that too, as long as there's a registry and registrations
must contain a minimum of documentation as either of free-form text (no
more than 500 words, say) or RFCs.  I'd prefer something much more
formal, if it were realistic (but it's not).

Nico
--

---

From: Tony Hansen <[email-masked]>
Date: Sun, 24 Oct 2010 21:13:55 -0400

The vendor and personal namespaces used for media types have an 
extremely low overhead as well and are pretty darn close to your "free 
love" level.

I think adding such namespaces for headers would be cheap, easy to do, 
and would solve many of the problems people see with X-.

Thoughts?

     Tony Hansen
     [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Mon, 25 Oct 2010 02:58:30 -0400

--On Sunday, October 24, 2010 21:13 -0400 Tony Hansen
<[email-masked]> wrote:

> The vendor and personal namespaces used for media types have
> an extremely low overhead as well and are pretty darn close to
> your "free love" level.

Of course, they depend on structuring the type name.
Optional-field in RFC 5322 Section 3.6.8 does not anticipate
such structuring, but does not prohibit it either (nor does it
prohibit "X-"; it just doesn't give it any special
interpretation).  I don't believe I've seen enough use of, e.g.,
header field names with periods in them to prevent our making
that sort of structuring now.  But it is a little late in the
game and I wonder how long such a convention would require to be
widely deployed and recognized.

> I think adding such namespaces for headers would be cheap,
> easy to do, and would solve many of the problems people see
> with X-.
> 
> Thoughts?

For the reasons above, I question "cheap" and "easy to do",
although it certainly strikes me as a good idea.

   john

---

From: Eric Burger <[email-masked]>
Date: Mon, 25 Oct 2010 11:50:31 -0400

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

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 25 Oct 2010 13:08:32 -0400

> Well... Is not the problem that a proprietary extension

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

---

From: Graham Klyne <[email-masked]>
Date: Mon, 25 Oct 2010 19:40:24 +0100

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

I think not.  Or not much.

I keep wondering why RFC3864 [1] isn't more visible in this discussion: 
provisional registration is cheap and easy.  Where's the problem here that I'm 
not seeing?

[[
    The main requirements for a header field to be included in the
    provisional repository are that it MUST have a citable specification,
    and there MUST NOT be a corresponding entry (with same field name and
    protocol) in the permanent header field registry.
]]
-- RFC3864, section 4.2.2

#g
--

[1] http://tools.ietf.org/html/rfc3864

Eric Burger wrote:
> ------------------------------------------------------------------------
>

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 25 Oct 2010 15:02:51 -0400

On Mon, Oct 25, 2010 at 07:40:24PM +0100, Graham Klyne wrote:
> provisional registration is cheap and easy.  Where's the problem here 
> that I'm not seeing?
>
> [[
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

People have come to think that getting an RFC actually published is
hard, probably because we have made it hard.  For people who aren't
used to the IETF, simply publishing something here is like being
nibbled to death by ducks.

Note that I-Ds aren't citable specifications, according to the process
rules.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 25 Oct 2010 13:20:01 -0600

> avoiding dealing with IANA at all.

For syntax, base64 generates sequences that are valid according to the
field-name production of 5322.  Clark notation is a nice fit for the
URI/field tuple.  As such, this should work:

"B64-" + base64({uri}field-name) + ": " + value

The person/group that owns the URI owns the change control over that
uri/field tuple, and is responsible for forward- and backward-compatibility,
or changing the uri or field for incompatible changes.

The B64- prefix is intended to ensure that we don't overlap an existing
header by mistake, and to give a hint to third parties that if they
base64-decode the field name, they should get something interesting.

-- 
Joe Hildebrand

---

From: Graham Klyne <[email-masked]>
Date: Mon, 25 Oct 2010 21:11:08 +0100

Hi Andrew,

Thanks for explaining this perception.

The "citable specification" does not have to be an RFC - any document, e.g., on 
the web would do (though I tend to remind registrants that that internet drafts 
time out after 6 months).

So it seems the problem is with interpretation of "citable specification".  It 
was not intended to be restricted to "formally citable specifications" or 
suchlike, just something that could be referenced and retrieved by anyone.

This should be easily fixable.  Or is there a deeper problem?

#g
--

---

From: Eric Johnson <[email-masked]>
Date: Mon, 25 Oct 2010 13:48:23 -0700

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

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 26 Oct 2010 06:42:22 +0800

> namespaces really help the fundamental problem?

Namespaces are the root of the problem, aren't they?

X- is just a (slum) namespace.  Nothing works here.

Eric-mumble is worse because Albert doesn't like Eric and so he duplicates the functions in his own namespace rather than cede control to Eric.  (BTW, that's an argument I don't see in the draft.)

Better to make your extensibility simple.  How about having three tiers of "interoperability protection":

 IP-C: Anyone can use a header with any name they choose.  
 
       Use at own risk.

 IP-R: Anyone can register a header with any name.

       Collisions are less likely, not impossible.

 IP-S: RFCs* register headers with absolute exclusivity.

       Safe to use.

Because the name isn't scope or qualified, headers can increase their interoperability protection status without breaking implementations that already use it.  This encourages the registration of headers with appropriate names.

The registry provides a limited guarantee of uniqueness.

* An standards track registration - or something similarly strong - causes existing registrations for the same name get swept away.  The review process can determine if this is appropriate.

--Martin

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Oct 2010 16:46:28 -0600

On 10/25/10 4:42 PM, Thomson, Martin wrote:
> Eric-mumble is worse because Albert doesn't like Eric and so he
> duplicates the functions in his own namespace rather than cede
> control to Eric.  (BTW, that's an argument I don't see in the
> draft.)

Many arguments are not yet in the draft, and I shan't have time to
update it before the cutoff. But perhaps a discussion at the appsarea
meeting in Beijing would be productive.

> IP-S: RFCs* register headers with absolute exclusivity.

Could you compare / contrast to provisional vs. permanent registrations?
The latter distinction might give us most or all of what we need
(depending on which problem we're trying to solve).

> Because the name isn't scope or qualified, headers can increase their
> interoperability protection status without breaking implementations
> that already use it.  This encourages the registration of headers
> with appropriate names.
> 
> * An standards track registration - or something similarly strong -
> causes existing registrations for the same name get swept away.  The
> review process can determine if this is appropriate.

Fun. :)

Peter

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 26 Oct 2010 06:55:55 +0800

> (depending on which problem we're trying to solve).

A provisional registration would be similar to IP-R.  The only different is that two people can compete for the same name with IP-R; provisional registrations still have exclusivity.

Provisional registrations do the job pretty well.  But exclusivity seems unnecessary at this level of protection.  The main problems I was trying to address were:

 - informational registrations - it makes sense to have the registry document existing current practice, even if there is no intent to standardize a value, or intent to interoperate
 - old uses and current ones - some registrations might fall out of common use; rather than prevent the name from being picked up, this would let someone supplant the old name

> > review process can determine if this is appropriate.

Can you think of a better reason?
	
--Martin

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 25 Oct 2010 17:51:44 -0700

On 10/25/2010 3:42 PM, Thomson, Martin wrote:
> Eric-mumble is worse because Albert doesn't like Eric and so he duplicates
> the functions in his own namespace rather than cede control to Eric.  (BTW,
> that's an argument I don't see in the draft.)

Sorry, but that's a reasonable theoretical argument that has no practical 
application in this space.  If there were a practical problem, here, we'd have 
experienced it sometime in the past 28 years.

The actual experience is that fields become popular or they don't.  If they 
become popular, their name is not an -- or the -- issue.

The problem with X- is that a name beginning with that is prohibited from 
becoming a formal standard, even when every system in the world is using it. 
That's pretty dumb.

> "interoperability protection":

Why?  Why add structure where the market has demonstrated no need?

Really folks, as Graham noted, anyone wishing to reserve a name can do so easily:

    <http://tools.ietf.org/html/rfc3864 >

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Graham Klyne <[email-masked]>
Date: Tue, 26 Oct 2010 09:39:26 +0100

> A provisional registration would be similar to IP-R.  The only different is that two people can compete for the same name with IP-R; provisional registrations still have exclusivity.

Actually, for message headers they don't:

[[
    The main requirements for a header field to be included in the
    provisional repository are that it MUST have a citable specification,
    and there MUST NOT be a corresponding entry (with same field name and
    protocol) in the **permanent** header field registry.
]]
-- http://tools.ietf.org/html/rfc3864#section-4.2 (note my ** emphasis).

> Can you think of a better reason?

FWIW:
[[
    When a new entry is recorded in the permanent message header field
    registry, IANA will remove any corresponding entries (with the same
    field name and protocol) from the provisional registry.
]]
-- http://tools.ietf.org/html/rfc3864#section-4.3

(The main point here, as I recall, was that the provisional registry can't be 
used to make an unsupported "land grab" on the namespace:  community review trumps.

#g
--

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 27 Oct 2010 05:50:28 +0800

On 2010-10-26 at 19:39:26, Graham Klyne wrote:
> Thomson, Martin wrote:
> > provisional registrations still have exclusivity.
> 

My apologies, I just re-invented the wheel.  I should RTFRFC.

The current process is fine.