Re: "External" hosts in EPP

[Sheer El-Showk <sheer@saraf.com>]

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:jordyn@register.com]
> >>>> Sent: Monday, December 17, 2001 5:38 PM
> >>>> To: wessorh@ar.com; Hollenbeck, Scott
> >>>> Cc: ietf-provreg@cafax.se
> >>>> Subject: RE: "External" hosts in EPP
> >>>>
> >>>>
> >>>> At 11:58 AM -0800 12/17/01, wessorh@ar.com 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-
> >>
> >
> >
>
>
>