Re: lastVerified: optional vs. extension

[janusz sienkiewicz <janusz@libertyrms.info>]

I agree with Hong.
From XML schema point of view, adding lvDate element looks like a simple
change (as complex as the fax element). From the implementation point of
view it is not that simple.  Significant changes may be required to EPP
object mapping documents.

Treating the feature as an EPP extension seems to be a reasonable way to
go.

Regards,

Janusz Sienkiewicz

Hong Liu wrote:

> Rick,
>
> Please see my comments in line.
>
> Cheers,
>
> --Hong
>
> --- Rick Wesson <wessorh@ar.com> wrote:
> > On Fri, 6 Dec 2002, Hong Liu wrote:
> >
> > > I concur with Scott's observation. I would say
> > that
> > > extension seems to be the way to go for
> > lastVerified.
> >
> >
> > Hong,
> >
> > My proposal was to have the follwoing XML in the
> > contact-1.0.xsd:
> >
> >   <complexType name="infDataType">
> > ...
> >       <element name="lvDate" type="dateTime"
> > minOccurs="0"/>
> > ...
> >   </complexType>
> >
> > You have advocated an extention. prposal is as
> > complex as the "fax"
> > element. Registries can express this critical value
> > that many
> > organizations are asking for or they may not.
> >
> As I explained in another email, even from a technical
> perspective, adding this element is not as trivial as
> you described above. I would not repeat why it is
> different than "fax" here.
>
> If it is in the base protocol, all registries will
> have to deal with it, whether they support it or not,
> in order to be EPP compliant. The business logic for
> registry policy will be driven down to the element
> level. We should try to avoid such design if we have
> an alternative.
>
> > Why do you prefer to add the burdon of an extention
> > whic is much more
> > vobers, requireing name space negoiation by the
> > server and extion
> > libraries for the client to address this ICANN and
> > IESG issue?
> >
> That is exactly the beauty of extension, and XML
> namespace separation. The server makes it explicit in
> terms of what namespaces it supports at session
> negotiation. XML parsing will fail right away if a
> client uses a namespace that the server does not
> support. The server business logic is a lot cleaner
> than handling it at the element level.
>
> Most importantly, we don't know whether the element by
> itself is sufficient for different policies to be set
> up. It is premature to incorporate it in the base EPP
> spec. What if different registries collect different
> data for the same purpose? Then you need to use
> extension anyway.
>
> >
> > -rick
> >
> >
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com