Re: [apps-discuss] "X-" revisited

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

On 7/9/11 8:11 AM, John C Klensin wrote:
> 
> 
> --On Tuesday, July 05, 2011 21:52 -0600 Peter Saint-Andre
> <[e-mail]> wrote:
> 
>> On 6/27/11 12:36 PM, Peter Saint-Andre wrote:
>> ...
>> Based on list feedback, I've submitted a further revision
>> (including much more specific recommendations for spec authors
>> and implementers):
>>
>> http://www.ietf.org/id/draft-saintandre-xdash-01.txt
>>
>> Keep those cards and letters coming! ;-)
> 
> 
> Peter,
> 
> With the disclaimer that I'm still a fan of "x-" under very
> limited circumstances, a few observations that I think are
> complementary to some of those already made in this thread.
> 
> First, while you can reasonably argue that most applications for
> "X-" that are either "experimental" or even "extension" are
> bogus and can be handled in other ways, there are private-use
> cases that, IMO, remain legitimate.  Those private-use cases
> are, IMO, legitimate.  They are very similar to RFC 1918
> addresses: if something reaches you that contains an X-
> parameter, and the sender and receiver don't have a clear
> private agreement about what it means, then the correct action
> is to discard it or treat it is gibberish.  Those private
> agreements may require some degree of authentication, but that
> is a separate issue.  Note that "private use" really does imply
> "private": suggesting or requiring an IANA registration, no
> matter how lightweight, is out of line if only because it
> identifies the registrant.  

I agree that mandating registration of private parameters or extensions
is wrong.

> Your document implicitly assumes 

I think it would be helpful to make the assumptions explicit.

> that the world consists of
> public stuff that is intended to be standardized, public stuff
> that is experimental and not likely to be standardized, and
> things for which embedding organization names in the parameter
> (see below) are satisfactory.  I don't believe it.

You don't think those buckets exist, or you think that there are
additional buckets? The document does mention private stuff, and I agree
that private stuff needs to be handled differently.

> Second, remember that the motivation that took us down this path
> (see Dave's notes), and a motivation for IANA registration on
> parameters and the IANA itself, was to prevent two parties from
> accidentally using the same parameter value for different
> purposes and thereby causing serious interoperability problems.
> As Dave indirectly points out, we could have mandated
> arrangements like "X-BrandenburgInternetWorking.foo" or, more
> likely, "X-BrandenburgInternetWorking--foo".  But we didn't and,
> unless the DNS is used (which has its own set of problems,
> especially in the world ICANN is creating) it would just require
> the creation of another registry that would have to be managed
> and that might be controversial among intellectual property
> folks ("X-BrandenburgInternetWorking.foo" and "X-Klensin.foo"
> are probably fine, but "X-JoesPizza.foo" is the introduction to
> a nightmare).
> 
> To discourage a mandate for parameters to be registered with
> IANA is to encourage those interoperability problems.    At a
> minimum, if you are going to make that recommendation, its
> implications need to be explicitly discussed in Security
> Considerations.  I think it is a bad recommendation, even if
> some people will certainly ignore it.   Making it a useful
> recommendation, however, requires that the IETF get completely
> over its self-proclaimed role as an arbiter of taste in
> identifier names and descriptions.

I'm comfortable with saying that all parameters should be registered,
with a carve-out for truly private parameters. As you say, it appears
that many implementers will simply ignore the mandate.

> Similarly, if "you better know who sent this to you and what
> they think it means" is a "special meaning to parameters with
> the 'X-' prefix", then I think you are looking for other
> problems.  

By "special meaning" I was trying to capture only the assumption that
any parameter with the "X-" prefix is non-standard (and that any
parameter without the "X-" prefix is standard). Given the fact of
leakage from the non-standard space into the standard space, such an
assumption is unwarranted. I'll make this clearer in -02.

> FWIW, "X-JoesPizza.foo" (or just "JoesPizza.foo")
> involves the imputation of a special meaning by parsing the
> parameter string and isolating the "relevant organization's name
> or primary domain name".  Interestingly, from the way you write
> that recommendation, "foo.JoesPizza" is equally legitimate,
> after which it becomes really easy to fall back into the trap of
> conflicting names and interoperability problems.

You're right that humans tend to impute other meaning to strings by
parsing them into patterns that make sense. I see no solution to that
problem.

> Recommendation: There is too much history and you can't get this
> right without causing even more interoperability issues than we
> have today.  Private-use cases are legitimate and it is
> appropriate to provide some syntax that will identify them and
> shift the burden of figuring out what they mean to private
> agreements (and authentication of the parties to those
> agreements that is appropriate to the protocol in question).  
> 
> Encouraging more protocols to organize their parameters as
> trees, allow for vendor and personal trees, and define
> sufficient syntax and registries to actually make those trees
> work is actually a fine idea, but it may still not eliminate the
> need for private-use parameters.

What prevents an implementer with a truly private-use parameter from
assigning a UUID, a hash, or some other unmeaningful string of characters?

> Finally, two asides/nits:
> 
> (1) If you want to talk about "X-", your reference should be to
> RFC 5322 and its predecessors, not 5321, 

Yes, I'd already caught that bug in -01, it's fixed in -02.

> or you need more text.
> RFC 5321 (and its predecessors) use "X" (no hyphen") for
> private-use commands (and calls them that, not extensions or
> experiments, see Section 4.1.5).  "X-" is used only in passing
> and in an example discussing gateways in Section 3.7.1.  FWIW,
> my guess is that the leading "X" idea started with FTP and
> migrated, in "X-" form, to 822, but I don't remember (if I ever
> knew), so it is really just a guess.

Interesting. I just found the following in RFC 691:

   Thus, FTP servers which care about the distinction between Telnet
   print and non-print could implement SRVR N and SRVR T.  Ideally
   the SRVR parameters should be registered with Jon Postel to avoid
   conflicts, although it is not a disaster if two sites use the
   same parameter for different things.  I suggest that parameters
   be allowed to be more than one letter, and that an initial letter
   X be used for really local idiosyncracies.

This convention appears to have been used in some early FTP RFCs, such
as 737, 743, and 775 (mentioned in RFC 1123, as you point out).

> (2) While provisional URI schemes keep coming up as examples of
> how one might do these special extensions instead (as in your
> Section 2), I think a careful understanding of the history of
> "X-" to which people most object (and that RFC 1123 discusses in
> the context of experimental FTP commands, providing an example
> in its Section 4.1.3.1 that may be better than the two you cite
> and that is certainly earlier) suggests that the only thing
> "provisional" about a provisional registration is tolerance for
> rotten or missing documentation.  Just like a command or
> parameter starting in "X-" or "X", once the name associated with
> a provisional registration is used and incorporated into
> protocols, it is "used up": if the definition is changed, or
> even clarified in a way that eliminates some interpretations, it
> is usually better to select a new parameter string than to
> pretend that the new definition applies retroactively to the old
> parameter name. 

Yes.

> Even if you disagree with that, I think it
> deserves some discussion in the document if you are going to
> recommend provisional registrations as an option.

Agreed.

I'm not sure I'll have time to work these matters into -02 of the
document given time constraints today, but if not we'll do so in -03.

Peter

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