Re: Call for Adoption: draft-reschke-rfc54987bis

[Julian Reschke <[e-mail]>]

On 2015-04-01 21:12, Willy Tarreau wrote:
> Hi Julian,
>
> On Wed, Apr 01, 2015 at 10:09:16AM +0200, Julian Reschke wrote:
>> On 2015-03-31 22:56, Poul-Henning Kamp wrote:
>>> --------
>>> In message <[e-mail]>, Willy Tarreau writes:
>>>
>>>>> Third, are there *any* valid reasons to even allow other charsets
>>>>> than ISO-8859-1 or UTF-8 from 2015 forward ?
>>>>
>>>> Idem. And if we don't need to do more than that, then probably we
>>>> just need a boolean to say "this is not ISO-8859-1, hence this is
>>>> UTF-8" and make the encoding implicit by the sole presence of the
>>>> encoding tag (eg: the "*" or "=", I don't remember right now).
>>>
>>> In that case I could live with it being per field, because the
>>> signal could be a single character and we could probably
>>> dispense with the % encoding too.
>>
>> Friends, this is not a new format. It is implemented in all major user
>> agents, so it really doesn't make sense to invent a new shorter syntax
>> approximately 15 years after this has been defined first.
>
> Thanks for the info, I wasn't aware of it at all. So just for our
> understanding, could you explain in a few words what in your proposal
> differs from what already exists, or whether it standardizes something
> already used as a de-facto standard maybe ?

The major differences would be:

- remove ISO-8859-1 from the set of required encodings, and

- better integration with the httpbis specs.

> I'm just trying to figure the level of flexibility that remains here.
> I must confess I don't feel very safe with having to parse any attribute
> this way if I need one. For instance, "q=0" for a compression token
> generally works fine, but its equivalent encoded form might probably
> not be handled by most servers. And for a gateway, having to do this
> n any header field might seem overkill at first glance.

It's an optional encoding; it only applies to those parameter fields 
where the spec explicitly allows it (such as Content-Disposition).

Best regards, Julian