Re: [Emu] #18 Internationalization

["Joseph Salowey (jsalowey)" <jsalowey at cisco.com>]

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba at hotmail.com] 
> Sent: Tuesday, August 18, 2009 7:10 AM
> To: Joseph Salowey (jsalowey); emu at ietf.org
> 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: jsalowey at cisco.com
> > To: bernard_aboba at hotmail.com; emu at ietf.org
> > 
> > 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:bernard_aboba at hotmail.com]
> > > Sent: Thursday, August 13, 2009 4:39 PM
> > > To: Joseph Salowey (jsalowey); emu at ietf.org
> > > 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: jsalowey at cisco.com
> > > > To: bernard_aboba at hotmail.com; emu at ietf.org
> > > > 
> > > > 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: emu-bounces at ietf.org [mailto:emu-bounces at ietf.org]
> > > On Behalf
> > > > > Of Bernard Aboba
> > > > > Sent: Monday, August 10, 2009 12:09 AM
> > > > > To: emu at ietf.org
> > > > > 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>
> > > > > 
> > > > > 
> > > 
> > > 
> 
>