Subject: [Enum] RE: EPP-E164 Questions

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 19 Jul 2004 14:14:22 -0400

(adding a subject...)

Thanks for the note, Lawrence.  It's nice to see someone else reading the
document!

Responses below.

-Scott-

> -----Original Message-----
> From: Conroy, Lawrence (SMTP) [mailto:lwc at roke.co.uk] 
> Sent: Monday, July 19, 2004 1:30 PM
> To: 'enum at ietf.org'
> Cc: Richard Shockey; Scott Hollenbeck
> Subject: 

[snip]

> (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?

This makes more sense if you start by looking at RFC 2915 instead of RFC
3403.  The ABNF in 2915 indicates a maximum length for the service field of
65 characters.  3403 now says that "It is up to the Application
Specification to specify the values found in this field".  So, the sort
answer is that the length limit has been there since 2915.  It may or may
not be appropriate now -- I'm open to removing the upper limit if that lines
up better with 3403.

> (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?

This limit is arbitrary.  It was selected as a guess at what might be "long
enough".  When doing the EPP work in provreg several implementers asked for
upper length limits on string fields to help make their coding lives easier.
This is just an artifact of a general approach I took with EPP to
accommodate such requests.

> (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)

IIRC 2915/3403 notes that these fields might be empty in some cases.  At
least I remember Michael Mealling telling me that they might be empty!  From
a purely mechanical schema perspective, there's thus no way of applying
policy to know if they need to be there or not.  They're OPTIONAL because
they may or may not be there depending on other factors.  Some other
specification that defines a policy will have to determine if/when these
elements will need to be there.

>        (b)  From the schema in 4, it seems that these child elements 
> cannot be empty
>             - am I right in this?

That's correct.  They can be left out, but if they're present they can't be
empty.

> 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"?

I think that's TBD, and a matter of implementation policy.  As I mentioned
in an earlier exchange with Michael Haberling it may or may not be
appropriate in all operating environments, but the capability will exist for
those environments where it's deemed useful.  The US ENUM Forum, for
example, has expressed an interest in the idea.

> (v)   Is this extension intended *only* for central Registry zone 
> population (i.e. non-delegated
>        zones)?

It can be used anywhere EPP is or might be deployed.   Admittedly that's
currently only by TLD zone administrators and the entities that interact
with them, but there's nothing in the protocol itself to impose that kind of
limitation.

-Scott-

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum