Re: Call for Adoption: draft-reschke-rfc54987bis

[Willy Tarreau <[e-mail]>]

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 ?

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.

Best regards,
Willy