Re: [Tsvwg] Fw: DISCUSS: draft-ietf-tsvwg-rsvp-user-error-spec

[Magnus Westerlund <[e-mail]>]

WG,

I have to say unless there is a really good reason, why not allow UTF-8. 
We also have to discuss if we should add language tags or not.

Cheers

Magnus


Adrian Farrel skrev:
> Hi,
> 
> Does anyone have any opinions on this Discuss?
> 
> Thanks,
> Adrian
> ----- Original Message ----- From: "Chris Newman" <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>; 
> <[e-mail]>
> Sent: Thursday, May 08, 2008 3:44 PM
> Subject: DISCUSS: draft-ietf-tsvwg-rsvp-user-error-spec
> 
> 
>> Discuss:
>> The IETF has a policy on character sets and languages (BCP #18, RFC
>> 2277) that I believe would apply to this protocol. If you believe BCP 18
>> / RFC 2277 does not apply, you need to make the argument why and
>> preferably do so in the document.
>>
>> While I applaud the realization that numeric codes alone are not
>> sufficient for debugging real-world product interactions, moving to the
>> richer solution (pairing numeric codes with freeform text and perhaps
>> parameters) comes with issues.  Do you allow multi-line text as is
>> useful if the error relates to a multi-line element or is complex to
>> explain clearly?  Do you allow text in the native language of the
>> admins/operators?  Do you tag the text with a language?
>>
>> In the SMTP world, we do get complaints about the English-only nature of
>> the protocol-level error text, and with Spam making it more important to
>> generate protocol-level errors instead of DSNs, these complaints will
>> only increase over time.  I expect we'll have to retro-fit language
>> support at some point and it will be painful (yes, there is a draft on
>> this floating around).
>>
>> My advise would be:
>>
>> 1. Allow for UTF-8/Net-Unicode (RFC 5198) so you never have to retro-fit
>> it, but encourage implementations to stick to single-line printable
>> US-ASCII whenever feasible.
>>
>> 2. Provide a way to tag the error with a language tag (BCP 47, RFC
>> 4646).  I can be talked out of this one as there is a complexity
>> tradeoff here, but it will be painful to retro-fit if you ever need it
>> later so do consider this seriously.
>>
>> 3. Suggest logging systems that are not UTF-8 capable or systems to
>> display the errors that are not UTF-8 capable encode according to RFC
>> 5137 / BCP 137.  Note that this also addresses the security
>> considerations that were raised by others.
>>
>> Thankfully, the RFCs I mention cover most of the nasty issues (including
>> security ones) so this can be done primarily by reference.
>>
>>
>>
> 
> 
> 


-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------