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

On May 4, 10:09am, Henrik Frystyk Nielsen wrote:
> Subject: Proposed Resolution for Mandatory's end-to-end notion
>  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
>
(text deleted)
> 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
> --

Boy do I feel like the rat in this rat-hole.  If it is the consensus of
the group that we will not change the scoping rules in the extension
mechanism, then I believe that removing the current text and leaving
the situation as it is with HTTP/1.1 is the right answer.

I'm not sure, however, that leaving the scoping as it is now is the
best answer.  Henrik has written persuasively in previous messages
to demonstrate that the current scoping language  doesn't reflect
actual usage.  If that is the case, capturing that reality in appropriate
scoping rules seems to me like a good way to promote interoperability
among those applications which will use some scope other than
true hop-by-hop or end-to-end.

I'm also not sure when we will have another chance to make a change
to the scoping rules.  It seems logical to me to say that this is a
part of the framework needed to make HTTP truly extensible (
that need being demonstrated by the current use of ad hoc methods)
and that anyone using extended HTTP had better understand the
new scopes.

I understand that this does imply a change to HTTP/1.1 semantics.
The current spec already has one minor change to HTTP/1.1 semantics
(a special case to the basic principle of unordered headers).  I would
like to suggest that we accept those changes as part of what is needed
to get an extension mechanism going, rev the major number and say
HTTP/2.0 is HTTP/1.1 + the specified extension mechanism.

Henrik is right to worry about backwards compatibility issues, and
I respect that worry.  I submit, however, that the current applications
are muddling along with just 1.1 and will continue to do so.
If we want a clearer path forward for new extensions to HTTP, it
may be the right mooment to make the semantic changes we need and
take the hit.

		regards,
			Ted Hardie
			NASA NIC

PS.  I have talked about this privately to a number of people in
this group, and many were quietly horrified, so I won't be surprised
if anyone else is too.  So don't worry about calling me crazy in
your responses....

Received on Tuesday, 5 May 1998 19:01:56 UTC