--On Wednesday, July 17, 2013 07:56 -0700 Bernard Aboba
bernard_ab...@hotmail.com wrote:
Sam said:
We don't get to place requirements on applications except to
say what they need to do to use EAP. The protocol
requirement for that is that applications using EAP need to
know what
Hi,
We don't get to place requirements on applications except to say what
they need to do to use EAP. The protocol requirement for that is that
applications using EAP need to know what character set they have so that
EAP can convert the identity to UTF-8 and so that EAP methods can do any
Hi,
After reading this document, I believe that this document omits
discussion of an important aspect, which is internationalization.
Since the contents of the EAP Identity and RADIUS User-Name attributes
are specified to be encoded in UTF-8, application protocols that utilize
encodings
Hi Bernard, Patrik,
Thanks for the comment. Checking that out now and will
get back.
Cheers,
S.
On 07/17/2013 05:29 AM, Patrik Fältström wrote:
On 16 jul 2013, at 21:42, Bernard Aboba bernard_ab...@hotmail.com wrote:
After reading this document, I believe that this document omits
Stephen == Stephen Farrell stephen.farr...@cs.tcd.ie writes:
Stephen Hi Bernard, Patrik,
Stephen Thanks for the comment. Checking that out now and will get
Stephen back.
Bernard, thanks for the comment. I expected to feel really frustrated
at how late the comment was sent but
Hi,
I think assuming that 4282bis has reached consensus on
internationalization is wildly wishful thinking at this stage. I
continue to be dubious that the right parties are involved in the
discussion and even if we have consensus in radext expect significant
discussion at ietf last call,
Hi,
Pushing the requirement down to the EAP method won't work IMHO.
Further to this: now that I have EAP-TTLS on screen, its words of wisdom
about EAP type selection show that it won't work quite clearly. And they
are valid beyond EAP-TTLS. Section 7.3 of RFC5281 states:
Note that at the time
Stefan == Stefan Winter stefan.win...@restena.lu writes:
However, I absolutely agree that if an application is going to
use EAP it needs to follow EAP's i18n conventions whatever those
may be. A rrequirement on anti-causal investigation for current
implementation efforts has
The question is: this document is about an applicability update, not a
change of the on-the-wire behaviour of EAP.
[BA] That's right -- which is why I see no need for the applicability update to
depend on RFC 4282bis. It just needs to discuss the applicability aspects.
If we were to try
Sam said:
My recommendation is that we point out the issue. And say that
strings used within a specific EAP method MUST follow the rules
for that method. If AAA is used, strings used within AAA MUST
follow the rules for the AAA protocol in use. We can add an
informative citation to
Hi,
Sam said:
Nah, you'd just be living in a different hell if you'd been explicit in
the EAP spec. I know: other parts of the IETF are in that hell. The
protocols are clear and everything is fine until you realize that the
backend authentication systems you're dealing with are using a
Hi,
[BA] We are just talking about core EAP and RADIUS RFCs here.
Internationalization of method-specific identities (and passwords) is
defined by the EAP method specifications, so the Identities UTF-8
everywhere is a much broader topic (and one which I'd argue is not
relevant to an ABFAB
[BA] Exactly. It's just an applicability statement, not a prescription
for world peace :)
Sure: we need more than an applicability statement update to achieve
peace in the EAP world. But if an applicability statement update is all
we can work with, we could try and do our best in that
Stefan == Stefan Winter stefan.win...@restena.lu writes:
Stefan In the other hell, it can be sure to receive UTF-8 in NFC,
Stefan and if that doesn't match what it needs, it can convert it.
Stefan In my naïve thinking, that second hell is a lot less hot
Stefan and much more
Sam said:
We don't get to place requirements on applications except to say what
they need to do to use EAP. The protocol requirement for that is that
applications using EAP need to know what character set they have so that
EAP can convert the identity to UTF-8 and so that EAP methods can do
Also, note that the important thing is not that applications use UTF-8
for usernames.
It's that they know what character set they are using and follow EAP's
(lack of) rules when using EAP.
In general, I would not expect an application to encode a username
that's also used in EAP authentication
After reading this document, I believe that this document omits discussion of
an important aspect, which is internationalization. Since the contents of the
EAP Identity and RADIUS User-Name attributes are specified to be encoded in
UTF-8, application protocols that utilize encodings other
On 16 jul 2013, at 21:42, Bernard Aboba bernard_ab...@hotmail.com wrote:
After reading this document, I believe that this document omits discussion of
an important aspect, which is internationalization. Since the contents of
the EAP Identity and RADIUS User-Name attributes are specified
18 matches
Mail list logo
