Re: Call for Adoption: draft-reschke-rfc54987bis

[[e-mail]]

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 <[e-mail]>, 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