Re: First reactions to mandatory draft

Henrik Frystyk Nielsen <frystyk@w3.org> writes:

>In order to make progress in a timely fashion, PLEASE come with specific
>suggestions for changes in the current draft:
>
>http://www.w3.org/Protocols/HTTP/ietf-http-ext/draft-frystyk-http-mandatory

Having finally finished analyzing the 20 January 1998 "Mandatory
Extensions in HTTP" draft, I hope that's still the one you want comments
on.  A few issues come to mind:

   1) Section 3.1 "Header Field Prefixes" uses the term "agent", which
      is new in the HTTP context.  I presume it to mean "a thing that
      generates headers", and that it is explictly not the same as a
      "server", although I can't figure out why.

   2) The same section says "Agents SHOULD NOT reuse header-prefix
      values in the same message." I can see that this was carried over
      from (at least) the 21 November 1997 PEP draft, but I think it
      needs to be "MUST NOT".  After all, wouldn't reusing a header
      prefix effectively alter the header-field-set associated with the
      extension?

   3) Section 4.1 "End-to-End Extensions" states that "Proxies MAT act
      as both the initiator and the ultimate recipient of end-to-end
      extension declarations." This is another carryover from the PEP
      draft, but violates the normal IETF usage of "end-to-end".  I
      think I understand the intent, but I believe another term is
      needed for this "not-quite-end-to-not-quite-end" concept.  It may
      even be necessary to differentiate between end-to-end and
      sender-to-recipient extensions just as between end-to-end and
      hop-by-hop.  I'm not proposing that, but I can see the logic.

   4) The example in section 13.2 "Server Uses ZipFlate Compression
      Extension" is another simplified carry-over from the PEP draft,
      but calls out some very interesting issues that don't arise
      earlier in the document, at least not obviously:

         A) Man and Opt headers are general headers, not request
            headers.  That should have been implied by the example in
            section 4.1, but it wasn't stated clearly.  All the other
            uses in the document show only requests, not responses.  It
            wasn't until I went back and reread the PEP draft that I
            realized that Man and Opt were PEP and PEP-Info in sheep's
            clothing, and therefore obviously general headers.

         B) How can a Man header in a response to a GET be truly
            mandatory?  The server has no in-band indication that the
            client will honor the header instead of following HTTP 1.1
            rules and simply ingoring it.  I don't see a way around this
            short of increasing the HTTP version to at least 2.0.

All in all, I like this draft better than PEP as it's much less vague
about intent and usage.

Ross Patterson
Sterling Software, Inc.
VM Software Division

Received on Monday, 9 February 1998 13:55:33 UTC