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
The appeal from Mr. Morfin was received on 8 July 2013; it can be found here:
http://www.iab.org/wp-content/IAB-uploads/2013/07/appeal-morfin-2013-07-08.pdf.
Mr. Morfin's appeal concerns RFC 6852. While the appeal does not state
any objection to any of the content of RFC 6852, Mr. Morfin wishes
Hi all,
This is a reminder that, based on discussions during IETF 86, we are
trialing an IETF mentoring program. During this trial period, we would like to
pair newcomers (people who have attended 3 or fewer meetings or have registered
as students) with existing IETF participants. The
All,
During IETF 87 in Berlin, we will be running a trial of the IETF Mentoring
Program. The goal of the IETF Mentoring Program is to match people new to the
IETF (people who have participated in three or fewer face-to-face meetings or
anyone registering as a student) with experienced IETF
A new Request for Comments is now available in online RFC libraries.
RFC 6982
Title: Improving Awareness of Running Code:
The Implementation Status Section
Author: Y. Sheffer, A. Farrel
Status: Experimental
Hi all,
This is a reminder that, based on discussions during IETF 86, we are
trialing an IETF mentoring program. During this trial period, we would like to
pair newcomers (people who have attended 3 or fewer meetings or have registered
as students) with existing IETF participants. The
All,
During IETF 87 in Berlin, we will be running a trial of the IETF Mentoring
Program. The goal of the IETF Mentoring Program is to match people new to the
IETF (people who have participated in three or fewer face-to-face meetings or
anyone registering as a student) with experienced IETF
20 matches
Mail list logo