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 4282bis as a snapshot of current
thinking.
[BA] That works for me.
Stefan> Pushing the requirement down to the EAP method won't work
Stefan> IMHO. Take as example EAP-TTLS in RFC5281. A full-text
Stefan> search for "UTF" in it yields 0 hits; and a look at section
Stefan> 7.3 ("EAP Identity Information") does not speak of any
Stefan> encodings.
[BA] You are right that a number of method specifications are deficient in the
internationalization area. However, I don't think that's an issue that an
ABFAB applicability statement can solve. Sam's proposed approach seems like
the only feasible one.
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 totally
different set of rules than the protocols.
That hell sucks too.
[BA] I totally agree.
Some EAP methods are going to care a lot. They'll care more about
passwords than they will usernames. Usernames are complex because they
can be carried in AAA, EAP identity and within a method.
[BA] Yes, but at least the method-specific identities and passwords are opaque
to the EAP core implementation and the AAA protocol.
we can write a guidance document for non-standards-track methods that> are
ambiguous giving the best advice we can. We can give good
requirements in standards-track methods. TEAP is in last-call now; I'm
fairly sure it gets this reasonably OK, but we should probably check
that.>> However, none of the above matters for this document.
[BA] Exactly. It's just an applicability statement, not a prescription for
world peace :)