On Sun, Feb 10, 2013 at 7:15 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote: > Content-Type: text/plain; charset=ISO-8859-1 > -------- > In message < > CAK3OfOi+cXMLGsMCpD1cRBxzz46wVYYj8nz021fhqhM7fTDMWA@mail.gmail.com> > , Nico Williams writes: > > >> But how does the 2 ends agree on which encoding to use? It might be > >> easier if HTTP just dictate UTF-8. > > > >Not might be. Will be. > > Really ? > > I have a hard time squaring that with the "HTTP/2 is just a transport > protocol, we don't change the semantics" credo that was waved around > rather forcefully previously ? > > And if we are going to change semantics, shouldn't we change the > ones that really matter[1] ? > > Poul-Henning > > [1] We can probably do much more for transmission efficiency by killing > cookies and adding client provided session-identifieres, than any > kind of encoding or compression will ever be able to...[2] > > [2] Not to mention the improved privacy and legal compliance that > would automatically buy everybody... Changing from US-ASCII encoded URIs to UTF8 encoded IRIs would seem like a syntax issue to me, not semantics at all. Since we are looking at coding efficiency it seems to me that we should at least be open to specifying the length of the URI by means of a length prefix rather than a space or CRLF separator. So I can't see a reason not to consider UTF8 encoding of the URL which is only a syntax change when all is said and done. Giving it a different name does not make it semantic. Since the world is moving to UTF8, it would seem that getting HTTP fully in sync with UTF8 would be the main motive for applications to move to HTTP2. Unless we are looking for a full employment and a HTTP3 to follow. -- Website: http://hallambaker.com/
Received on Monday, 11 February 2013 01:50:17 UTC