Re: First reactions to mandatory draft

From: Henrik Frystyk Nielsen (frystyk@w3.org)
Date: Wed, Mar 11 1998


Message-Id: <3.0.5.32.19980311200204.00c997f0@localhost>
Date: Wed, 11 Mar 1998 20:02:04 -0500
To: "Ross Patterson" <Ross_Patterson@ns.reston.vmd.sterling.com>, ietf-http-ext@w3.org
From: Henrik Frystyk Nielsen <frystyk@w3.org>
Subject: Re: First reactions to mandatory draft

At 17:31 2/12/98 EST, Ross Patterson wrote:

>>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 ;-)

OK - bad examples (again). 

>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.

There are two reasons why they are general header fields and not request or
response header fields:

1) They describe which extensions are actually applied to a particular
message, which can be both a request and a response.

2) The type of implicit mandatory extensions that I think you are referring
to are already present in HTTP. Take for example the Content-Encoding
header field. A server can start using a content-coding without any
knowledge about whether the client can understand it or not.

The client on the other hand may or may not care - a simple GET tool that
doesn't do any rendering doesn't have to deal with it all and it would
therefore not be reasonable to require that it understands the coding.

I will send out some proposed wording to clarify this in a follow-up mail.

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk