Otmar,
Thanks for the clarifications. I have no further questions.
It would probably be good to have an IETF-wide
answer to my question about ISO 3166, but I don't think
that should delay your document.
[Patrik - do you have an answer re 3166? The question is
how to cite the up-to-date list of country codes.]
Brian
On 2007-07-16 17:31, Otmar Lendl wrote:
On 2007/07/02 12:07, Brian E Carpenter <[EMAIL PROTECTED]> wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Thanks for the review.
I've been going through your comments and the IESG's and have put
some more polishing touches on the text.
Summary: This draft is ready, with some minor questions.
Comments:
Substantive:
------------
This seems clear and straightforward. I have not checked the XML
with a parser. A few minor questions:
Whoever wants to check the xml: The examples were generated using
http://www.ienum.ie/images/ENUM-Clienttoolkit.tar.gz (plus
some scripts to reformat the XML for the line-length limitations.)
4.1. The <validation> Element
...
o An optional <lastE164Number> element. If present it indicates
that the whole number block starting with <E164Number> up to and
including <lastE164Number> has been validated. To avoid
ambiguity, both numbers must be of the same length.
Isn't it the case that some countries (e.g. Germany) use variable
length numbers within a single PABX? How will that be handled?
Here in Austria we're using open numbering plans as well, so we
had that very much in mind. It's rather simple: The delegation
from the ENUM registry to the number-owner is on the head-number
of the PABX which transforms all extension numbers behind that
PABX number into subdomains on the customer's nameserver.
Such cases thus just require a single delegation and thus a
single validation token which contains the pilot number (or "prefix")
of the PABX.
4.2. The <tokendata> Element
...
o A single <address> section containing the following elements:
I'm a little concerned that this may be too simply defined.
If you look at section 3.4. "Civic Address Components" of RFC 4676,
you will see the results of a thorough approach.
We considered that.
The choice was between this all-encompassing scheme and the
white-pages access protocol of the ITU. As the latter already
has a XML scheme and as the reference DB of validation information
will often be the local white pages directory, we opted to use
that one.
That's definitly a judgement call.
... The <ISOcountryCode> element specifies the country using the
ISO 3166 [11] code.
Does that reference dated 1988 automatically pull in the latest
list of country codes?
Not sure about that. I've checked other RFCs (this is certainly not
the first one to reference country codes) and they don't contain
a better reference (i.e. 4676 uses it, but doesn't provide a
reference).
8. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in RFC 3688 [13].
That looks like a normative reference to me.
ok, changed.
Editorial:
----------
[9] 3rd, D., Boyer, J., and J. Reagle, "Exclusive XML
Canonicalization Version 1.0", W3C REC REC-xml-exc-c14n-
20020718, July 2002.
Has lost part of the authors' names.
oops, that was a reference from http://xml.resource.org/
fixed.
/ol
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
