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 totally >> different set of rules than the protocols. >> That hell sucks too. > > [BA] I totally agree. I'm joyfully naïve here. Right now, the receiving end has no guarantees about the encoding and normalisation of the incoming string. If it doesn't match its expectations in that regard, then that's unrecoverable. In the other hell, it can be sure to receive UTF-8 in NFC, and if that doesn't match what it needs, it can convert it. In my naïve thinking, that second hell is a lot less hot and much more habitable. Could you point out where my thinking goes wrong? Also: we're dealing with writing specifications here. If our specifications are correct, and some implementations do it wrong anyway - that's their problem, right? >> However, none of the above matters for this document. > > [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 one. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Attachment:
signature.asc
Description: OpenPGP digital signature