Subject: [Enum] (no subject)

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Mon, 19 Jul 2004 13:41:40 -0400

Hi Richard, Scott, folks,
  I note that we still haven't really processed the EPP-E164 draft, so
here's my attempt to re-start this.
First, as I understand it, it's an XML (sub-)schema that operates 
within a pure client-server model,
so in terms of a protocol, it works if it's a valid schema and fits to 
the guidelines in RFC3735.

I am not now, nor have I ever been, knowingly a member of any cults; 
I'm not for or against any protocol
on religious principle. Thus the following is for my clarification only.

I have a couple of questions on the draft content. I'm no XML expert, 
so these may be dumb but...

(i)    2.2.4 (and the xml schema in 4) gives the service field a max 
length of 65 characters.
       This seems perfectly reasonable to me, but why 65 as opposed to 
60 or 70?
(ii)   2.2.6 (and the xml schema in 4) gives the replacement field a 
max length of
       255 characters. Again, this seems overkill if anything, as the 
max domain name
       is less than this, I thought. Thus why so long - is this a 
SNAPTR requirement?
(iii) (a)  3.1.2 items 3..6. Aren't these conditionally mandatory, 
rather than
           purely optional? (This is also true for 3.2.1 and 3.2.5, 
except that
           in those cases it's the client specifying the content, not 
the server)
      (b)  From the schema in 4, it seems that these child elements 
cannot be empty
           - am I right in this?

Finally, I'm trying to understand the use of this protocol/extension, 
as it is not obvious to me
that populating NAPTRs in a zone is the sort of thing I'd expect a 
Registrar (or a Registrant)
to request be done to a central repository. Thus, a pair of questions:

(iv)  Under what circumstances would someone use a Registrar-Registry
      Protocol to populate NAPTRs in a zone, and who is that "someone"?
(v)   Is this extension intended *only* for central Registry zone 
population (i.e. non-delegated
      zones)?

all the best,
  Lawrence
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum