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

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Nov 2016 07:37:24 +0100

Hi there,

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 
<https://github.com/httpwg/http-extensions/issues/267>.

One point he makes is that the fact that the parameter encoding doesn't 
have a proper name (other than "the encoding defined in...") makes it 
hard to talk about it in other specs.

So, given that we're after WGLC:

Would people object to naming this thing?

This would affect the abstract, the introduction, the title, and maybe 
some more places.

*If* the group is ok with this, would "IPE" (Internationalisation 
Parameter Encoding") be ok?

Best regards, Julian

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 17 Nov 2016 16:22:33 +0900

On 2016/11/17 15:37, Julian Reschke wrote:

> *If* the group is ok with this,

Giving things a name is usually a good idea.

> would "IPE" (Internationalisation Parameter Encoding") be ok?

First, it sounds grammatically wrong ("Internationalized Parameter 
Encoding" would be better, at least grammatically).

Second, it somehow pretends to be the only way to encode parameters with 
non-ascii values. To avoid that, I'd prefer something like "Legacy 
Internationalized Parameter Encoding". Other ideas welcome.

I still think that using UTF-8 directly for this purpose is the right 
way to go, in line with what the rest of the IETF and the Web are doing, 
and the earlier we get there, the better.

Regards,   Martin.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Nov 2016 08:42:46 +0100

> Internationalized Parameter Encoding". Other ideas welcome.

"LIPE" works for me.

> and the earlier we get there, the better.

Separate discussion :-)

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 17 Nov 2016 23:26:52 +0000

--------

><https://github.com/httpwg/http-extensions/issues/267>.

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 ; \
		type*=''white%20beer

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Nov 2016 00:37:47 +0100

> only makes room for utf8.

That's a leftover from where it originated. It only requires support for 
UTF-8, so that's the only thing you can reliably send.

> CS can obviously adopt that too.

I wouldn't go there.

> 	strings in HTTP-headers ?

That is true, but it really doesn't need to be stated here. It would be 
just advice anyway, right?

>         ascii, to allow people to specify only the language ?

We can't without breaking existing implementations.

> 		type*=iso8859-1'da'hvede%D8l ; \

RFC5987bis just defines what goes into the parameter value. Everything 
else is up to the definition of the header field. See also 
<https://greenbytes.de/tech/webdav/draft-ietf-httpbis-rfc5987bis-03.html#rfc.section.4.p.2>.

Best regards, Julian