W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: RFC 5987bis WG last call - naming the encoding

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Thu, 17 Nov 2016 23:26:52 +0000
To: Julian Reschke <julian.reschke@gmx.de>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <7331.1479425212@critter.freebsd.dk>
In message <b65d5148-29f0-5e8b-9375-590ca8e52357@gmx.de>, Julian Reschke writes:

>I got some great feedback from one of our chairs who checked how this 
>impacts *his* work on RFC 5988bis (which refers to RFC 5987) -- see 

So, silly question time...

The stuff in RFC5987bis overlaps but is incompatible with the
utf8-string in the "common structure" draft I've written.

We should spend a moment deciding what to do about that.

RFC5987bis is more general, in the sense that you can specify any
character set you want, including BAUDOT and EBCDIC, whereas CS
only makes room for utf8.

CS can adopt the RFC5987 charset tagging, and instead of utf8_string
have a general "non-ascii-string"

RFC5987bis also allows you to specify an optional language,
CS can obviously adopt that too.

But now that I actually look at it, I have at least
three questions about it:

First:  The RFC5987bis draft doesn't mention the Accept-Language
        header with a single word.  If the client says it
	only understands elbonian, we shouldn't send it hungarian
	strings in HTTP-headers ?

Second: Should we also make the charset optional, defaulting to
        ascii, to allow people to specify only the language ?

Third: Shouldn't we allow alternative languages ?

In other words, should this be legal ?

	Content-Type: liquid/beverage ; \
		type*=utf-8'de'wei%C39Fbier ; \
		type*=iso8859-1'da'hvede%D8l ; \

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Thursday, 17 November 2016 23:27:22 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 17 November 2016 23:27:28 UTC