 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes, this makes more sense. > Subject: RE: [Emu] #18 Internationalization of error messages > Date: Tue, 8 Sep 2009 19:26:20 -0700 > From: jsalowey at cisco.com > To: bernard_aboba at hotmail.com; emu at ietf.org > > OK, makes sense. How about we make the language tags specific to text > sent from the server to the peer that is intended to be displayed to a > user. We can also specifically state that it is also acceptable to send > numeric codes that can be mapped to a specific representation by the > client to meet the internationalization requirement. These codes would > not be internationalized even if they were in ASCII/UTE-8 format. > > Does this make sense? > > Thanks, > > Joe > > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba at hotmail.com] > > Sent: Tuesday, September 08, 2009 7:09 PM > > To: Joseph Salowey (jsalowey); emu at ietf.org > > Subject: RE: [Emu] #18 Internationalization of error messages > > > > I don't have a problem with requiring support for UTF-8 in > > usernames and passwords within authentication mechanisms > > native to the tunnel method. However, I do have an issue > > with requiring internationalization of error message text. > > > > One of the principles of good protocol design is to *avoid* > > internationalization problems within error messages by use of > > error numbers (e.g. 404 in HTTP and SIP). This makes it > > possible for client software to display localized versions of > > error messages without requiring the server to support > > internationalization. > > > > If the tunnel protocol incorporates error numbers, it should > > therefore not be necessary for the server to send > > internationalized error text. > > > > Adding requirements for internationalization of error text or > > negotiation of language tags for error messages is not only > > unnecessary, it is actually enforcing a requirement for a > > *bad design*. > > > > > > > > > > > > |