W3C home > Mailing lists > Public > ietf-http-ext@w3.org > January to March 1998

Re: First reactions to mandatory draft

From: Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com>
Date: Thu, 12 Feb 98 17:31:48 EST
Message-Id: <199802122253.AA12686@reston.vmd.sterling.com>
To: ietf-http-ext@w3.org
Henrik Frystyk Nielsen <frystyk@w3.org> writes:

>At 13:54 2/9/98 EST, Ross Patterson wrote:
>>   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?
>The reason why I didn't make it a MUST is that for certain types of
>extensions adding or modifying a parameter makes sense. Take for example a
>hit-meter style extension. In mandatory this can be modelled as an optional
>end-to-end extension where caches that know about the extension may process
>it and add its result to the existing set of parameters; caches that don't
>can safely ignore it.

I see - you're contending that a smart proxy might act as the "ultimate
recipient" of the extension and alter the contents of the extension
headers.  I read the section to mean "It would be a good idea for
extensions to avoid choosing the same header-prefix for their headers
as one already in use within the HTTP message."  Read my way, it cries
out to be a MUST NOT, not a SHOULD NOT.  Read as you meant it, it
doesn't.  Perhaps you could find clearer terms to express the concept
you're aiming at.

>>         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.
>There are many types of extensions that are enforced out-of-band:
>Copyrights and other legal agreements are typical examples. In these, it
>does make sense for the server to include a mandatory extension declaration
>even though it doesn't know whether the client will obey it or not.

True, but here we're talking about computers exchanging information and
trying to cooperate, not lawyers trying to pick people's pockets ;-)

My point was that the draft makes a big deal out of the "mandatoryness"
of Man and C-Man headers, and rightfully so.  It goes so far as to define
the "M-" method prefix to ensure that servers that don't comply to the
draft will reject mandatory requests with something like a "405 Method
Not Allowed" response.  But when we get to the examples, we see a case
where the supposedly-mandatory header can and will be ignored by a client
or proxy that doesn't comply.  All of a sudden, "mandatory" starts to
look like "mandatory to compliant readers and optional to others", which
just doesn't sound right.

Ross Patterson
Sterling Software, Inc.
VM Software Division
Received on Thursday, 12 February 1998 17:49:51 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 1 July 2021 15:49:07 UTC