Re: #227: Encoding advice for new headers and parameters

On 2016-10-04 03:59, Mark Nottingham wrote:
>
>> On 29 Sep. 2016, at 11:48 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
>>
>> On 2016-09-28 04:29, Mark Nottingham wrote:
>>> [ "just me" hat on ]
>>>
>>> <https://github.com/httpwg/http-extensions/issues/227>
>>>
>>> After some discussion in Berlin and Stockholm, as well as experience with dealing with i18n in parameters for the Link header (see <https://github.com/mnot/I-D/issues/180>), I think we should give more definite advice about when RFC5987(bis) encoding should and should not be used.
>>>
>>> In particular, flagging encoding by using a parameter name complicates extension processing (see the issue referenced above), and causes a lot of uncertainty about precedence, etc.
>>
>> It complicates processing *slightly*.
>
> I'm not taking about parsing overhead, I'm talking about complication to the model for headers that use it -- as we saw in Link.

Yes, that's what I'm talking about as well. Reasoning about

   title=x; title*=UTF-8''y

is not that different than about

   title=x; title=y

>> The issue of parameters potentially repeating, and the fact that you need to define what to do in that case, exists in any way. It is inherent in any format that supports name/value pairs.
>
> Yes, but RFC5987 encoding complicates it further, because now you have the possibility of multiple parameters in two different encodings, and potentially different rules / precedences for each encoding.

I don't see how that makes it significantly harder. Furthermore, the old 
spec already recommends precedence (and that' what is implemented), and 
we can talk about strengthening that requirement.

>>> I think it would be much simpler and more reliable to advise people minting new HTTP headers to *not* use RFC5987(bis) encoding, but instead advise that they mandate use of an encoding on the field (or a specified portion thereof).
>>
>> RFC 5987 defines a way to deal with non-ASCII. It's not pretty, has a slightly bizarre syntax, but at least it's there, and it has been implemented successfully in all widely deployed user agents.
>
> I agree with all of that.
>
>
>> Defining *another* way to achieve this seems like a bad idea to me (insert XKCD reference here...).
>
> I didn't say we needed to define another one; I just think we should stop promoting this one.

Which IMHO leaves spec authors in a worse position.

> ...


Best regards, Julian

Received on Tuesday, 4 October 2016 05:53:16 UTC