Loading ...
Sorry, an error occurred while loading the content.
 

RE: SOAP IANA considerations

Expand Messages
  • Larry Masinter
    I don t think that a registry of HTTP headers is appropriate, Rather, additional HTTP headers should be documented in IETF standards-track documents, if they
    Message 1 of 12 , Dec 6, 2001
      I don't think that a "registry" of HTTP headers is appropriate,
      Rather, additional HTTP headers should be documented in IETF
      standards-track documents, if they are to be considered extensions
      to the HTTP protocol defined by the IETF.

      It is useful to have an index of headers for implementers
      to know where various headers are defined (as, say, an update
      to RFC 2076), but such an index is not a registry.

      The HTTP protocol specification RFC 2616 does create IANA
      registries (for content-coding and transfer-coding
      value tokens) and makes reference to several others
      (for charset, media type, and language tags). That there is
      no registry for other protocol elements (headers and error codes)
      is not an accident.

      So I discourage you from trying to create a HTTP header
      registry so that you could add "SOAPAction" to it.

      Larry (as former HTTP WG chair)
      --
      http://larry.masinter.net
    • Mark Nottingham
      ... [...] ... That was the approach taken by the P3P WG. My motivation for asking was that, at the time, there was no clear way to put a stake in the ground
      Message 2 of 12 , Dec 6, 2001
        On Thu, Dec 06, 2001 at 02:35:45PM -0800, Larry Masinter wrote:
        > I don't think that a "registry" of HTTP headers is appropriate,
        > Rather, additional HTTP headers should be documented in IETF
        > standards-track documents, if they are to be considered extensions
        > to the HTTP protocol defined by the IETF.
        [...]
        > So I discourage you from trying to create a HTTP header
        > registry so that you could add "SOAPAction" to it.

        That was the approach taken by the P3P WG. My motivation for asking
        was that, at the time, there was no clear way to put a stake in the
        ground and claim a header, from a W3C perspective. The default was to
        use the HTTP extension framework.

        We eventually got advice that it would probably be good enough to
        publish an RFC, but it ate up a lot of time to get to that point. Of
        course, we probably just didn't ask the right people. ;)

        An index certainly would be a nice thing.

        Thanks,

        --
        Mark Nottingham
        http://www.mnot.net/
      • Jeffrey Mogul
        I don t think that a registry of HTTP headers is appropriate, Rather, additional HTTP headers should be documented in IETF standards-track documents, if they
        Message 3 of 12 , Dec 6, 2001
          I don't think that a "registry" of HTTP headers is appropriate,
          Rather, additional HTTP headers should be documented in IETF
          standards-track documents, if they are to be considered extensions
          to the HTTP protocol defined by the IETF.

          It is useful to have an index of headers for implementers
          to know where various headers are defined (as, say, an update
          to RFC 2076), but such an index is not a registry.

          I'm confused. First of all, about where the original message in this
          thread appeared (apparently not on HTTP-WG, but then I don't know how
          to find the original message).

          More particularly: I don't understand the conflict between the desire
          (on the part of at least one of you, apparently) to have an IANA "HTTP
          Headers Registry", and Larry's desire to see HTTP headers documented in
          IETF standards-track documents.

          As far as I can tell from reading RFC 2434, there is no conflict; the
          document that creates an IANA registry normally specifies some sort
          of review mechanism, and one "suggested" wording is:

          Specification Required - Values and their meaning must be
          documented in an RFC or other permanent and readily available
          reference, in sufficient detail so that interoperability
          between independent implementations is possible.

          I agree that it would be Darned Good Idea to have an HTTP Headers
          Registry administered by IANA, because otherwise I suspect we will
          end up with a chaotic situation as more RFCs generate more header
          names.

          So I think it would be appropriate to create an "IANA Considerations"
          section (logically part of the HTTP specification, but presumably in
          a separate document) that says something like:

          IANA Considerations

          The Internet Assigned Numbers Authority (IANA) administers the
          name space for HTTP header field-name values. Values and their
          meaning must be documented in an RFC, in sufficient detail
          so that interoperability between independent implementations is
          possible. Subject to these constraints, name assignments are
          First Come, First Served (see RFC2434).

          This registry initially consists of those header field-name
          values specified in RFC 2616, RFC 2617, [other RFCs TBD].

          Future RFCs that add values to this registry MUST provide an
          explicit list of such values in an "IANA Considerations" section,
          for the convenience of IANA in maintaining the registry.

          The list of "other RFCs" could be potentially fairly large, since
          there are a bunch of Experimental, Informational, or Proposed
          Standard RFCs listed on the HTTP-WG home page (in addition to the
          small set of Draft Standard RFCs).

          And, I suppose, some poor soul(s) would have to volunteer to help
          IANA glean the list of header names from all of these RFCs. But we
          might as well start now, rather than later.

          One more thing: I infer from the Subject line of this thread of
          messages that the intent is to create this registry as a section of
          the SOAP document. This is insane; it couples progress on
          establishing the registry to the progress of a much more complex
          technical design, and it hides the registry specification behind a
          title that most people would never suspect. (OK, how many people
          could guess the name of the RFC that defines the HTTP Status Code
          Registry, and no fair peeking at www.iana.org to find the
          back-pointer?)

          I'd suggest that we create a separate document called

          IANA Header Field-name Registry for HTTP

          that contains just the text above (and other necessary boilerplate)
          and be done with it.

          -Jeff
        • Mark Nottingham
          Jeff, The thread started here: http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0109.html I ve been meaning to do this for some time. If there s
          Message 4 of 12 , Dec 6, 2001
            Jeff,

            The thread started here:
            http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0109.html

            I've been meaning to do this for some time. If there's support, I'll
            be glad to be the poor soul. I agree that it shouldn't be coupled
            with SOAP's other registrations (as it appears to make people in that
            WG equally nervous).

            Larry, would you mind expanding upon this:
            > That there is no registry for other protocol elements (headers and
            > error codes) is not an accident.

            Cheers,



            On Thu, Dec 06, 2001 at 04:28:01PM -0800, Jeffrey Mogul wrote:
            > I don't think that a "registry" of HTTP headers is appropriate,
            > Rather, additional HTTP headers should be documented in IETF
            > standards-track documents, if they are to be considered extensions
            > to the HTTP protocol defined by the IETF.
            >
            > It is useful to have an index of headers for implementers
            > to know where various headers are defined (as, say, an update
            > to RFC 2076), but such an index is not a registry.
            >
            > I'm confused. First of all, about where the original message in this
            > thread appeared (apparently not on HTTP-WG, but then I don't know how
            > to find the original message).
            >
            > More particularly: I don't understand the conflict between the desire
            > (on the part of at least one of you, apparently) to have an IANA "HTTP
            > Headers Registry", and Larry's desire to see HTTP headers documented in
            > IETF standards-track documents.
            >
            > As far as I can tell from reading RFC 2434, there is no conflict; the
            > document that creates an IANA registry normally specifies some sort
            > of review mechanism, and one "suggested" wording is:
            >
            > Specification Required - Values and their meaning must be
            > documented in an RFC or other permanent and readily available
            > reference, in sufficient detail so that interoperability
            > between independent implementations is possible.
            >
            > I agree that it would be Darned Good Idea to have an HTTP Headers
            > Registry administered by IANA, because otherwise I suspect we will
            > end up with a chaotic situation as more RFCs generate more header
            > names.
            >
            > So I think it would be appropriate to create an "IANA Considerations"
            > section (logically part of the HTTP specification, but presumably in
            > a separate document) that says something like:
            >
            > IANA Considerations
            >
            > The Internet Assigned Numbers Authority (IANA) administers the
            > name space for HTTP header field-name values. Values and their
            > meaning must be documented in an RFC, in sufficient detail
            > so that interoperability between independent implementations is
            > possible. Subject to these constraints, name assignments are
            > First Come, First Served (see RFC2434).
            >
            > This registry initially consists of those header field-name
            > values specified in RFC 2616, RFC 2617, [other RFCs TBD].
            >
            > Future RFCs that add values to this registry MUST provide an
            > explicit list of such values in an "IANA Considerations" section,
            > for the convenience of IANA in maintaining the registry.
            >
            > The list of "other RFCs" could be potentially fairly large, since
            > there are a bunch of Experimental, Informational, or Proposed
            > Standard RFCs listed on the HTTP-WG home page (in addition to the
            > small set of Draft Standard RFCs).
            >
            > And, I suppose, some poor soul(s) would have to volunteer to help
            > IANA glean the list of header names from all of these RFCs. But we
            > might as well start now, rather than later.
            >
            > One more thing: I infer from the Subject line of this thread of
            > messages that the intent is to create this registry as a section of
            > the SOAP document. This is insane; it couples progress on
            > establishing the registry to the progress of a much more complex
            > technical design, and it hides the registry specification behind a
            > title that most people would never suspect. (OK, how many people
            > could guess the name of the RFC that defines the HTTP Status Code
            > Registry, and no fair peeking at www.iana.org to find the
            > back-pointer?)
            >
            > I'd suggest that we create a separate document called
            >
            > IANA Header Field-name Registry for HTTP
            >
            > that contains just the text above (and other necessary boilerplate)
            > and be done with it.
            >
            > -Jeff

            --
            Mark Nottingham
            http://www.mnot.net/
          • Joris Dobbelsteen
            This is IMHO rather about the fear that we get a HTTP Header Registry with numberous of useless headers, obstructing the creation of new useful headers. Using
            Message 5 of 12 , Dec 7, 2001
              This is IMHO rather about the fear that we get a HTTP Header Registry with
              numberous of useless headers, obstructing the creation of new useful
              headers. Using RFCs or a registry provides some advantages and
              disadvantages.

              The use of RFCs means that headers are generated with a useful description
              how they operate. It takes a lot of time for new headers to be documented,
              but I think this might be worth the effort, but only in some cases.

              On the other hand, creating a registry makes it possible to get a long list
              of mostly useless headers, you don't know where to use them for. If you want
              to set up a registry, ensure that you make some good RULES for adding
              headers to the list. Make sure the list doesn't get poluted: all the useless
              names.

              A domain name registries (e.g. the .nl domain) runs out of name-space,
              resulting in strange, stupid and funnie names. Even sentences without spaces
              are registered.

              Most companies just use there own headers for there products and I don't
              think they conflict with others. A registry ensures this doesn't happen.
              Some examples could be:

              - header names are reviewed. They must be supplied with a name and
              (generalized) description (of working). If agreed to the header, it's put on
              the list.
              - naming rules: add e.g. company or product name in the header

              General purpose headers must be published in RFCs, so others can use them.
              These don't follow the restrictions for the registry. I suppose you could
              combine both, in order to benefit from the little time needed to register a
              header on the registry and RFCs for general purpose headers, usable for
              multiple applications. This combines both strengths, but requires a
              registration policy...


              - Joris


              >-----Original Message-----
              >From: Jeffrey Mogul [mailto:mogul@...]
              >Sent: Friday, 7 December 2001 1:28
              >To: LMM@...
              >Cc: 'Mark Nottingham'; 'Graham Klyne'; 'Mark Baker'; mogul@...;
              >http-wg@...; xml-dist-app@...
              >Subject: Re: SOAP IANA considerations
              >
              >
              > I don't think that a "registry" of HTTP headers is appropriate,
              > Rather, additional HTTP headers should be documented in IETF
              > standards-track documents, if they are to be considered extensions
              > to the HTTP protocol defined by the IETF.
              >
              > It is useful to have an index of headers for implementers
              > to know where various headers are defined (as, say, an update
              > to RFC 2076), but such an index is not a registry.
              >
              >I'm confused. First of all, about where the original message in this
              >thread appeared (apparently not on HTTP-WG, but then I don't know how
              >to find the original message).
              >
              >More particularly: I don't understand the conflict between the desire
              >(on the part of at least one of you, apparently) to have an IANA "HTTP
              >Headers Registry", and Larry's desire to see HTTP headers documented in
              >IETF standards-track documents.
              >
              >As far as I can tell from reading RFC 2434, there is no conflict; the
              >document that creates an IANA registry normally specifies some sort
              >of review mechanism, and one "suggested" wording is:
              >
              > Specification Required - Values and their meaning must be
              > documented in an RFC or other permanent and readily available
              > reference, in sufficient detail so that interoperability
              > between independent implementations is possible.
              >
              >I agree that it would be Darned Good Idea to have an HTTP Headers
              >Registry administered by IANA, because otherwise I suspect we will
              >end up with a chaotic situation as more RFCs generate more header
              >names.
              >
              >So I think it would be appropriate to create an "IANA Considerations"
              >section (logically part of the HTTP specification, but presumably in
              >a separate document) that says something like:
              >
              > IANA Considerations
              >
              > The Internet Assigned Numbers Authority (IANA) administers the
              > name space for HTTP header field-name values. Values and their
              > meaning must be documented in an RFC, in sufficient detail
              > so that interoperability between independent implementations is
              > possible. Subject to these constraints, name assignments are
              > First Come, First Served (see RFC2434).
              >
              > This registry initially consists of those header field-name
              > values specified in RFC 2616, RFC 2617, [other RFCs TBD].
              >
              > Future RFCs that add values to this registry MUST provide an
              > explicit list of such values in an "IANA Considerations" section,
              > for the convenience of IANA in maintaining the registry.
              >
              >The list of "other RFCs" could be potentially fairly large, since
              >there are a bunch of Experimental, Informational, or Proposed
              >Standard RFCs listed on the HTTP-WG home page (in addition to the
              >small set of Draft Standard RFCs).
              >
              >And, I suppose, some poor soul(s) would have to volunteer to help
              >IANA glean the list of header names from all of these RFCs. But we
              >might as well start now, rather than later.
              >
              >One more thing: I infer from the Subject line of this thread of
              >messages that the intent is to create this registry as a section of
              >the SOAP document. This is insane; it couples progress on
              >establishing the registry to the progress of a much more complex
              >technical design, and it hides the registry specification behind a
              >title that most people would never suspect. (OK, how many people
              >could guess the name of the RFC that defines the HTTP Status Code
              >Registry, and no fair peeking at www.iana.org to find the
              >back-pointer?)
              >
              >I'd suggest that we create a separate document called
              >
              > IANA Header Field-name Registry for HTTP
              >
              >that contains just the text above (and other necessary boilerplate)
              >and be done with it.
              >
              >-Jeff
              >
              >
            • Jeffrey Mogul
              After reading your message several times, I *think* you agree that it would be a good idea to establish a registry, using the criterion that Values and their
              Message 6 of 12 , Dec 11, 2001
                After reading your message several times, I *think* you agree that
                it would be a good idea to establish a registry, using the criterion
                that "Values and their meaning must be documented in an RFC."

                But you write:

                On the other hand, creating a registry makes it possible to get a
                long list of mostly useless headers, you don't know where to use
                them for. If you want to set up a registry, ensure that you make
                some good RULES for adding headers to the list. Make sure the list
                doesn't get poluted: all the useless names.

                My initial thought was that the requirement that the header name
                be documented in an RFC was a high enough standard to meet; the IESG
                has not been very generous about allowing Internet-Drafts to become
                RFCs. If a specification makes it to the RFC stage, then this
                suggests it has had enough review to be "somewhat useful" rather
                than "mostly useless."

                I suppose that a case could be made that the requirement should
                be stricter, e.g., "Values and their meaning must be documented in
                *standards-track, historic, or informational* RFC". That is, don't
                let experimental RFCs add things to the registry.

                I'm not sure about this, though. We might be micro-managing.

                -Jeff
              • Larry Masinter
                I think that the requirement is not merely that the header is useful but that its interaction with the rest of HTTP has been analyzed and documented. Lots of
                Message 7 of 12 , Dec 12, 2001
                  I think that the requirement is not merely that the header is
                  "useful" but that its interaction with the rest of HTTP has
                  been analyzed and documented. Lots of header extensions are
                  poorly considered and not interoperable as documented.

                  The original motivation -- to allow "SOAPAction" as a HTTP
                  header by putting it in a registry that would be established
                  by the XML protocol group -- is pretty suspect. They don't
                  need a "registry" to allow SOAPAction, they need to document
                  how SOAPAction is used, what it means, and how to implement
                  it interoperably. Is it end-to-end or hop-to-hop? Is it allowed
                  in trailers as well as headers? Is it only allowed with requests,
                  responses, only some methods or with all? How does it interact
                  with other parts of HTTP semantics?

                  So I think that "Values and their meaning must be documented
                  in a RFC" is not adequate for HTTP headers. "Values and their meaning
                  and interaction with the rest of HTTP must be reviewed in
                  a standards-track update or extension to HTTP".

                  Of course there are lots of headers and extensions that aren't
                  documented in standards-track RFCs, but then those headers and
                  extensions aren't standard.

                  Otherwise, you'll see "Safe:" and "Accept-Additions:" in the
                  header registry.

                  > -----Original Message-----
                  > From: Jeffrey Mogul [mailto:mogul@...]
                  > Sent: Tuesday, December 11, 2001 11:29 AM
                  > To: Joris Dobbelsteen
                  > Cc: WWW WG (E-mail)
                  > Subject: Re: SOAP IANA considerations
                  >
                  >
                  > After reading your message several times, I *think* you agree that
                  > it would be a good idea to establish a registry, using the criterion
                  > that "Values and their meaning must be documented in an RFC."
                  >
                  > But you write:
                  >
                  > On the other hand, creating a registry makes it possible to get a
                  > long list of mostly useless headers, you don't know where to use
                  > them for. If you want to set up a registry, ensure that you make
                  > some good RULES for adding headers to the list. Make sure the list
                  > doesn't get poluted: all the useless names.
                  >
                  > My initial thought was that the requirement that the header name
                  > be documented in an RFC was a high enough standard to meet; the IESG
                  > has not been very generous about allowing Internet-Drafts to become
                  > RFCs. If a specification makes it to the RFC stage, then this
                  > suggests it has had enough review to be "somewhat useful" rather
                  > than "mostly useless."
                  >
                  > I suppose that a case could be made that the requirement should
                  > be stricter, e.g., "Values and their meaning must be documented in
                  > *standards-track, historic, or informational* RFC". That is, don't
                  > let experimental RFCs add things to the registry.
                  >
                  > I'm not sure about this, though. We might be micro-managing.
                  >
                  > -Jeff
                  >
                • Mark Baker
                  I believe Mark is busy with other things right now, so I ll hazard a response. ... Definitely. IIRC, Mark s thinking was that we would do all that, *and*
                  Message 8 of 12 , Dec 12, 2001
                    I believe Mark is busy with other things right now, so I'll hazard
                    a response.

                    > I think that the requirement is not merely that the header is
                    > "useful" but that its interaction with the rest of HTTP has
                    > been analyzed and documented. Lots of header extensions are
                    > poorly considered and not interoperable as documented.
                    >
                    > The original motivation -- to allow "SOAPAction" as a HTTP
                    > header by putting it in a registry that would be established
                    > by the XML protocol group -- is pretty suspect. They don't
                    > need a "registry" to allow SOAPAction, they need to document
                    > how SOAPAction is used, what it means, and how to implement
                    > it interoperably. Is it end-to-end or hop-to-hop? Is it allowed
                    > in trailers as well as headers? Is it only allowed with requests,
                    > responses, only some methods or with all? How does it interact
                    > with other parts of HTTP semantics?

                    Definitely. IIRC, Mark's thinking was that we would do all that, *and*
                    establish a registry for others to use. But I agree with the sentiment
                    here that we only really need an index, not a registry.

                    MB
                    --
                    Mark Baker, Chief Science Officer, Planetfred, Inc.
                    Ottawa, Ontario, CANADA. mbaker@...
                    http://www.markbaker.ca http://www.planetfred.com
                  • Joris Dobbelsteen
                    ... This points out that we should not use the word useful , as it s exact meaning is merely undescribed . What s the need of a registry is not to get
                    Message 9 of 12 , Dec 13, 2001
                      >-----Original Message-----
                      >From: Mark Baker [mailto:distobj@...]
                      >Sent: Wednesday, 12 December 2001 17:27
                      >To: LMM@...
                      >Cc: 'Jeffrey Mogul'; 'Joris Dobbelsteen'; http-wg@...
                      >Subject: Re: SOAP IANA considerations
                      >
                      >
                      >I believe Mark is busy with other things right now, so I'll hazard
                      >a response.
                      >
                      >> I think that the requirement is not merely that the header is
                      >> "useful" but that its interaction with the rest of HTTP has
                      >> been analyzed and documented. Lots of header extensions are
                      >> poorly considered and not interoperable as documented.

                      This points out that we should not use the word "useful", as it's exact
                      meaning is merely 'undescribed'.

                      What's the need of a registry is not to get conflicting headers and we want
                      to prevent headers that don't work well with the current HTTP standard, what
                      can be done more easily with RFCs.

                      >>
                      >> The original motivation -- to allow "SOAPAction" as a HTTP
                      >> header by putting it in a registry that would be established
                      >> by the XML protocol group -- is pretty suspect. They don't
                      >> need a "registry" to allow SOAPAction, they need to document
                      >> how SOAPAction is used, what it means, and how to implement
                      >> it interoperably. Is it end-to-end or hop-to-hop? Is it allowed

                      If new headers are defined and they are hop-to-hop, do the current proxies
                      and gateways know about this? This is only in the case of extending
                      currently existing hop-to-hop headers (like connection header).

                      >> in trailers as well as headers? Is it only allowed with requests,
                      >> responses, only some methods or with all? How does it interact
                      >> with other parts of HTTP semantics?
                      >
                      >Definitely. IIRC, Mark's thinking was that we would do all that, *and*
                      >establish a registry for others to use. But I agree with the sentiment
                      >here that we only really need an index, not a registry.

                      So setting up a registry must prevent 'poor headers' from appearing and
                      headers being used by more than once with different meanings. When using
                      RFCs, this is already ensured, but the two major complaints are that RFCs
                      take a long time to be published and we don't want a list of RFCs that just
                      handle HTTP extensions that are not meaningful to many applications (will
                      not be implemented in most products). Most companies don't take the time
                      needed to publish the RFC claiming there headers and giving a specification
                      of it.

                      So why a registry?
                      - Fast registration of headers
                      - No more (less?) conflicting headers (people register them)

                      But why RFCs?
                      - They will conform to the HTTP standard
                      - Others will know how it interacts with HTTP


                      I would like to (and will) end with note that using a registry doesn't mean
                      we should not require a description of the header any more, it can also mean
                      that we use the same procedure as RFCs, but that the 'registration time' is
                      dramatically shortened. This ensure 'good headers' to be registered.

                      Of course, already described headers cannot be overridden and must be kept.
                      Others should be prevented from registering headers with these names.

                      - Joris
                    • Koen Holtman
                      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
                      Message 10 of 12 , Dec 16, 2001
                        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.

                        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.

                        It would be useful if somebody ran a service which helps everybody in
                        picking new header names that nobody else is using yet. So in my
                        opinion, the only way to maximally promote interoperability here is to
                        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. Similar weak
                        requirements already apply to the vendor mime type registry and the
                        media feature tag registry.

                        Koen.
                      • Mark Nottingham
                        Hmm. I don t know if it s good/possible to maintain a registry of *all* HTTP headers in use. The original intent was to assure coordination between headers
                        Message 11 of 12 , Dec 16, 2001
                          Hmm. I don't know if it's good/possible to maintain a registry of
                          *all* HTTP headers in use. The original intent was to assure
                          coordination between headers that were standardised (or Recommended,
                          etc.) by organisations like the IETF, W3C, OASIS, etc. to assure that
                          there are no collisions, and to clarify the process. Imposing the
                          requirement for these headers to be a reasonable fit into HTTP isn't
                          such a bad thing, IMHO.

                          Vendors, third parties, etc. would have three choices;
                          1) meet the requirements by publishing an RFC
                          2) use the HTTP Extension framework
                          3) take their chances.

                          These are, of course, exactly the choices that they have today,
                          except that #1 isn't well-defined.




                          On Sun, Dec 16, 2001 at 05:29:02AM -0800, Koen Holtman wrote:
                          >
                          >
                          > 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.
                          >
                          > 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.
                          >
                          > It would be useful if somebody ran a service which helps everybody in
                          > picking new header names that nobody else is using yet. So in my
                          > opinion, the only way to maximally promote interoperability here is to
                          > 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. Similar weak
                          > requirements already apply to the vendor mime type registry and the
                          > media feature tag registry.
                          >
                          > Koen.
                          >

                          --
                          Mark Nottingham
                          http://www.mnot.net/
                        • Jeffrey Mogul
                          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
                          Message 12 of 12 , Dec 18, 2001
                            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
                          Your message has been successfully submitted and would be delivered to recipients shortly.