> -----Original Message----- > From: Bernard Aboba [mailto:bernard_ab...@hotmail.com] > Sent: Tuesday, August 18, 2009 7:10 AM > To: Joseph Salowey (jsalowey); emu@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: 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
