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
