Barry, > >> 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. It's somewhere in between, as things are definitely *not* OK at the moment, but my reason for suggesting a discussion with the précis folks is to take advantage of their insights and work to date. If I thought this draft needed to wait for the output of the précis WG, I would have indicated which précis draft ought to be a normative reference (and I did not do that). Whether that's a good idea will only be clear after every use of UTF8String is checked. FWIW, the FQDN situation is worked out, start with a normative reference to RFC 5890, which includes the specification of the various label types. > 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. My expectation is the same - if [RFCxxxx] is specified as "MUST implement" or "SHOULD implement", then I usually expect that RFC to be a normative reference. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.black@xxxxxxx Mobile: +1 (978) 394-7754 ----------------------------------------------------