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

Proposed Resolution for Mandatory's end-to-end notion

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Mon, 04 May 1998 10:09:29 -0400
Message-Id: <>
To: ietf-http-ext@w3.org
 There has been significant discussion on this topic but I think that we
should try and reach closure ASAP and move on.

I therefore suggest that we do just like the HTTP/1.1 spec - that is we
duck the question of defining who the ultimate recipient really is and
leave it as an implementation issue. That is, I remove the explanatory text
in section 4.1

The ultimate recipient of an end-to-end extension declaration would often
be but is not limited to either the origin server or the user agent.
Proxies MAY act as both the initiator and the ultimate recipient of
end-to-end extension declarations. It is outside the scope of this
specification to define how an agreement is reached between a party
representing the proxy and the party on whose behalf it can act, but, for
example, the parties may be within the same trust domain.

If a proxy is the ultimate recipient of a mandatory end-to-end extension
declaration then it MUST handle that extension declaration as described in
section 55. The proxy SHOULD remove all parts of the extension declaration
from the message before forwarding it.

and instead write that the Mandatory notion of end-to-end is exactly as in
HTTP. If people want to be creative then they can do so but the spec is
silent about it - just like in HTTP.

I do not feel comfortable trying to impose different scoping rules for
mandatory than already present in HTTP. This would cause a lot of very hard
backwards compatibility problems with existing HTTP applications.

I also hear a lot of arguments saying that it is also not the place to try
and be more explicit about the scoping rules than HTTP is. Therefore the
proposed compromise.

Any objections?

Henrik Frystyk Nielsen,
World Wide Web Consortium
Received on Monday, 4 May 1998 10:09:31 UTC

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