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. 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. 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. > Subject: RE: [Emu] #18 Internationalization > Date: Mon, 17 Aug 2009 15:06:22 -0700 > From: jsalo...@cisco.com > To: bernard_ab...@hotmail.com; emu@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_ab...@hotmail.com] > > Sent: Thursday, August 13, 2009 4:39 PM > > To: Joseph Salowey (jsalowey); emu@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: jsalo...@cisco.com > > > To: bernard_ab...@hotmail.com; emu@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-boun...@ietf.org [mailto:emu-boun...@ietf.org] > > On Behalf > > > > Of Bernard Aboba > > > > Sent: Monday, August 10, 2009 12:09 AM > > > > To: emu@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> > > > > > > > > > > > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
