Document: draft-ietf-enum-iris-ereg-02.txt Reviewer: Elwyn Davies [elwynd@dial.pipex.com] Review Date: Tuesday 11/29/2005 4:45 PM CST Telechat Date: Thursday 12/01/2005 Summary: This draft has not been updated since my last call comments. The authors, WG chair, Alison and I had a constructive discussion and I believe updates are pending. I feel it should be revised before approval and I think that was agreed. -------------------------------------------------------------------------------- Review Date: Tuesday 10/25/2005 8:09 AM CST IETF LC/Telechat Date: Thursday 10/27/2005 Summary: This document is nearly ready for Proposed Standard, but there are a number of issues relating to the complexities of internationalization and string matching which I believe need sorting out. There are also a few areas where the descriptions of the xml in Section 3 are a little sloppy - I feel there is a tendency to rely on the formalism of the xml schema to be the ultimate determinant. There are also some editorial nits. Caveat: I assuming that the xml schema has been checked by a suitable parser. Review: ------- The document is generally in good shape: I have assumed that the xml schema in section 4 has been checked by a parser and have not studied it in detail other than in a couple of places where the descriptions in s3 were rather sloppy to the extent that I could not make out what was implied other than by reading the schema. Issues: Language issues: ================ language specifiers: The base IRIS specification RFC3981 points up (in the Internationalization section) that language strings (which are talked about extensively) are defined through the W3C XML Schema Part 1 (Structures). I think it would be worth repeating this paragraph in this document (in para 2 of s7). I also note that the W3C document is now very out of date... it points back to RFC1766 which has long been superseded by RFC3066 and more recently the new Language Tags registry has been approved. Presumably it is intended that this new sort of tag should be supported now? s3.1.2: last para: This would be a good point to give a pointer to the Internationalization section and an indication of what strings language tags contain (as per discussion above). s3.2.5: element description: " - a specification of the language code to use to localize the data in *this result*.": It is my understanding that there might potentially be multiple items (in particular contacts) in a single result with language specifiers. What is the intended scope of the localization to be done according to any given specifier? Just this contact or the whole result as might be implied by the words.. but then what if the contacts have different language specifiers? s3.2.5: and : With reference also to the discussion of Matching Issues below especially s3.1.5 (d), I don't like this idea. Can I not put an email address with an IDN encoded domain in eMail, and if not, what can I put in eMail? s3.3.2: : Give or take some issues with singular and plural, the implication is that a client can tell a server several languages to use. What is the server to make of this? What scope should be applied to any given language specifier? If there is just one should the whole result be translated wherever possible and appropriate? s3.4: "enum - the fully qualified name of an ENUM domain. This is a domain name as specified by RFC 1035 [9]. It yields a (Section 3.2.3) in the response.": Presumably I am allowed, indeed must use, IDNs here? Again we may be in some murky waters with matching algorithms. Comprehensibility of bits of section 3: ======================================= s3.1.1: Discussion of how the option is supposed to work. I regret to say that the explanation of how this was supposed to 'narrow' (constrain?) the search left me almost totally in the dark, particularly as regards what happens if you are supposed do a search with less specific domains. I am not sure I could implement this function so that it would produce reliably equivalent results between servers. s3.1.5: first sentence: "Some of the queries above have similar query constraints for searching on contacts." This is rather over vague. How about replacing whole of first para with: Sections 3.1.2 and 3.1.3 allow searches for contact-based specifications. The scope of such searches can be constrained using the common parameters described in this section. s3.2.1: para 1: "...values that cannot be given...": Does this mean "values that cannot be included in query results"? s3.2.1: "As specified, *they* are nillable and therefore may be present with empty content or present with their specified content. The use of these elements is also optional. If present without content, *each of these element* types MUST have one or more of the following boolean attributes:": It is not at all clear what 'they' and 'each of these elements' refers to - there are various long lists with sub-lists in the preceding text - please clarify this. Also nillable is xml jargon: it needs a reference or definition. s3.2.3 et seq: Example numbers: I note that the majority of domain names and telephone numbers are taken from recognized documentation example spaces (good). I presume "3.0.7.1.e164.arpa" is derived from +1 7035 555 1212 - is this ok since 703 is a real area code? (actually I just realised that +1 7035 555 1212 isn't in the correct format for a NA number even though is is using the 555 example exchange code.) It is also probably sensible to use a true example number for the sample in s3.2.5 (currently +1234567890). s3.2.3: description: "may contain at least one of..": This caused my brain to hurt until I went and read the schema: The definition indicates that what this means is " MAY be present but if it is it MUST contain at least one of the following… " s3.2.3: values: s/at period/in grace period provided after/ (5 places) s3.2.3: : "downstream registration reference" - even with the example, I am not really sure what this means. Matching issues: ================ s3.1.5: item: I think this item needs some more work. There are a number of sub-issues: a) "...the matching SHOULD take place only on the domain given (i.e. no partial matches...": This seems to be a recipe for confusing users. If some servers are allowed to do other than a full match because of the SHOULD, this is presumably a partial match and the results that a user gets back will depend on what server is asked given the same data. I think this should either be a MUST or explicitly allow partial matches.. and explain what that means. b) "If either the contents of the element or domain part of the contents of the element contain a name with non-ASCII characters, they MUST be normalized according to the processes of RFC 3491 [16].": If I understand RFC3491 and 3454 correctly, this will result in case-folding for strings with non-ascii characters in them but nothing is done if they are pure ascii... I am sure this is not what is wanted. c) same text as (b): Using 'normalized' could be confusing as normalization is just one of the stages of 3491/3454 operations. 'prepared' would be better. d) How should the domain match be done?: The IETF has gone to a lot of trouble to define IDNs.. it seems to me that the matching algorithm for domain names should use that rather than some half way house where domain names use the 'preparation' part but don't do the encoding, so that a request using the punycode encoded IDN would fail. e) The match for the user part is not further specified so I guess it has to be assumed to be character by character exact: is this what is wanted? f) Are you explicitly forbidding the extended format (RFC2821) like "Elwyn Davies "? s3.4: last bullet point: "All names in these entity classes are case insensitive.": Is this a meaningful statement given that languages in which case folding doesn't apply may be involved? Editorial nits: =============== global: use "name server" instead of "nameserver" (some places do already). global: s/e.g./e.g.,/ s3, para 1: s/a registry/registry/ s3, last para:s/reference Section 4 for needed details/refer to Section 4 for relevant details/ s3.1.4:s/domainss/domain/ s3.2.5: Suggest replace last sentence with "Each one MUST contain only an element containing the exact city, region, or postal code (i.e. no substring searches are allowed)." s2.1, para: s/jurisdicational/jurisdictional/ s2.1, para: s/elements/element/ s2.1, last para: s/the recepient/to the recipient/ s3.2.3, : s/indicatation/indication/, s/registrered/registered/ s3.2.9, para: s/an validation/a validation/ s3.4, e164 bullet: s/interpretted/interpreted/ s3.4, enum-handle bullet: s/a ENUM/an ENUM/ s3.4, validation-entity bullet: s/an validation/a validation/