Re: SOAP IANA considerations

I don't think we are disagreeing in any unresolvable way.

Koen Holtman writes:

    OK, so we all want to promote interoperability, right?  But I am
    seeing a lot of disagreement in this thread about what rules for
    a HTTP header name registry would promote interoperability most.

That's a good point.  Promoting interoperability is certainly the
primary objective.  But I sense that a secondary objective (at least,
among some people) is a desire to provide differentiation between
"standard" and "non-standard" headers, since (as we saw in the
proliferation of HTML tags) the creation of new IDs is not without
potential negative consequences.  (Mostly lack of interoperability,
but sometimes more subtle than that.)

    As far as I am concerned it is crazy to try to use an IETF
    registry to force some minimal level of documentation
    requirements on all HTTP headers.  Implementing a new header is
    as simple as adding a line in a CGI script, and many people who
    have the need and ability to implement new headers will simply
    not care about getting formal IETF approval of their
    documentation, if they intend to publish documentation at all.

The value of having a registry that does require minimal
documentation is that (1) it encourages documentation, for people who
aren't entirely irresponsible, and (2) it allows us to define what
"interoperability" means with respect to a given header name.

Implementors who choose to add header names without going through
this process are thus (implicitly, at least) accepting the risk of
non-interoperability.  That is, they have only themselves to blame
if, later on, their software runs into interoperability bugs.

The catch here is that, if an implementor widely deploys a system
using a non-registered header, then this creates future problems for
standards-track extensions which inadvertently choose the same
header.  So, when Koen writes:

    It would be useful if somebody ran a service which helps
    everybody in picking new header names that nobody else is using
    yet.

I agree with him.

This suggests that the most effective approach (for maintaining
interoperability) is the creation of TWO lists.

    1. An IANA registry of "Standardized HTTP Headers" that only
    includes headers described in standards-track documents, or the
    equivalent.  (I would include "Best Current Practices" documents,
    since protocols such as HTTP/1.0 never entered the IETF Standards
    Track.)

    2. An IANA registry of "Known non-standardized HTTP Headers." The
    purpose of this list would simply be to publicize the use (or
    intended use) of header names, so as to avoid collisions.  As
    Koen wrote (my paraphrase), "to maximally promote
    interoperability [this index should] have very low requirements
    for registration.  In principle the *only* requirement for
    registering a header should be the honest intention to start
    using this header in internet HTTP-type traffic."  RFC2434
    explicitly allows this kind of FCFS registry.

I hope this two-pronged approach satisfies everyone, since we end up
with as much documentation as possible, without either unduly
burdening people trying experiments or application-specific
extensions, and without implying any approval of non-standards-track
extensions.

-Jeff

Received on Tuesday, 18 December 2001 22:55:15 UTC