5) Statement that the string contains an FQDN, as stated for one case of
the Tunnel-Client-Endpoint AVP in 4.5.4. That specific statement is
incomplete, as it needs to be accompanied by a normative reference to
a document that specifies the format of internationalized domain
names, and probably needs to also state which types of labels (e.g.,
A-label, U-label) are allowed.
Every use of UTF8String in this draft needs to be checked, and most
of them are likely to need some attention. The ongoing work in the
precis WG may help with some of this, and I would suggest talking to
the APP ADs, especially Pete Resnick (hi Pete) before embarking on
significant work in this area in order to avoid wasted or duplicated
efforts.
OK, this last one bothers me a lot: you /seem /to be suggesting that we hold
up this draft to wait for the result of a WG which has yet to publish a
problem statement. I'm sure that that is not the case, but it sure sounds
like it.
David can clarify if I'm wrong, but that's not what it sounds like to
me. What it sounds like he's suggesting is that you talk with the
precis people to see if things are OK, or if there's anything you
should be doing differently. I'm adding the precis chairs to this
message, and asking them to respond to this point.
A tangential point, while I'm here:
[4] Based on this text in 4.4.9:
The use of this AVP is NOT RECOMMENDED; the AVPs defined by
Korhonen, et al. [RFC5777] SHOULD be used instead.
I would have expected RFC5777 to be a Normative Reference, not an
Informative Reference.
I don't care particularly, but I don't think that it's really necessary to
understand RFC 5777 to understand this document.
It would seem odd, in general, if something that's a "MUST implement"
or "SHOULD implement" weren't a normative reference. But I haven't
(yet) looked at this particular case to see.
Barry