Subject: Re: Call for Adoption: draft-reschke-rfc54987bis

From: [email-masked]
Date: Wed, 1 Apr 2015 13:58:16 GMT

So we have to cope with legacy. not a huge problem.

Can we spec that *only* UTF-8 is valid charset to use this extension from now? That would make the ABNF delimiter not "*=" but "*=UTF-8".

The %-encoding restrictions can be updated for senders no problem if they are careful about decoding received or relayed escapes.

Amos

------ Original Message ------
From: Julian Reschke
Date: 01/04/2015 9:19 PM
To: Poul-Henning Kamp;Mark Nottingham;
Cc: HTTP Working Group;
Subject: Re: Call for Adoption: draft-reschke-rfc54987bis

On 2015-03-31 16:40, Poul-Henning Kamp wrote:
> --------
> In message <[email-masked]>, Mark Nottingham wri
> tes:
>
>> We discussed this document in Dallas:
>>
>>
>> Based on the feedback received, I believe that we should adopt this
>> document as a WG product, with a target of Proposed Standard.
>
> Solving the problem:  Yes, good idea.
>
> "Solving" it this way:  Bad idea.

It *has* been solved this way. This is not new.

> First, we're worried about transmission times for HTTP so making
> the charset selection per header-subfield is a horribly inefficient
> way to solve the problem.

Yes.

> Second, do we really want to make it possible to have one subfield
> of a header be KOIR8 and the next subfield be codepage 1251 ?

The spec clearly says that anything but UTF-8 might not be interoperable.

> Third, are there *any* valid reasons to even allow other charsets
> than ISO-8859-1 or UTF-8 from 2015 forward ?

This is a legacy encoding; it goes back to RFC 2231 (and even more).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Apr 2015 20:54:29 +0200

On 2015-04-01 15:58, [email-masked] wrote:
> Can we spec that *only* UTF-8 is valid charset to use this extension
> from now? That would make the ABNF delimiter not "*=" but "*=UTF-8".

It already says "MUST send UTF-8".

> ...

Best regards, Julian