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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 8 May 2008 16:02:52 +0100

Hi,

Does anyone have any opinions on this Discuss?

Thanks,
Adrian
----- Original Message ----- 
From: "Chris Newman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; 
<[email-masked]>
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.
>
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 09 May 2008 09:40:43 +0200

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:
> ----- Original Message ----- From: "Chris Newman" <[email-masked]>
> To: <[email-masked]>

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------