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
--On Wednesday, July 17, 2013 07:56 -0700 Bernard Aboba
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 character set they have s
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
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 as
> "Stefan" == Stefan Winter 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 habitable.
This
> > [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
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
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
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 42
> 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
> "Stefan" == Stefan Winter 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 never sto
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
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 cal
> "Stephen" == Stephen Farrell 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 after reading your
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 wrote:
>
>> After reading this document, I believe that this document omits discussion
>> of an importa
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
> encoding
On 16 jul 2013, at 21:42, Bernard Aboba 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 to be encoded
> in UTF-
17 matches
Mail list logo
