[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: REMINDER: Call for review of the "NAI-based Peer Discovery" document for acceptance as a RADEXT WG work item
> > Sounds good to me. The mangling would be: find first @ in User-Name,
> > chop off behind @, toss remainder to DNS library and hope for an answer.
> > Is that what you had in mind?
> It is a bit more complicated than that. See:
Thanks! An interesting read indeed!
Apart from finally having a black-on-white confirmation that I am naïve
[or naive?], it showed that
- Alan's recommendation to keep punycode mangling out of the RADIUS
application-layer processing and moving it to "the library" was a step
in the right direction
- my wording in -00 wasn't good enough to fully implement the IAB's
recommendation: it still leaves the question of private (possibly
$ANY_ENCODING) vs. public (ASCII + punycode) namespaces and/or a mixture
of the two (plus /etc/hosts resolution etc...).
I am thinking of modifying the algorithm, purging
"4. Generate R' = ( DNS library transformation of R to an FQDN in punycode)"
"6. Using the host's name resolution library, perform a NAPTR query for service "AAAS+RADSECT" for R"
which leaves it to the host configuration in which order, encoding,
postfixing with domain names etc. the conversion is done.
That leaves a bit of space for surprises when the server's library does
different conversions than a client's, but I tend to think that host
software configuration issues are out of the scope of this document.
Does that sound like a way out?
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
Tel: +352 424409 1
Fax: +352 422473
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.