RE-VERSION

Josh Cohen (josh@netscape.com)
Thu, 07 Aug 1997 22:30:20 -0700 

This is a cryptographically signed message in MIME format.

--------------msB8638AC447501967A956DF62
Content-Type: multipart/mixed; boundary="------------8DDDCAD1D3C95F5B71E85076"

This is a multi-part message in MIME format.
--------------8DDDCAD1D3C95F5B71E85076
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

-- 
-----------------------------------------------------------------------------
Josh Cohen <josh@netscape.com>		      Netscape Communications Corp.
http://people.netscape.com/josh/
                                "You can land on the sun, but only at night"
--------------8DDDCAD1D3C95F5B71E85076
Content-Type: text/plain; charset=us-ascii; name="RE-VERSION.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="RE-VERSION.txt"

Greetings,

	I apologize for the lateness in posting this to the list.

If you view the open issues for HTTP/1.1 and the agenda for the Munich
meeting, you'll notice an issue called 'RE-VERSION'.  After discussion
with the HTTP editors, I was encouraged to raise this issue on the list
and as an open item for HTTP.

The RE-VERSION essentiall boils down to the meaning of the
version in an HTTP/1.1 response.

I, and the editors, understand that this issue was heatedly and
deeply discussed previously, however, over the course of time, 
I do not beleive that the previous resolution is sufficient.

To summarize, the draft now indicates that the response version
should be the highest version supported by the server, NOT
the version of the actual HTTP response.

My problem with this is based on the assumption in the draft
which dictates that the response version is hop-by-hop.

Overall, I beleive that the response version should indicate
the version of the response message.

The problems encountered so far, in addition to any confusion
because the 'response version', isnt the response version,
are as follows:

A client sends a 1.0 request, a 1.1 server responds with 
a 1.1 response. ( minus certain http/1.1 features/headers).

GET http://foo/foo.html HTTP/1.0
blah: blahvalue

HTTP/1.1 200 Ok
blah: blahvalue

content...

When going through a proxy, how is the proxy supposed to maintain
the hop-by-hop nature of the responses?

Worse, if a 1.0 proxy is in the stream, it will blindly pass
the 1.1 response code back to the client, and clearly fails
to honor the hop-by-hop nature of the response.
(this is the case with squid, netscape proxy, and presumable others)
Previously, the 1.0 didnt clearly define what the behaviour
should be in this case.

On deciding what to send in a 1.1 response to a 1.0 client,
there is no canonical list of things which a 
server must not send when sending a 1.1 labeled response
to a 1.0 server. There will surely be more than just
chunked encoding.. This seems like a nightmare for
proxy/server implementors dictating constant maintenance
releases to block new server reponse features/headers
from being sent to 1.0 clients.
( how can it be prepared to block something which hasn't
  been invented yet?)

The only reason I could find in the previous discussion
for this behavior was to allow partial implementations
to take advantage of some 1.1 features, but not all.
These days, since a great deal of the most contentious
features have been separated from the core http/1.1 draft,
I dont think its too much to ask for a reasonably
compliant implementation that can at least deal with
all the core http/1.1 headers/features.

Lets say Im implement a client that understands
cache-control ( IMHO a valuable 1.1 feature ),
but is 1.0 otherwise.  Should a server send
a cache-control: directive or the usual ugliness
of removing the last-modified: header? (or some other way).
Or should it send both? (subverting the usefulness
of the cache-control making it redundant)

Finally, with things the way they are, does the response
version actually mean anything useful?  How useful is knowing
what the highest version supported by the server?
Wouldnt knowing the version of the actual response message
be more useful and less ambiguous?

The way I see it we have these options:

1) leave as-is, keeping the broken hop-by-hop behaviour
   ( but vigorously specify what must not be sent to a 
	1.0 client in a 1.1 labeled response )

2) make the response version = the request version.

3) create an additional 'response-version: ' header
   to indicate the message version in use.

4) keep the same rules in the draft, but make our version
   2.0. ( which will mean that the server must send a 1.x
	response to a 1.x client )


Personally, I think the right thing to do is #2.
Yes, this will have some effect on the current implementations.
However:

1) the effect shouldnt put them in any worse position than they
   already are. ( still broken )

2) The IETF process draft/draft standard rfc/proposed standard rfc etc,
   is meant to allow changes.  Implementing a draft implies that changes
   will need to be made.


(Im sure Im missing some issues or other stuff.. feel free to comment :)

--------------8DDDCAD1D3C95F5B71E85076--

--------------msB8638AC447501967A956DF62
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIGvwYJKoZIhvcNAQcCoIIGsDCCBqwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BSYwggJlMIIBzqADAgECAgIEtTANBgkqhkiG9w0BAQQFADB3MQswCQYDVQQGEwJVUzEsMCoG
A1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNVBAsTE0lu
Zm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20wHhcNOTcw
NjE4MDMzNDM0WhcNOTcxMjE1MDMzNDM0WjCBhDELMAkGA1UEBhMCVVMxJjAkBgNVBAoTHU5l
dHNjYXBlIENvbW11bmljYXRpb25zIENvcnAuMRUwEwYDVQQDEwxKb3NoIFIgQ29oZW4xIDAe
BgkqhkiG9w0BCQEWEWpvc2hAbmV0c2NhcGUuY29tMRQwEgYKCZImiZPyLGQBARMEam9zaDBc
MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDOhb62VH0eutOs2TOSlez9LDZ/Npc7WOR0A/noE6GI
sVnEiwsa3smYNsXPNdMOrTV/IeLhIh2WMlog8lAxDGidAgMBAAGjNjA0MBEGCWCGSAGG+EIB
AQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9w0BAQQF
AAOBgQCD8SxLEPSi8sO9sY3dUNOvFhrZe1IzQ/mPDWFKlMz8VnN+jyPXaL7rfmIhpAz2Q58W
tyU7x5qxw/pTbna9bYL+C/SWyXY6bKSvowl0adPrA0jxSkx1EmSwmpXSgSiotcSZhfWtmcBh
lw/xn5ImodY7lrgybtG3RV6sZAWjsODEVDCCArkwggIioAMCAQICAQEwDQYJKoZIhvcNAQEE
BQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENv
cnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNyb290
Y2EubmV0c2NhcGUuY29tMB4XDTk3MDMyNjAxNDQzOFoXDTk5MDMyNjAxNDQzOFowdzELMAkG
A1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9u
MRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2Nh
cGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDBqj7+LT+lh8NH3/vabdgYoEU9
+cebQ84ntFoTnBF9v9LyiF7Hv7KLebqn5SgLQKaOmTFVxfjOlgZeIoR2vwEiYsOpmSe7CGgR
FMcKftyyh/jH4CQwAbwtloXnGcMuoZN3LDQYL/vfokiz56CvegPki4x1pC2TIIwgOVSnRbpA
ZQIDAQABo1UwUzARBglghkgBhvhCAQEEBAMCAAQwHQYDVR0OBBYEFPzgVOgH8ZXeOveZxq76
FQxuxC6SMB8GA1UdIwQYMBaAFPzgVOgH8ZXeOveZxq76FQxuxC6SMA0GCSqGSIb3DQEBBAUA
A4GBAFn32xtcegbE5sWYYYQYzvoGSyCxJMr8WX4/GPHkvqwQ2UrSaY9u/JHK9QQcCq65+so5
7E0AGaZnlMzlQFtZhCSS8AEsGeQLLzsc9g8bhUXsw5fx4LpAy91XcYngi0lwSR/dtss0b2/P
LyHkU9EZZo9nYvDd7h1IKvBHe4N0h3nIMYIBYTCCAV0CAQEwfTB3MQswCQYDVQQGEwJVUzEs
MCoGA1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNVBAsT
E0luZm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20CAgS1
MAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw05NzA4MDgwNTMwMjFaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwIwYJKoZI
hvcNAQkEMRYEFIYPw2koi9pykpWSfhuAKYBiZhG8MA0GCSqGSIb3DQEBAQUABEAPAP6PZfR2
BmFVD9C2xJk3/Sf3o8WqBFRqii2zwMrxDiiLHOn4vH/vUYGTWPYYax2YM73f4vCWMSWrNe20
3S6M
--------------msB8638AC447501967A956DF62--