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

["Adrian Farrel" <[e-mail]>]

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.
>
>
>