Subject: Re: [Emu] #18 Internationalization

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 8 Sep 2009 14:09:36 -0700

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, August 18, 2009 7:10 AM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: RE: [Emu] #18 Internationalization
> 
> The problem is that the internationalization language is too 
> general.  
> For example, Section 4.3.6 states:
> 
> 
> "  Any strings sent by the server intended for display to the 
> user MUST 
>    be sent in UTF-8 format and SHOULD be able to be marked 
> with language 
>    information and adapted to the user's language preference.
> "
> 
> This language applies to any string sent by the server, 
> regardless of whether it was sent as part of TLS, or an 
> existing EAP method.  Changing this to "Strings sent as part 
> of the tunnel method (e.g. not part of the tunneling protocol 
> or inner method)"
> would make more sense. 
> 
[Joe] OK, I created issue 25 to track this.  

> Also, we probably should make a distinction between numeric 
> and non-numeric strings.  Requiring numbers to be 
> internationalized (e.g. use of Arabic instead of ASCII 
> digits) is not probably not what was intended here. 
> 
[Joe] Can you clarify this?  If the intention is for display to a user
shouldn't the numbers be displayed in a format that makes sense in that
context?  

> Also, there are issues in Section 4.5.2:
> 
> "
>    The password authentication exchange MUST support user names and
>    passwords in international languages.  It MUST support encoding of
>    user name and password strings in UTF-8 [RFC3629] format.  Any
>    strings sent by the server during the password exchange 
> and intended
>    for display to the user MUST be sent in UTF-8 format and SHOULD be
>    able to be marked with language information and adapted to 
> the user's
>    language preference.
> "
> 
> Again, this section refers to "any strings sent by the 
> server", regardless of whether those strings are sent within 
> TLS or existing EAP methods.  The scope of this requirement 
> should be narrowed. 
> 
[Joe] This seems pretty clear that it is strings sent by the server
during the password exchange and not within the tunnel or some other
context.    

> > Subject: RE: [Emu] #18 Internationalization
> > Date: Mon, 17 Aug 2009 15:06:22 -0700
> > From: [email-masked]
> > To: [email-masked]; [email-masked]
> > 
> > The scope of the work is a method for transporting passwords. The 
> > requirements include appropriate internationalization support.
> > 
> > Section 4.6 covers requirements that existing EAP method not be 
> > modified by the tunnel. The sections that talk about 
> internationalization are:
> > 
> > 4.3.6 which discusses an optional requirement to have an attribute 
> > format for display strings that supports internationalization.
> > 
> > 4.5.2 which discusses the internationalization requirements for a 
> > password exchange.
> > 
> > If existing mechanisms do not meet the requirements for 
> > internationalization then either they will need to be 
> modified or new 
> > ones will need to be developed.
> > 
> > I'm not sure where the confusion exists, other than the 
> requirements 
> > for internationalization themselves.
> > 
> > Joe
> > 
> > > -----Original Message-----
> > > From: Bernard Aboba [mailto:[email-masked]]
> > > Sent: Thursday, August 13, 2009 4:39 PM
> > > To: Joseph Salowey (jsalowey); [email-masked]
> > > Subject: RE: [Emu] #18 Internationalization
> > > 
> > > Within Tunnel methods, exchanges of user names and passwords are 
> > > often accomplished either using TLS or existing EAP methods (e.g. 
> > > Identity or inner authentication methods). There are some tunnel 
> > > methods that have their own native authentication methods (e.g. 
> > > EAP-TTLSv0), but even those typically reuse functionality defined 
> > > previously (e.g. Diameter AVPs for PAP, CHAP, etc.).
> > > 
> > > Given that, I'd suggest that the scope of the 
> requirements needs to 
> > > be clarified. For example, support for negotiation of 
> language tags 
> > > might make sense for tunnel methods that carry such text in an 
> > > EAP-method specific way. However, a method that relies 
> solely on TLS 
> > > or existing EAP methods would not benefit from this 
> functionality, 
> > > and the requirements document should not imply that it is within 
> > > scope for proposals to change TLS, RFC 3748 or existing 
> EAP methods 
> > > so as to better support internationalization.
> > > 
> > > > Subject: RE: [Emu] #18 Internationalization
> > > > Date: Thu, 13 Aug 2009 12:31:59 -0700
> > > > From: [email-masked]
> > > > To: [email-masked]; [email-masked]
> > > > 
> > > > The core chartered requirements also include the use of 
> the tunnel 
> > > > method for password authentication, so it is important 
> to consider 
> > > > this case.
> > > > 
> > > > In addition, there is a proposal for defining conventions
> > > for defining
> > > > generic textual attributes within the tunnel. I think the main 
> > > > advantage of doing this would be to have a consistent 
> approach to 
> > > > internationalization. If this is too difficult, perhaps it
> > > should be
> > > > dropped, although I'm not sure these requirements would be too 
> > > > different form what is needed for password authentication.
> > > > 
> > > > Joe
> > > > 
> > > > > -----Original Message-----
> > > > > From: [email-masked] [mailto:[email-masked]]
> > > On Behalf
> > > > > Of Bernard Aboba
> > > > > Sent: Monday, August 10, 2009 12:09 AM
> > > > > To: [email-masked]
> > > > > Subject: Re: [Emu] #18 Internationalization
> > > > > 
> > > > > Joe Salowey said:
> > > > > 
> > > > > "
> > > > > #18: Internationalization
> > > > > 
> > > > > Is the use of UTF-8 sufficient or is other tagging necessary. 
> > > > > The following cases need to be considered:
> > > > > 
> > > > > 1. Usernames and passwords
> > > > > 2. Prompts and error associated with username and password 
> > > > > authentication 3. Other textual data "
> > > > > 
> > > > > It's important to keep in mind that this is a tunnel method 
> > > > > requirements document. The tunnel method will use TLS, so
> > > as far as
> > > > > bringing up the tunnel is concerned, it is TLS
> > > internationalization
> > > > > that is relevant here. With respect to inner
> > > authentication methods,
> > > > > it is the internationalization support of the inner 
> method that 
> > > > > matters.
> > > > > 
> > > > > Given this, what exactly is within the purview of the
> > > tunnel method
> > > > > with respect to internationalization? Clearly, the 
> EMU WG is not 
> > > > > chartered to change EAP itself, TLS or existing EAP methods.
> > > > > 
> > > > > Given that, what *exactly* does this requirement refer to? 
> > > > > While it's certainly possible for a tunnel method to 
> do language 
> > > > > negotiation, given that such a negotiation wouldn't
> > > affect most of
> > > > > what goes on in the method (e.g. TLS or the inner
> > > method), I don't
> > > > > see what good it would do.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > 
> <http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood>
> > > > > 
> > > > > 
> > > 
> > > 
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Sep 2009 19:09:25 -0700

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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 8 Sep 2009 19:26:20 -0700

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

> Sent: Tuesday, September 08, 2009 7:09 PM
> 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*.  
> 
> 
> 
> 
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 9 Sep 2009 12:36:54 -0700

Yes, this makes more sense. 

> Date: Tue, 8 Sep 2009 19:26:20 -0700
> From: [email-masked]