Subject: [Gen-art] Gen art review: draft-ietf-enum-iris-ereg-02.txt

From: Elwyn Davies <[email-masked]>
Date: Tue, 25 Oct 2005 14:09:24 +0100

Background for those on the CC list, who may be unaware of GenART:
GenART is the Area Review Team for the General Area of the IETF.  We
advise the General Area Director (i.e. the IETF/IESG chair) by providing
more in depth reviews than he could do himself of documents that come up
for final decision in IESG telechat.  I was selected as the GenART
member to review this document.  Below is my review, which was written
specifically with an eye to the GenART process, but since I believe that
it will be useful to have these comments more widely distributed, others
outside the GenART group are being copied.

Document: draft-ietf-enum-iris-ereg-02.txt
Intended Status: Proposed Standard
Shepherding AD: Allison Mankin
Review Trigger: IETF Last Call ending 27/10/05 and IESG Telechat 27/10/05

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: <contact> element description: "<language> - 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: <eMail> and <IDNeMail> : 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: <languageNotSupported>: 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 <enum>
       (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 <specificity> 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: <status> 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 "<status> MAY be present but if it is it MUST contain at 
least one of the following… "

s3.2.3: <status> <xxxPeriod> values: s/at period/in grace period provided after/ 
(5 places)

s3.2.3: <registrationReference>: "downstream registration reference" - even with 
the example, I am not really sure what this means.

Matching issues:
================
s3.1.5: <email> 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 <inDomain> element or domain part of the 
contents of the <exactMatch> 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 <[email-masked]>"?

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 
<exactMatch> element containing the exact city, region, or postal code (i.e. no 
substring searches are allowed)."

s2.1, <subStatus> para: s/jurisdicational/jurisdictional/
s2.1, <contactTypeType> para: s/elements/element/
s2.1, last para: s/the recepient/to the recipient/

s3.2.3, <registrationReference>: s/indicatation/indication/, 
s/registrered/registered/

s3.2.9, <serial> 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/

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art