Subject: RE: More Private Comments
From: "Hollenbeck, Scott" <[email-masked]>
To: "'Daniel Manley'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Date: Fri, 21 Dec 2001 16:35:35 -0500

> -----Original Message-----
> From: Daniel Manley [mailto:[email-masked]]
> Sent: Friday, December 21, 2001 10:12 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]'
> Subject: Re: More Private Comments
> 
> 
> thanks for posting this Scott.  The only other suggestion we 
> have would 
> be to include a "type" attributes to the <polledMsg> tag.  
> I'm not sure 
> if EPP could define a set of types since EPP only defines 
> that transfers 
> must generate messages.  So possibly a pattern like <polledMsg 
> type="transfer:domain" id="123">Transfer requested</polledMsg>.  This 
> would allow parsing clients to know how to parse the XML in <resData> 
> without having to pre-parse it beforehand.

Dan and I exchanged some private messages to make sure we're on the same
page, and after thinking about it a bit more I've come up with a way to
ensure that an optional "type" attribute is meaningful without having to
enumerate possible types: we just use existing EPP elements that clients
already understand.  Here's a sample to describe a transfer request:

<msgQ count="5" id="12345">
  <qDate>2000-06-08T22:00:00.0Z</qDate>
  <msg xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
       type="<domain:transfer/>">Transfer requested.</msg>
</msgQ>

Note that the value of the "type" attribute is the command element that
caused the message in the first place, and that an "xmlns" attribute has to
be added to ensure that the parser can digest the "type" attribute.

My commentary and question: Given that all of this info is also found in the
<resData> element, I've suggested to Dan that the "type" attribute appears
redundant.  Dan's rationale for why it might be helpful is described above.
Does anyone object to adding an optional (it's not needed when there's no
<resData>) "type" attribute in this fashion?

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Daniel Manley'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: More Private Comments
Date: Fri, 21 Dec 2001 11:17:18 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Daniel Manley [mailto:[email-masked]]
> Sent: Friday, December 21, 2001 10:12 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]'
> Subject: Re: More Private Comments
> 
> 
> thanks for posting this Scott.  The only other suggestion we 
> have would 
> be to include a "type" attributes to the <polledMsg> tag.  
> I'm not sure 
> if EPP could define a set of types since EPP only defines 
> that transfers 
> must generate messages.  So possibly a pattern like <polledMsg 
> type="transfer:domain" id="123">Transfer requested</polledMsg>.  This 
> would allow parsing clients to know how to parse the XML in <resData> 
> without having to pre-parse it beforehand.

I don't believe we could come up with a definitive set of types, though it
might be possible to say that the value of the "type" attribute is a
combination of the EPP command that caused the message and the namespace of
the object that was involved.  That means it won't be something that can be
validated by the XML parser, but it might still be useful.

> Also, I was wondering if poll in the EPP documents (this would also 
> apply to futur push implementations, if any) should be 
> further defined 
> like this:
> 
> "An EPP server MUST generate queued messages or notifications to the 
> registrar if an object owned by the registrar is affected or changed 
> without the registrar's invovlement."  (or something of the sorts)

OK, I could add text to the <poll> description to get that message across.
I don't think we can use words like "registrar" or "owned", but I understand
the intent of the suggestion.

-Scott-

Date: Fri, 21 Dec 2001 10:12:13 -0500
From: Daniel Manley <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: More Private Comments
Sender: [email-masked]

Hollenbeck, Scott wrote:

>
>2)  inconsistent poll response format
>
>This comment described an issue with the way <poll> messages are returned.
>In the current documents, the response <msg> element is overloaded to return
>the message.  Dan suggested a change the to the 1301 response code so that
>it has a consistent meaning, and putting the message within the <resData>
>element.  I disagreed with putting the message with <resData> because
><resData> is currently used only for _object specific_ response data, and I
>suggested a compromise of putting the message within the <msgQ> element,
>like this:
>
>  S:  <response>
>  S:    <result code="1301">
>  S:      <msg>Message dequeued.</msg>
>  S:    </result>
>  S:    <msgQ count="5">
>  S:      <qDate>2000-06-08T22:00:00.0Z</qDate>
>  S:      <polledMsg id="12345">Transfer requested.</polledMsg>
>  S:    </msgQ>
>  S:    <resData>
>  S:      <obj:trnData xmlns:obj="urn:ietf:params:xml:ns:obj"
>  S:       xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
>  S:        <obj:name>example</obj:name>
>  S:        <obj:trStatus>pending</obj:trStatus>
>  S:        <obj:reID>ClientX</obj:reID>
>  S:        <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate>
>  S:        <obj:acID>ClientY</obj:acID>
>  S:        <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate>
>  S:        <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate>
>  S:      </obj:trnData>
>  S:    </resData>
>  S:    <trID>
>  S:      <clTRID>ABC-12345</clTRID>
>  S:      <svTRID>54321-XYZ</svTRID>
>  S:    </trID>
>  S:  </response>
>  S:</epp>
>
>This puts all of the <poll>-specific data in the <msgQ> element, keeps
><resData> object-specific, and makes the response code structure consistent.
>At the end of our last private exchange Dan said he still wasn't comfortable
>with this suggested modification, so we may have more to talk about.
>
thanks for posting this Scott.  The only other suggestion we have would 
be to include a "type" attributes to the <polledMsg> tag.  I'm not sure 
if EPP could define a set of types since EPP only defines that transfers 
must generate messages.  So possibly a pattern like <polledMsg 
type="transfer:domain" id="123">Transfer requested</polledMsg>.  This 
would allow parsing clients to know how to parse the XML in <resData> 
without having to pre-parse it beforehand.

Also, I was wondering if poll in the EPP documents (this would also 
apply to futur push implementations, if any) should be further defined 
like this:

"An EPP server MUST generate queued messages or notifications to the 
registrar if an object owned by the registrar is affected or changed 
without the registrar's invovlement."  (or something of the sorts)

As a registrar I would want to be notified anytime an object of mine is 
modified or affected by the actions of either other registrars (like 
transfer requests) or by the registry itself (via policy mechanisms like 
auto-renew or changes made by registry support staff).  That way, 
registrars can be sure that their databases have better chances of not 
being out of sync with the registry.

Dan

Date: 19 Dec 2001 12:27:48 -0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: "External" hosts in EPP
Sender: [email-masked]

On Wed, 19 Dec 2001 06:57:32 -0500 "Hollenbeck, Scott" wrote:
>Doesn't giving an option to copy the hosts put us right into the same
>situation where host objects can get created without the client explicitly
>creating them?  I _really_ think it's safer for the client to create
>whatever hosts it needs before doing the transfer, and failing the transfer
>request if a needed host hasn't been created.  It's an extra step up front,
>but it avoids other notification and synchronization steps post-transfer.

The "copy option" _would_ mean that host objects might be created without the client explicitly creating them, but the registrar would agree that this should happen by explicitly specifying that he wants them copied.

But I see the consistency issue here as well. Right now, there are no places in the protocol where objects are created implicitly, so it might not be worth introducing this now, with the "copy option".

If registrars are happy with the extra step up front, I'm happy. :-)

Asbjorn

-- 
 The information transmitted in this email is intended only for the person(s)
 or entity to which it is addressed and may contain proprietary, confidential
 and/or privileged material. If you have received this email in error, please
 contact the sender by replying and delete this email so that it is not
 recoverable. If you are not the intended recipient(s), any retention, review,
 disclosure, distribution, copying, printing, dissemination, or other use of,
 or taking of any action in reliance upon, this information is strictly
 prohibited and without liability on our part.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: "External" hosts in EPP
Date: Wed, 19 Dec 2001 06:57:32 -0500
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, December 19, 2001 4:59 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: "External" hosts in EPP
> 
> 
> Scott,
> 
> I agree that creating objects without the registrars 
> knowledge is perhaps not a very good idea. :-)
> 
> I don't have a problem with doing it as you describe. Are 
> people here happy with that? What if we in the <transfer> 
> command give the user the option whether to copy necessary 
> host objects or not, and the default behaviour is not copying 
> the host objects and potentially fail the transfer.

Doesn't giving an option to copy the hosts put us right into the same
situation where host objects can get created without the client explicitly
creating them?  I _really_ think it's safer for the client to create
whatever hosts it needs before doing the transfer, and failing the transfer
request if a needed host hasn't been created.  It's an extra step up front,
but it avoids other notification and synchronization steps post-transfer.

-Scott-

Date: 19 Dec 2001 09:59:09 -0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: "External" hosts in EPP
Sender: [email-masked]

Scott,

I agree that creating objects without the registrars knowledge is perhaps not a very good idea. :-)

I don't have a problem with doing it as you describe. Are people here happy with that? What if we in the <transfer> command give the user the option whether to copy necessary host objects or not, and the default behaviour is not copying the host objects and potentially fail the transfer.

Asbjorn

On Tue, 18 Dec 2001 13:14:01 -0500 "Hollenbeck, Scott" wrote:
>I don't think host copying is such a good idea because it means that a host
>object gets created implicitly as a by-product of the <transfer> command
>rather than as the result of a <create> command.  The server then has to let
>the client know that this happened, and the risk of synchronization error
>increases.
>
>As I see it, there are two situations to consider:
>
>1. The requesting client already has a local copy of the external host
>object before the <transfer> is requested.  In this situation, the server
>has to switch a pointer from the old client's copy to the new client's copy
>as part of the transfer, but no new objects get created without the client's
>knowledge.
>
>2. The requesting client doesn't have a local copy of the external host
>object before the <transfer> is requested.  Suppose we require the client to
>create a local copy before they request the transfer?  They can see the name
>servers before requesting a transfer, and it should be easy to compare
>what's there with the client's local store of external hosts.  Once the new
>local copy exists we're in situation #1 as described above, and the client
>and server have consistent object views during the transfer process.  If the
>transfer doesn't go through, the client can always delete the external host
>object as part of their cleanup effort, or they can keep it around for
>future use.
>
>My basic point of discomfort is in the server creating objects as part of
>something other than a <create> command.  I think the above could work
>without the client having to worry about updating their object stores after
>a transfer takes place because the server created an object for them that
>they might not have expected.
>
>-Scott-
>

-- 
 The information transmitted in this email is intended only for the person(s)
 or entity to which it is addressed and may contain proprietary, confidential
 and/or privileged material. If you have received this email in error, please
 contact the sender by replying and delete this email so that it is not
 recoverable. If you are not the intended recipient(s), any retention, review,
 disclosure, distribution, copying, printing, dissemination, or other use of,
 or taking of any action in reliance upon, this information is strictly
 prohibited and without liability on our part.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: "External" hosts in EPP
Date: Tue, 18 Dec 2001 13:14:01 -0500
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2001 11:57 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: "External" hosts in EPP
> 
> 
> b) If the domain is using an external host that the gaining 
> registrar has not already registered, a copy of the existing 
> host object should be copied into the namespace of the 
> gaining registrar (thus owning the new host object). In 
> addition the domain record needs to refer to the new object 
> instead of the old object[1].

I don't think host copying is such a good idea because it means that a host
object gets created implicitly as a by-product of the <transfer> command
rather than as the result of a <create> command.  The server then has to let
the client know that this happened, and the risk of synchronization error
increases.

As I see it, there are two situations to consider:

1. The requesting client already has a local copy of the external host
object before the <transfer> is requested.  In this situation, the server
has to switch a pointer from the old client's copy to the new client's copy
as part of the transfer, but no new objects get created without the client's
knowledge.

2. The requesting client doesn't have a local copy of the external host
object before the <transfer> is requested.  Suppose we require the client to
create a local copy before they request the transfer?  They can see the name
servers before requesting a transfer, and it should be easy to compare
what's there with the client's local store of external hosts.  Once the new
local copy exists we're in situation #1 as described above, and the client
and server have consistent object views during the transfer process.  If the
transfer doesn't go through, the client can always delete the external host
object as part of their cleanup effort, or they can keep it around for
future use.

My basic point of discomfort is in the server creating objects as part of
something other than a <create> command.  I think the above could work
without the client having to worry about updating their object stores after
a transfer takes place because the server created an object for them that
they might not have expected.

-Scott-

Date: 18 Dec 2001 16:57:28 -0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: "External" hosts in EPP
Sender: [email-masked]

On Mon, 17 Dec 2001 14:37:48 -0800 "Jordyn A. Buchanan" wrote:
>Consistency is nice.  Asbjorn's proposal has the added advantage of 
>making it much easier to change from a host without glue to an 
>in-zone host with glue by simply updating the object as opposed to 
>changing each and every domain that you have associated with a 
>particular out-of-zone host.
>
>Jordyn

Yeah, and I don't think that differentiating between in-zone and external hosts will complicate the protocol too much. The registrars can refer to any exernal hosts they want to without messing things up for other registrars, and the registry only needs to make sure that there are "separate namespaces" for external hosts for each registrar...

As far as I can see (right now at least), domain transfers won't be too complicated either. The following will probably work:

a) If the domain is using an in-zone host, it behaves as in the current EPP drafts. After the transfer, the domain will still point to the same host object. No host objects will be created and the domain object will not be modified.

b) If the domain is using an external host that the gaining registrar has not already registered, a copy of the existing host object should be copied into the namespace of the gaining registrar (thus owning the new host object). In addition the domain record needs to refer to the new object instead of the old object[1].

c) If the domain is using an external host that the gaining registrar has already registered in the Registry, the domain should start refering to the "new" (as in the for the gaining registrar's existing) host id instead of the old (losing registrar's) host id. The domain record needs to be updated afterwards to refer to the new object instead of the old object[1].

Hopefully, I am not missing aything obvious here...

Thanks,

Asbjorn

[1] I think this will be as good as invisible for the user. As the host is listed in the domain using the name, not the roid, there would be no visible change here. In host object commands it should not cause any problems either as the name again is used to identify the objects. The only difference[2] would be in the ROID value for the host object, but this id is only used in the <info> command today AFAICR.

[2] <offtopic>Well... This is out of scope of this group, but if the registry supports a domain lookup type in WHOIS where it will list the nameserver id's instead of their names, the nameserver id's will of course also have to change here...</offtopic>

-- 
 The information transmitted in this email is intended only for the person(s)
 or entity to which it is addressed and may contain proprietary, confidential
 and/or privileged material. If you have received this email in error, please
 contact the sender by replying and delete this email so that it is not
 recoverable. If you are not the intended recipient(s), any retention, review,
 disclosure, distribution, copying, printing, dissemination, or other use of,
 or taking of any action in reliance upon, this information is strictly
 prohibited and without liability on our part.

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Sheer El-Showk'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Empty Text Elements 
Date: Tue, 18 Dec 2001 11:18:57 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

you beat me to the punch, empty is an erasure mechanism.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Sheer El-Showk'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Empty Text Elements
Date: Tue, 18 Dec 2001 10:42:18 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Sheer El-Showk [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2001 9:57 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]'
> Subject: Re: Empty Text Elements
> 
> 
> How would you then unset a value for an optional field?

Maybe the <org> element was a bad example because you're right, it's useful
to allow an empty element to unset an optional element.  It's cases where
the element isn't optional (like the contact <email> element) that this
might be useful.

-Scott-

From: "Gould, James" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Empty Text Elements
Date: Tue, 18 Dec 2001 10:22:00 -0500
Sender: [email-masked]

Scott,

I believe this is a good change.  If an element exists, it should contain
text.

Jim

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Tuesday, December 18, 2001 8:38 AM
To: [email-masked]'
Subject: Empty Text Elements

One more fix to discuss based on a comment I received some time ago...

Several text elements in different schemas can currently be sent empty, like
this:

<org></org>

This might be confusing or worse to a client or server that fails to account
for the fact that elements can be empty.  If it would help make things more
robust, the definitions for such elements can be changed to ensure that the
elements contain at least one character.  The definition for the type behind
the <org> element above could be changed from this:

  <simpleType name="postalLineType">
     <restriction base="normalizedString">
       <maxLength value="255"/>
     </restriction>
  </simpleType>

to this:

  <simpleType name="postalLineType">
     <restriction base="normalizedString">
       <minLength value="1"/>
       <maxLength value="255"/>
     </restriction>
  </simpleType>

and the parser would ensure that empty elements don't get through.  Would
that be a helpful change?

-Scott- 

Date: Tue, 18 Dec 2001 09:56:38 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: Empty Text Elements
Sender: [email-masked]

How would you then unset a value for an optional field?

Sheer

On Tue, 18 Dec 2001, Hollenbeck, Scott wrote:

> One more fix to discuss based on a comment I received some time ago...
>
> Several text elements in different schemas can currently be sent empty, like
> this:
>
> <org></org>
>
> This might be confusing or worse to a client or server that fails to account
> for the fact that elements can be empty.  If it would help make things more
> robust, the definitions for such elements can be changed to ensure that the
> elements contain at least one character.  The definition for the type behind
> the <org> element above could be changed from this:
>
>   <simpleType name="postalLineType">
>      <restriction base="normalizedString">
>        <maxLength value="255"/>
>      </restriction>
>   </simpleType>
>
> to this:
>
>   <simpleType name="postalLineType">
>      <restriction base="normalizedString">
>        <minLength value="1"/>
>        <maxLength value="255"/>
>      </restriction>
>   </simpleType>
>
> and the parser would ensure that empty elements don't get through.  Would
> that be a helpful change?
>
> -Scott-
>

Date: Tue, 18 Dec 2001 09:54:50 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: Daniel Manley <[email-masked]>
cc: "Jordyn A. Buchanan" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
Subject: Re: "External" hosts in EPP
Sender: [email-masked]

Well, this is a good general concern that extends up into the
implementation as well as the protocol.  The whole point of EPP was to
standardize on a protocol that would simplify registrar implementation and
allow them to trivially support multiple registries.  As someone pointed
out (Jordyn or Daniel I think), even the existing protocol implementations
are non-interoperable and registry-specific (though is is due to tracking
a moving standard).  It would be unfortunate to provide enough flexibility
in the data model that registrars would have to support essentially
different application logic to support them.  Of course, dictating
registry policy is well outside of our scope but we can do what little we
can to minimize inconsistencies.

Sheer

On Tue, 18 Dec 2001, Daniel Manley wrote:

> yes, that's a good argument that we don't consider enough.  At what
> point does EPP have a little too much of the "E"?  I'll take back my
> previous statement, but do consider that this is an extensible protocol.
>  What's stopping every registry from extending in such different
> directions that interoperability is still lost?
>
> Dan
>
>
> Jordyn A. Buchanan wrote:
>
> > As I indicated in Salt Lake, I'm not a very big fan of "freedom of
> > expression" for freedom of expression's sake.  This is the sort of
> > option that makes it harder to interoperate and doesn't gain any
> > additional functionality.
> >
> > If someone (Cathy, Klaus?) has any reasons why it is actually
> > beneficial to have the name server as an attribute as opposed to an
> > object, I'll reconsider my stance.  I think all I've heard to this
> > point is "that's how some registries do it already".  That's not
> > really an argument to explain whether it's good behavior, though. Some
> > registries allow out-of-zone glue, which we decided was a bad idea
> > long ago.  The change to EPP is already going to require some change
> > in how registrars interact with registries; I simply don't get how the
> > requirement to create a host object before using it is particularly
> > damaging.
> >
> > On the flip side, if some registries require host object creation and
> > some don't, this means registrars have to create substantially
> > different logic for how they register domains in some TLDs (or IP
> > registries) than they do in others.  That's not good.
> >
> > Jordyn
> >
> >
> > At 6:51 PM -0500 12/17/01, Daniel Manley wrote:
> >
> >> For the sake of freedom of expression, I guess it wouldn't hurt, but
> >> we would probably not use it -- there's too many advantage to using
> >> host objects.
> >>
> >> Dan
> >>
> >> Hollenbeck, Scott wrote:
> >>
> >>>> -----Original Message-----
> >>>> From: Jordyn A. Buchanan [mailto:[email-masked]]
> >>>> Sent: Monday, December 17, 2001 5:38 PM
> >>>> To: [email-masked]; Hollenbeck, Scott
> >>>> Cc: [email-masked]
> >>>> Subject: RE: "External" hosts in EPP
> >>>>
> >>>>
> >>>> At 11:58 AM -0800 12/17/01, [email-masked] wrote:
> >>>>
> >>>>> Scott,
> >>>>>
> >>>>> I'd agree that Asbjorn's proposal is reasonable one. OTOH, creating
> >>>>> objects for non-glue hosts seem counterintuitive, I'd prefer
> >>>>
> >>>> that we did
> >>>>
> >>>>> not have too. If others favor consistency, i'll drop my objection.
> >>>>>
> >>>> Consistency is nice.  Asbjorn's proposal has the added advantage of
> >>>> making it much easier to change from a host without glue to an
> >>>> in-zone host with glue by simply updating the object as opposed to
> >>>> changing each and every domain that you have associated with a
> >>>> particular out-of-zone host.
> >>>>
> >>>
> >>> OK, then, last concern:  I think I said something bogus when talking
> >>> about
> >>> this at SLC.  I believe it was Sheer who asked if the intention was
> >>> to allow
> >>> mixing of host-object and no-host-object modes, and I think I said
> >>> "yes".
> >>> If I did, that's not what I meant to say.  My intention was to
> >>> provide the
> >>> choice in the domain mapping such that a server could choose to
> >>> implement
> >>> host objects (now with Asbjorn's suggested fix that some of you vaguely
> >>> remembered at the end of the discussion), or a server could choose
> >>> to NOT
> >>> implement host objects and do delegations using name server info as
> >>> domain
> >>> attributes.
> >>>
> >>> Does anyone see any value in offering this choice?  Is anyone
> >>> interested in
> >>> implementing a no-host-object server?  If not, it doesn't seem worth
> >>> adding
> >>> the choice.
> >>>
> >>> -Scott-
> >>
> >
> >
>
>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Empty Text Elements
Date: Tue, 18 Dec 2001 08:38:09 -0500
Sender: [email-masked]

One more fix to discuss based on a comment I received some time ago...

Several text elements in different schemas can currently be sent empty, like
this:

<org></org>

This might be confusing or worse to a client or server that fails to account
for the fact that elements can be empty.  If it would help make things more
robust, the definitions for such elements can be changed to ensure that the
elements contain at least one character.  The definition for the type behind
the <org> element above could be changed from this:

  <simpleType name="postalLineType">
     <restriction base="normalizedString">
       <maxLength value="255"/>
     </restriction>
  </simpleType>

to this:

  <simpleType name="postalLineType">
     <restriction base="normalizedString">
       <minLength value="1"/>
       <maxLength value="255"/>
     </restriction>
  </simpleType>

and the parser would ensure that empty elements don't get through.  Would
that be a helpful change?

-Scott- 

Date: Tue, 18 Dec 2001 08:21:18 -0500
From: Daniel Manley <[email-masked]>
To: "Jordyn A. Buchanan" <[email-masked]>
CC: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: "External" hosts in EPP
Sender: [email-masked]

yes, that's a good argument that we don't consider enough.  At what 
point does EPP have a little too much of the "E"?  I'll take back my 
previous statement, but do consider that this is an extensible protocol. 
 What's stopping every registry from extending in such different 
directions that interoperability is still lost?

Dan

Jordyn A. Buchanan wrote:

> As I indicated in Salt Lake, I'm not a very big fan of "freedom of 
> expression" for freedom of expression's sake.  This is the sort of 
> option that makes it harder to interoperate and doesn't gain any 
> additional functionality.
>
> If someone (Cathy, Klaus?) has any reasons why it is actually 
> beneficial to have the name server as an attribute as opposed to an 
> object, I'll reconsider my stance.  I think all I've heard to this 
> point is "that's how some registries do it already".  That's not 
> really an argument to explain whether it's good behavior, though. Some 
> registries allow out-of-zone glue, which we decided was a bad idea 
> long ago.  The change to EPP is already going to require some change 
> in how registrars interact with registries; I simply don't get how the 
> requirement to create a host object before using it is particularly 
> damaging.
>
> On the flip side, if some registries require host object creation and 
> some don't, this means registrars have to create substantially 
> different logic for how they register domains in some TLDs (or IP 
> registries) than they do in others.  That's not good.
>
> Jordyn
>
>
> At 6:51 PM -0500 12/17/01, Daniel Manley wrote:
>
>> For the sake of freedom of expression, I guess it wouldn't hurt, but 
>> we would probably not use it -- there's too many advantage to using 
>> host objects.
>>
>> Dan
>>
>> Hollenbeck, Scott wrote:
>>
>>>> -----Original Message-----
>>>> From: Jordyn A. Buchanan [mailto:[email-masked]]
>>>> Sent: Monday, December 17, 2001 5:38 PM
>>>> To: [email-masked]; Hollenbeck, Scott
>>>> Cc: [email-masked]
>>>> Subject: RE: "External" hosts in EPP
>>>>
>>>>
>>>> At 11:58 AM -0800 12/17/01, [email-masked] wrote:
>>>>
>>>>> Scott,
>>>>>
>>>>> I'd agree that Asbjorn's proposal is reasonable one. OTOH, creating
>>>>> objects for non-glue hosts seem counterintuitive, I'd prefer
>>>>
>>>> that we did
>>>>
>>>>> not have too. If others favor consistency, i'll drop my objection.
>>>>>
>>>> Consistency is nice.  Asbjorn's proposal has the added advantage of 
>>>> making it much easier to change from a host without glue to an 
>>>> in-zone host with glue by simply updating the object as opposed to 
>>>> changing each and every domain that you have associated with a 
>>>> particular out-of-zone host.
>>>>
>>>
>>> OK, then, last concern:  I think I said something bogus when talking 
>>> about
>>> this at SLC.  I believe it was Sheer who asked if the intention was 
>>> to allow
>>> mixing of host-object and no-host-object modes, and I think I said 
>>> "yes".
>>> If I did, that's not what I meant to say.  My intention was to 
>>> provide the
>>> choice in the domain mapping such that a server could choose to 
>>> implement
>>> host objects (now with Asbjorn's suggested fix that some of you vaguely
>>> remembered at the end of the discussion), or a server could choose 
>>> to NOT
>>> implement host objects and do delegations using name server info as 
>>> domain
>>> attributes.
>>>
>>> Does anyone see any value in offering this choice?  Is anyone 
>>> interested in
>>> implementing a no-host-object server?  If not, it doesn't seem worth 
>>> adding
>>> the choice.
>>>
>>> -Scott-
>>
>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Cathy Murphy'" <[email-masked]>
Cc: [email-masked]
Subject: RE: "External" hosts in EPP
Date: Tue, 18 Dec 2001 08:00:53 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Cathy Murphy [mailto:[email-masked]]
> Sent: Monday, December 17, 2001 10:09 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: RE: "External" hosts in EPP
> 
> 
> 
> Also, I'm wondering why you don't think a mixed-mode server is feasible.
> It seems straight-forward to require either the host-object or the
> host-attribute for a particular domain, but to prohibit both.

Cathy,

My thought was that if a server advertises that it does host objects, it
should do host objects consistently.  This would seem to make things easier
on the client, who can then manage all hosts the same way.

-Scott-

Date: Mon, 17 Dec 2001 22:25:32 -0800
To: Daniel Manley <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: "External" hosts in EPP
Cc: [email-masked]
Sender: [email-masked]

As I indicated in Salt Lake, I'm not a very big fan of "freedom of 
expression" for freedom of expression's sake.  This is the sort of 
option that makes it harder to interoperate and doesn't gain any 
additional functionality.

If someone (Cathy, Klaus?) has any reasons why it is actually 
beneficial to have the name server as an attribute as opposed to an 
object, I'll reconsider my stance.  I think all I've heard to this 
point is "that's how some registries do it already".  That's not 
really an argument to explain whether it's good behavior, though. 
Some registries allow out-of-zone glue, which we decided was a bad 
idea long ago.  The change to EPP is already going to require some 
change in how registrars interact with registries; I simply don't get 
how the requirement to create a host object before using it is 
particularly damaging.

On the flip side, if some registries require host object creation and 
some don't, this means registrars have to create substantially 
different logic for how they register domains in some TLDs (or IP 
registries) than they do in others.  That's not good.

Jordyn

At 6:51 PM -0500 12/17/01, Daniel Manley wrote:
>For the sake of freedom of expression, I guess it wouldn't hurt, but 
>we would probably not use it -- there's too many advantage to using 
>host objects.
>
>Dan
>
>Hollenbeck, Scott wrote:
>
>>>-----Original Message-----
>>>From: Jordyn A. Buchanan [mailto:[email-masked]]
>>>Sent: Monday, December 17, 2001 5:38 PM
>>>To: [email-masked]; Hollenbeck, Scott
>>>Cc: [email-masked]
>>>Subject: RE: "External" hosts in EPP
>>>
>>>
>>>At 11:58 AM -0800 12/17/01, [email-masked] wrote:
>>>
>>>>Scott,
>>>>
>>>>I'd agree that Asbjorn's proposal is reasonable one. OTOH, creating
>>>>objects for non-glue hosts seem counterintuitive, I'd prefer
>>>that we did
>>>
>>>>not have too. If others favor consistency, i'll drop my objection.
>>>>
>>>Consistency is nice.  Asbjorn's proposal has the added advantage 
>>>of making it much easier to change from a host without glue to an 
>>>in-zone host with glue by simply updating the object as opposed to 
>>>changing each and every domain that you have associated with a 
>>>particular out-of-zone host.
>>>
>>
>>OK, then, last concern:  I think I said something bogus when talking about
>>this at SLC.  I believe it was Sheer who asked if the intention was to allow
>>mixing of host-object and no-host-object modes, and I think I said "yes".
>>If I did, that's not what I meant to say.  My intention was to provide the
>>choice in the domain mapping such that a server could choose to implement
>>host objects (now with Asbjorn's suggested fix that some of you vaguely
>>remembered at the end of the discussion), or a server could choose to NOT
>>implement host objects and do delegations using name server info as domain
>>attributes.
>>
>>Does anyone see any value in offering this choice?  Is anyone interested in
>>implementing a no-host-object server?  If not, it doesn't seem worth adding
>>the choice.
>>
>>-Scott-

Date: Mon, 17 Dec 2001 22:08:49 -0500 (EST)
From: Cathy Murphy <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: [email-masked]
Subject: RE: "External" hosts in EPP
Sender: [email-masked]

On Mon, 17 Dec 2001, Hollenbeck, Scott wrote:

> OK, then, last concern:  I think I said something bogus when talking about
> this at SLC.  I believe it was Sheer who asked if the intention was to allow
> mixing of host-object and no-host-object modes, and I think I said "yes".
> If I did, that's not what I meant to say.  My intention was to provide the
> choice in the domain mapping such that a server could choose to implement
> host objects (now with Asbjorn's suggested fix that some of you vaguely
> remembered at the end of the discussion), or a server could choose to NOT
> implement host objects and do delegations using name server info as domain
> attributes.
> 
> Does anyone see any value in offering this choice?  

Yes.

> Is anyone interested in implementing a no-host-object server?  If not,
> it doesn't seem worth adding the choice.

I don't believe it is fair as a non-implementer (currently) to argue too
vehemently one way or the other, but I will point out that we (ARIN) are
going to a host-attribute model. This makes a lot of sense for the host
names we track for in-addr.arpa, but I don't know that the argument is
quite as strong for most other domains.

Even if it's decided to stick with a host-object only mode, we'd probably
make this part of an RIR-type extension down the road. 

Also, I'm wondering why you don't think a mixed-mode server is feasible.
It seems straight-forward to require either the host-object or the
host-attribute for a particular domain, but to prohibit both.

-Cathy

> 
> -Scott- 
>

Date: Mon, 17 Dec 2001 18:51:54 -0500
From: Daniel Manley <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: "External" hosts in EPP
Sender: [email-masked]

For the sake of freedom of expression, I guess it wouldn't hurt, but we 
would probably not use it -- there's too many advantage to using host 
objects.

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: Jordyn A. Buchanan [mailto:[email-masked]]
>>Sent: Monday, December 17, 2001 5:38 PM
>>To: [email-masked]; Hollenbeck, Scott
>>Cc: [email-masked]
>>Subject: RE: "External" hosts in EPP
>>
>>
>>At 11:58 AM -0800 12/17/01, [email-masked] wrote:
>>
>>>Scott,
>>>
>>>I'd agree that Asbjorn's proposal is reasonable one. OTOH, creating
>>>objects for non-glue hosts seem counterintuitive, I'd prefer 
>>>
>>that we did
>>
>>>not have too. If others favor consistency, i'll drop my objection.
>>>
>>Consistency is nice.  Asbjorn's proposal has the added advantage of 
>>making it much easier to change from a host without glue to an 
>>in-zone host with glue by simply updating the object as opposed to 
>>changing each and every domain that you have associated with a 
>>particular out-of-zone host.
>>
>
>OK, then, last concern:  I think I said something bogus when talking about
>this at SLC.  I believe it was Sheer who asked if the intention was to allow
>mixing of host-object and no-host-object modes, and I think I said "yes".
>If I did, that's not what I meant to say.  My intention was to provide the
>choice in the domain mapping such that a server could choose to implement
>host objects (now with Asbjorn's suggested fix that some of you vaguely
>remembered at the end of the discussion), or a server could choose to NOT
>implement host objects and do delegations using name server info as domain
>attributes.
>
>Does anyone see any value in offering this choice?  Is anyone interested in
>implementing a no-host-object server?  If not, it doesn't seem worth adding
>the choice.
>
>-Scott-
>

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: "External" hosts in EPP
Date: Mon, 17 Dec 2001 17:48:57 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Jordyn A. Buchanan [mailto:[email-masked]]
> Sent: Monday, December 17, 2001 5:38 PM
> To: [email-masked]; Hollenbeck, Scott
> Cc: [email-masked]
> Subject: RE: "External" hosts in EPP
> 
> 
> At 11:58 AM -0800 12/17/01, [email-masked] wrote:
> >Scott,
> >
> >I'd agree that Asbjorn's proposal is reasonable one. OTOH, creating
> >objects for non-glue hosts seem counterintuitive, I'd prefer 
> that we did
> >not have too. If others favor consistency, i'll drop my objection.
> 
> Consistency is nice.  Asbjorn's proposal has the added advantage of 
> making it much easier to change from a host without glue to an 
> in-zone host with glue by simply updating the object as opposed to 
> changing each and every domain that you have associated with a 
> particular out-of-zone host.

OK, then, last concern:  I think I said something bogus when talking about
this at SLC.  I believe it was Sheer who asked if the intention was to allow
mixing of host-object and no-host-object modes, and I think I said "yes".
If I did, that's not what I meant to say.  My intention was to provide the
choice in the domain mapping such that a server could choose to implement
host objects (now with Asbjorn's suggested fix that some of you vaguely
remembered at the end of the discussion), or a server could choose to NOT
implement host objects and do delegations using name server info as domain
attributes.

Does anyone see any value in offering this choice?  Is anyone interested in
implementing a no-host-object server?  If not, it doesn't seem worth adding
the choice.

-Scott-

Date: Mon, 17 Dec 2001 14:37:48 -0800
To: [email-masked], "Hollenbeck, Scott" <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: RE: "External" hosts in EPP
Cc: [email-masked]
Sender: [email-masked]

At 11:58 AM -0800 12/17/01, [email-masked] wrote:
>Scott,
>
>I'd agree that Asbjorn's proposal is reasonable one. OTOH, creating
>objects for non-glue hosts seem counterintuitive, I'd prefer that we did
>not have too. If others favor consistency, i'll drop my objection.

Consistency is nice.  Asbjorn's proposal has the added advantage of 
making it much easier to change from a host without glue to an 
in-zone host with glue by simply updating the object as opposed to 
changing each and every domain that you have associated with a 
particular out-of-zone host.

Jordyn

Date: Mon, 17 Dec 2001 11:58:50 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: <[email-masked]>
Subject: RE: "External" hosts in EPP
Sender: [email-masked]

Scott,

I'd agree that Asbjorn's proposal is reasonable one. OTOH, creating
objects for non-glue hosts seem counterintuitive, I'd prefer that we did
not have too. If others favor consistency, i'll drop my objection.

-rick

On Mon, 17 Dec 2001, Hollenbeck, Scott wrote:

> Rick,
>
> I working from Asbjorn's proposal; full reference here [1].  The argument I
> heard earlier today is that consistency will make implementation easier by
> minimizing "special case" behavior.
>
> -Scott-
> [1]
> http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00000.html
>
> > -----Original Message-----
> > From: Rick H Wesson [mailto:[email-masked]]
> > Sent: Monday, December 17, 2001 2:14 PM
> > To: Hollenbeck, Scott
> > Cc: [email-masked]
> > Subject: RE: "External" hosts in EPP
> >
> >
> >
> > Scott,
> >
> > I'm definately for what works. could you restate the proposal
> > in clearer
> > terms. for out-of-zone hosts would every registrar still need
> > to create a
> > host object? If so how is that easier, or is it just more consistant.
> >
> > thanks
> >
> > -rick
>

Subject: RE: "External" hosts in EPP
From: Daniel Manley <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: "'Rick H Wesson'" <[email-masked]>, [email-masked]
Date: 17 Dec 2001 15:01:34 -0500
Sender: [email-masked]

Yes, I think the great benefit is consistency.

Dan

On Mon, 2001-12-17 at 14:16, Hollenbeck, Scott wrote:
> Rick,
> 
> I working from Asbjorn's proposal; full reference here [1].  The argument I
> heard earlier today is that consistency will make implementation easier by
> minimizing "special case" behavior.
> 
> -Scott-
> [1]
> http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00000.html
> 
> > -----Original Message-----
> > From: Rick H Wesson [mailto:[email-masked]]
> > Sent: Monday, December 17, 2001 2:14 PM
> > To: Hollenbeck, Scott
> > Cc: [email-masked]
> > Subject: RE: "External" hosts in EPP
> > 
> > 
> > 
> > Scott,
> > 
> > I'm definately for what works. could you restate the proposal 
> > in clearer
> > terms. for out-of-zone hosts would every registrar still need 
> > to create a
> > host object? If so how is that easier, or is it just more consistant.
> > 
> > thanks
> > 
> > -rick

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Rick H Wesson'" <[email-masked]>
Cc: [email-masked]
Subject: RE: "External" hosts in EPP
Date: Mon, 17 Dec 2001 14:16:36 -0500
Sender: [email-masked]

Rick,

I working from Asbjorn's proposal; full reference here [1].  The argument I
heard earlier today is that consistency will make implementation easier by
minimizing "special case" behavior.

-Scott-
[1]
http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00000.html

> -----Original Message-----
> From: Rick H Wesson [mailto:[email-masked]]
> Sent: Monday, December 17, 2001 2:14 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: RE: "External" hosts in EPP
> 
> 
> 
> Scott,
> 
> I'm definately for what works. could you restate the proposal 
> in clearer
> terms. for out-of-zone hosts would every registrar still need 
> to create a
> host object? If so how is that easier, or is it just more consistant.
> 
> thanks
> 
> -rick

Date: Mon, 17 Dec 2001 11:14:27 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: <[email-masked]>
Subject: RE: "External" hosts in EPP
Sender: [email-masked]

Scott,

I'm definately for what works. could you restate the proposal in clearer
terms. for out-of-zone hosts would every registrar still need to create a
host object? If so how is that easier, or is it just more consistant.

thanks

-rick

On Mon, 17 Dec 2001, Hollenbeck, Scott wrote:

> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > Sent: Monday, November 05, 2001 1:56 PM
> > To: [email-masked]
> > Subject: "External" hosts in EPP
> >
>
> [snip]
>
> > I am wondering if the following might be worth considering:
> >
> > a) For in-zone hosts, everything is as described in EPP-host-03.
> >
> > b) Out-of-zone hosts, on the other hand, are "private" to a
> > RegistrAR; they are registered on a RegistrAR basis and will
> > be invisible/un-referable for other RegistrARs.
>
> I need to bring this up again.  We talked about the "out of zone" host issue
> at the SLC session, but now I'm not sure if the alternative I described
> (first sent to the list by Rick Wesson [1]) is the best way to tackle this
> problem.  As I started to look at the needed I-D updates I did a chalk talk
> with some of my implementers, and they believe that Asbjorn's suggestion may
> be more efficient to operate and easier to implement as it keeps
> host-related protocol operations consistent.
>
> I didn't see any objections to Asbjorn's suggestion on the list, just Rick's
> alternative and related discussion.  If there _are_ objections, now would be
> a good time to raise them.
>
> -Scott-
> [1]
> http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00001.html
>

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: "External" hosts in EPP
Date: Mon, 17 Dec 2001 13:17:47 -0500
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, November 05, 2001 1:56 PM
> To: [email-masked]
> Subject: "External" hosts in EPP
> 

[snip]

> I am wondering if the following might be worth considering:
> 
> a) For in-zone hosts, everything is as described in EPP-host-03.
> 
> b) Out-of-zone hosts, on the other hand, are "private" to a 
> RegistrAR; they are registered on a RegistrAR basis and will 
> be invisible/un-referable for other RegistrARs.

I need to bring this up again.  We talked about the "out of zone" host issue
at the SLC session, but now I'm not sure if the alternative I described
(first sent to the list by Rick Wesson [1]) is the best way to tackle this
problem.  As I started to look at the needed I-D updates I did a chalk talk
with some of my implementers, and they believe that Asbjorn's suggestion may
be more efficient to operate and easier to implement as it keeps
host-related protocol operations consistent.

I didn't see any objections to Asbjorn's suggestion on the list, just Rick's
alternative and related discussion.  If there _are_ objections, now would be
a good time to raise them.

-Scott-
[1]
http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00001.html

From: "Gould, James" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: More Private Comments
Date: Mon, 17 Dec 2001 10:39:42 -0500
Sender: [email-masked]

Scott,

I have no problem with items 1 and 2, but item 3 "no "content length: "
header in TCP transport.", I have a different proposal.  If there is a
desire to use a packet header, as an implementer I would find it more
efficient and simpler to use a network header that only includes the length
of the packet as a network byte order, four byte, unsigned integer.  By
using the network header, the packets will be framed and the framing can be
done without having to do string comparisons.  

Jim

> ----------
> From: 	Hollenbeck, Scott
> Sent: 	Monday, December 17, 2001 7:47 AM
> To: 	[email-masked]'
> Subject: 	More Private Comments
> 
> Last week I received a few private comments that will result in changes to
> the EPP documents.  Here's a quick summary:
> 
> Eric Brunner-Williams provided some suggested changes to the data
> collection
> policy elements.  Nothing radical, so I intend to make the changes he
> requested.
> 
> Dan Manley also sent me some private comments touching on 4 things:
> 
> 1)  auth info not required for transfer query command
> 
> This was discussed on the list a little while ago.  I intend to change
> things such that auth info is required to complete a transfer query.
> 
> 2)  inconsistent poll response format
> 
> This comment described an issue with the way <poll> messages are returned.
> In the current documents, the response <msg> element is overloaded to
> return
> the message.  Dan suggested a change the to the 1301 response code so that
> it has a consistent meaning, and putting the message within the <resData>
> element.  I disagreed with putting the message with <resData> because
> <resData> is currently used only for _object specific_ response data, and
> I
> suggested a compromise of putting the message within the <msgQ> element,
> like this:
> 
>   S:  <response>
>   S:    <result code="1301">
>   S:      <msg>Message dequeued.</msg>
>   S:    </result>
>   S:    <msgQ count="5">
>   S:      <qDate>2000-06-08T22:00:00.0Z</qDate>
>   S:      <polledMsg id="12345">Transfer requested.</polledMsg>
>   S:    </msgQ>
>   S:    <resData>
>   S:      <obj:trnData xmlns:obj="urn:ietf:params:xml:ns:obj"
>   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
>   S:        <obj:name>example</obj:name>
>   S:        <obj:trStatus>pending</obj:trStatus>
>   S:        <obj:reID>ClientX</obj:reID>
>   S:        <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate>
>   S:        <obj:acID>ClientY</obj:acID>
>   S:        <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate>
>   S:        <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate>
>   S:      </obj:trnData>
>   S:    </resData>
>   S:    <trID>
>   S:      <clTRID>ABC-12345</clTRID>
>   S:      <svTRID>54321-XYZ</svTRID>
>   S:    </trID>
>   S:  </response>
>   S:</epp>
> 
> This puts all of the <poll>-specific data in the <msgQ> element, keeps
> <resData> object-specific, and makes the response code structure
> consistent.
> At the end of our last private exchange Dan said he still wasn't
> comfortable
> with this suggested modification, so we may have more to talk about.
> 
> 3)  no "content length: " header in TCP transport.
> 
> Dan's comment is that it would be helpful for buffering purposes for the
> application reading from a socket to know the size of an incoming PDU.  he
> and I talked about it a bit, and came with a suggested change to the TCP
> mapping to define a short header of the form "type:length:value", where:
> 
> Type = "application/epp+xml"
> 
> Length: length of the value in octets, represented in hex.
> 
> Value: The <epp>...</epp> stuff.  So a TCP datagram containing an XML
> instance of length 128 decimal (80 hex) would look like this:
> 
> application/epp+xml:80:<epp>...</epp>
> 
> 4) Domain and Contact transfers in EPP
> 
> Dan and I talked a bit more about the comments he made during the SLC
> provreg session, but no specific changes were agreed to.
> 
> Eric and Dan, please feel free to expand on anything you think needs more
> explaining or if you disagree with my summations.
> 
> -Scott- 
> 
> 

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: More Private Comments
Date: Mon, 17 Dec 2001 07:47:54 -0500
Sender: [email-masked]

Last week I received a few private comments that will result in changes to
the EPP documents.  Here's a quick summary:

Eric Brunner-Williams provided some suggested changes to the data collection
policy elements.  Nothing radical, so I intend to make the changes he
requested.

Dan Manley also sent me some private comments touching on 4 things:

1)  auth info not required for transfer query command

This was discussed on the list a little while ago.  I intend to change
things such that auth info is required to complete a transfer query.

2)  inconsistent poll response format

This comment described an issue with the way <poll> messages are returned.
In the current documents, the response <msg> element is overloaded to return
the message.  Dan suggested a change the to the 1301 response code so that
it has a consistent meaning, and putting the message within the <resData>
element.  I disagreed with putting the message with <resData> because
<resData> is currently used only for _object specific_ response data, and I
suggested a compromise of putting the message within the <msgQ> element,
like this:

  S:  <response>
  S:    <result code="1301">
  S:      <msg>Message dequeued.</msg>
  S:    </result>
  S:    <msgQ count="5">
  S:      <qDate>2000-06-08T22:00:00.0Z</qDate>
  S:      <polledMsg id="12345">Transfer requested.</polledMsg>
  S:    </msgQ>
  S:    <resData>
  S:      <obj:trnData xmlns:obj="urn:ietf:params:xml:ns:obj"
  S:       xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
  S:        <obj:name>example</obj:name>
  S:        <obj:trStatus>pending</obj:trStatus>
  S:        <obj:reID>ClientX</obj:reID>
  S:        <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate>
  S:        <obj:acID>ClientY</obj:acID>
  S:        <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate>
  S:        <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate>
  S:      </obj:trnData>
  S:    </resData>
  S:    <trID>
  S:      <clTRID>ABC-12345</clTRID>
  S:      <svTRID>54321-XYZ</svTRID>
  S:    </trID>
  S:  </response>
  S:</epp>

This puts all of the <poll>-specific data in the <msgQ> element, keeps
<resData> object-specific, and makes the response code structure consistent.
At the end of our last private exchange Dan said he still wasn't comfortable
with this suggested modification, so we may have more to talk about.

3)  no "content length: " header in TCP transport.

Dan's comment is that it would be helpful for buffering purposes for the
application reading from a socket to know the size of an incoming PDU.  he
and I talked about it a bit, and came with a suggested change to the TCP
mapping to define a short header of the form "type:length:value", where:

Type = "application/epp+xml"

Length: length of the value in octets, represented in hex.

Value: The <epp>...</epp> stuff.  So a TCP datagram containing an XML
instance of length 128 decimal (80 hex) would look like this:

application/epp+xml:80:<epp>...</epp>

4) Domain and Contact transfers in EPP

Dan and I talked a bit more about the comments he made during the SLC
provreg session, but no specific changes were agreed to.

Eric and Dan, please feel free to expand on anything you think needs more
explaining or if you disagree with my summations.

-Scott- 

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: <check> in epp-05...
Date: Mon, 17 Dec 2001 07:11:49 -0500
Sender: [email-masked]

That inconsistency appears to be a remnant of the changes made between -04
and -05; it looks like I missed one.  The first statement is what's
intended, so I'll fix the second in this next round of edits.

-Scott- 

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, December 17, 2001 6:52 AM
> To: [email-masked]
> Subject: <check> in epp-05...
> 
> 
> Hi, 
>  
> in all the mappings, <check> is defined as being "used to 
> determine if an object may be provisioned within a repository". 
>  
> I am not sure if this has been mentioned before, but reading 
> 2.8.2 in the main draft again (epp-05), it states that 
> <check> is used "to determine if an object is known to the server". 
>  
> This is not the same thing, as an object might not exist (not 
> known to the server), but may not be provisioned for other 
> reasons (e.g., defensive registration for .NAME). I think the 
> text in 2.8.2 should be changed to be consistent with the mappings...

Date: 17 Dec 2001 11:52:00 -0000
From: [email-masked]
To: [email-masked]
Subject: <check> in epp-05...
Sender: [email-masked]

Hi, 
 
in all the mappings, <check> is defined as being "used to determine if an object may be provisioned within a repository". 
 
I am not sure if this has been mentioned before, but reading 2.8.2 in the main draft again (epp-05), it states that <check> is used "to determine if an object is known to the server". 
 
This is not the same thing, as an object might not exist (not known to the server), but may not be provisioned for other reasons (e.g., defensive registration for .NAME). I think the text in 2.8.2 should be changed to be consistent with the mappings... 

Asbjorn

-- 
 The information transmitted in this email is intended only for the person(s)
 or entity to which it is addressed and may contain proprietary, confidential
 and/or privileged material. If you have received this email in error, please
 contact the sender by replying and delete this email so that it is not
 recoverable. If you are not the intended recipient(s), any retention, review,
 disclosure, distribution, copying, printing, dissemination, or other use of,
 or taking of any action in reliance upon, this information is strictly
 prohibited and without liability on our part.

To: "Hollenbeck, Scott" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: <contact:ascii< and <contact:i15d> Elements 
Date: Wed, 12 Dec 2001 12:01:24 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

First, thanks for "standing-in" for me yesterday. Family business prevented
my attending SLC, and I appreciate the courtesy.

The proposal meets the concerns I had.

Cheers,
Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: <[email-masked]>
Subject: <contact:ascii< and <contact:i15d> Elements
Date: Wed, 12 Dec 2001 11:17:16 -0500
Sender: [email-masked]

I'm sending this note to the list to summarize the discussion we had at yesterday's meeting regarding the comment I received from Eric Brunner-Williams about the contact mapping's <contact:ascii> and <contact:i15d> elements.

In a private email message Eric asked me if "internationalized" is more appropriately described as "localized" in this context and why we need both forms at all.  At yesterday's meeting I suggested this is more of a localization issue and that yes, we need both forms, and there was no disagreement as far as I could tell.  I suggested schema changes to simplify the element structure and to better support localization needs.

Here are current schema slices:

<element name="ascii" type="contact:postalType"/>
<element name="i15d" type="contact:postalType"
 minOccurs="0"/>

<complexType name="postalType">
  <sequence>
    <element name="name" type="contact:postalLineType"/>
    <element name="org" type="contact:postalLineType"
     minOccurs="0"/>
    <element name="addr" type="contact:addrType"/>
  </sequence>
</complexType>

I suggested getting rid of the <contact:ascii> and <contact:i15d> elements, and instead using something like this (note that 'minOccurs="1"' is default behavior and doesn't need to be explicitly specified):

<element name="postalInfo" type="contact:postalType"
 maxOccurs="2"/>

Text would be changed to note that data intended for use in a global environment MUST be represented at least once in ASCII (preferably in the first occurrence); a second localized form is OPTIONAL.  In a closed environment where data is not intended for global use, local policy MAY define acceptable single instance forms.

-Scott-

Date: Mon, 10 Dec 2001 21:44:21 -0500
To: Sheer El-Showk <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Implementors?
Cc: Edward Lewis <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 8:34 PM -0500 12/10/01, Sheer El-Showk wrote:
>Hi,
>
>I might have some comments on implementating an application based on the
>EPP commands/data model.  I havn't actually been involved in implementing
>the protocol itself (XML parser), but have integrated protocol
>implementations into a registry and registrar application and have some
>feedback that might be useful.

Here's my "stock answer" to a potential implementation reporter:

I don't know how many others will be standing up, so figure on something
informal, up to 5 mins.  I'd prioritize on identifying the effort, a rough
estimate of maturity, then issues found.  (The latter may be lower priority
than will see the light of day.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

Date: Mon, 10 Dec 2001 20:34:05 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: <[email-masked]>, <[email-masked]>
Subject: Re: Implementors?
Sender: [email-masked]

Hi,

I might have some comments on implementating an application based on the
EPP commands/data model.  I havn't actually been involved in implementing
the protocol itself (XML parser), but have integrated protocol
implementations into a registry and registrar application and have some
feedback that might be useful.

Sheer

On Fri, 7 Dec 2001, Edward Lewis wrote:

> During our agenda, there is a block of time to talk about implementations.
> Only one person has stepped forward so far to speak.  One other person
> identified three other implementations.
>
> What we are seeking are "implementation issues with the EPP specs."  BTW -
> the last call on the core specs closes on Monday.
>
> If you plan to present something on this, let Jaap, myself, or the list
> know so we can divide up some time limits.  You don't need slides to
> present, and the more we learn of implementations, the better case we have
> for getting the EPP documents to the needed level.  (I'll leave "needed"
> open to interpretation.)
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]
>
> Opinions expressed are property of my evil twin, not my employer.
>
>

Date: Mon, 10 Dec 2001 15:19:08 +0100 (MET)
From: Elmar Knipp <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: Edward Lewis <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Comments on EPP at the Registrars Constituency 
Sender: [email-masked]

On Sat, 8 Dec 2001, Eric Brunner-Williams in Portland Maine wrote:

> Could you expand on your paranthetical comment?
>
> What will the AERO-registry use for a provisioning protocol, and what are
> the reasons for that choice?

Eric,

we will use the enhanced version 2.0 (March 2001) of the old CORE SRS
protocol (1999), which is based on simple key value pairs.

The main reason is that the functional specs for SITA were negotiated in
spring 2001 and the contracts between CORE and SITA are based on these
specs. Moreover, it was planned that the registrar functions are not only
done by ICANN registrars. Therefore the technical barriers on the
registrars site should be very low.

Admittedly, this is by no means cutting edge technology, but we needed a
compromise between ease of use and capability of expression for the
protocol.

Best regards,
Elmar

-- 
_____________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
                                        44227 Dortmund
                                        Germany
                                        Fon: +49 231 9703-0
     [email-masked]               Fax: +49 231 9703-200

To: Elmar Knipp <[email-masked]>
cc: Edward Lewis <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Comments on EPP at the Registrars Constituency 
Date: Sat, 08 Dec 2001 16:22:53 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Elmar,

Could you expand on your paranthetical comment?

What will the AERO-registry use for a provisioning protocol, and what are
the reasons for that choice?

Eric

Date: Fri, 7 Dec 2001 09:57:26 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Implementors?
Cc: [email-masked], [email-masked]
Sender: [email-masked]

During our agenda, there is a block of time to talk about implementations.
Only one person has stepped forward so far to speak.  One other person
identified three other implementations.

What we are seeking are "implementation issues with the EPP specs."  BTW -
the last call on the core specs closes on Monday.

If you plan to present something on this, let Jaap, myself, or the list
know so we can divide up some time limits.  You don't need slides to
present, and the more we learn of implementations, the better case we have
for getting the EPP documents to the needed level.  (I'll leave "needed"
open to interpretation.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

Subject: Re: auth_info for transfer query command
From: Daniel Manley <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Date: 06 Dec 2001 10:16:20 -0500
Sender: [email-masked]

Well, there's the possibility that it's bogus (possibility of getting it
wrong or a typo).  And I, as a registrar, would rather not inconvenience
the user with relatively lengthly process of email confirmations, etc,
just to find out at the last step that the auth info provided earlier is
invalid (when the registrant might not be at my beck and call to enter a
new value at that time).

Dan

On Fri, 2001-11-23 at 12:01, Eric Brunner-Williams in Portland Maine
wrote:
> > well, maybe this doesn't really apply in EPP.  I'm probably just stuck 
> ...
> New World, neh?
> 
> > but I would still like to validate the authInfo before issuing a 
> > transfer request.
> 
> Why?
> 
> Is ths registrar's authInfo presumptively bogus?
> Is this the common case?
> 
> Eric

Subject: RE: Provreg WG last call announcement
From: Daniel Manley <[email-masked]>
To: [email-masked]
Date: 06 Dec 2001 10:12:25 -0500
Sender: [email-masked]

On Mon, 2001-11-26 at 16:52, Hollenbeck, Scott wrote:
> <snip/>
> 
> As I said, passing registry-defined error codes in the <value> element isn't
> the way the <value> element is defined in the specs.  Thinking about this a
> bit more, though, I can see where it would be helpful to provide more than
> just the offending data in error situations - perhaps it makes more sense to
> pass back the whole offending element, with data included.  In the case of
> missing elements, or elements that are missing data, the server can just
> pass back an empty element (including the object namespace, if needed) to
> identify the problem.  In the example Sheer provided, it could look like
> this:
> 
> <value><contact:id/></value>
> 
> to note that a <contact:id> element is missing.
> 
> If additional response codes are needed, the best place to define them would
> be in the protocol's extension mechanism.
> 
> -Scott-

Then Liberty misinterpreted this as well.  Yes, I see from draft 05 of
EPP:

 - Zero or more OPTIONAL <value> elements that echo client-provided
    values that caused server error conditions.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: ISO References 
Date: Wed, 5 Dec 2001 13:15:05 -0500 
Sender: [email-masked]

> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2001 10:17 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]'
> Subject: Re: ISO References 
> 
> 
> Scott,
> 
> The reference to 639 in the <greeting> context is unnecessary, ditto in
the
> result codes context, and finally in the internationalization
consideration
> section.

Yup; thanks.

-Scott-

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: ISO References 
Date: Wed, 05 Dec 2001 10:16:54 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

The reference to 639 in the <greeting> context is unnecessary, ditto in the
result codes context, and finally in the internationalization consideration
section.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: ISO References
Date: Wed, 5 Dec 2001 09:31:53 -0500 
Sender: [email-masked]

Right now all of the EPP documents I've written that reference a
specification for date-time formatting are referencing ISO 8601:1988 (E).
There's an alternate reference (a profile of ISO 8601) developed in the impp
WG that was recently last-called by the IESG, "Date and Time on the
Internet: Timestamps" [1].  Assuming that the impp document advances, I
believe it would be more appropriate for provreg documents to cite the impp
WG document rather than the ISO document because ISO documents generally
aren't available for free.

I'd also like to remove references to ISO 639:1988 (E/F), "Code for the
representation of names of languages" since RFC3066 is already cited, and
RFC3066 cites ISO 639.

-Scott-

[1] http://www.ietf.org/internet-drafts/draft-ietf-impp-datetime-05.txt

Date: Mon, 3 Dec 2001 10:55:36 +0100 (MET)
From: Elmar Knipp <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: [email-masked], <[email-masked]>
Subject: Re: Comments on EPP at the Registrars Constituency
Sender: [email-masked]

On Thu, 29 Nov 2001, Edward Lewis wrote:

> EPP is a policy neutral protocol specification, so this policy has no
> impact on the definition and implemetation of the protocol.  The 2-letter
> restriction would impact the use of the protocol.
>
> E.g.
>
> You could form a valid EPP request to ask for a two-letter domain.  The
> response from the registry would deny the request (if the registry banned
> two-letter names).  If the registry allowed two-letter domains, the request
> may be granted (other things being equal).

Edward,

I fully agree. E.g. the registry for AERO will allow two-letter domains.
(But the AERO-registry will not be based on EPP for some other reasons.)

Best regards,
Elmar

-- 
_____________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
                                        44227 Dortmund
                                        Germany
                                        Fon: +49 231 9703-0
     [email-masked]               Fax: +49 231 9703-200

From: Bruce Tonkin <[email-masked]>
To: "'Rick H Wesson'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Comments on EPP at the Registrars Constituency
Date: Mon, 3 Dec 2001 15:33:40 +1100 
Sender: [email-masked]

Also to my knowledge it was never put forward by the Registrars Constituency
at ICANN.
Some things have a habit of occuring top down at ICANN, in response to
advice from groups such as the Government Advisory Committee.

Bruce Tonkin

> -----Original Message-----
> From: Rick H Wesson [mailto:[email-masked]]
> Sent: Friday, November 30, 2001 5:57 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Comments on EPP at the Registrars Constituency
> 
> 
> 
> Paul,
> 
> Within EPP there are no provosions to prevent 2 letter SLD 
> registrations.
> 
> The policy is an ICANN one, see section B of Appendix K of 
> the ICANN TLD
> agreements.
> 
> http://www.icann.org/tlds/agreements/unsponsored/registry-agmt
-appk-26apr01.htm

-rick

On Thu, 29 Nov 2001 [email-masked] wrote:

> Hi,
>
> I've just subscribed to the list, and I have a query.
>
> At the recent ICANN Registrars' constituency meeting
> I understand that there was a proposal to include a
> prohibition on two letter codes at the second level of
> the Domain Name System.
>
> This sounds strange - If EPP does not permit any two
> letter codes at the second level, what will this mean for
> all the reservations of country codes under .info, for
> example?
>
> Can you shed some light on this situation ?
> Does it only apply to ENUM identifiers ?
>
> Thanks,
>
>  Paul
>
>  P. S. Mylotte
>  IP Addressing & Naming
>  BTexact Technologies
>  Adastral Park
>  01473 606333 / + 44 1473 606333
>  [email-masked]
>