RE: [ietf-provreg] References for Today's Host Object Discussion

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> Unless I am missing something, Scott, can you propose some text that 
> would accommodate nameservers-as-attributes?  Based on:
> 
> >- Allowing a choice between name server host objects and 
> name server domain
> >attributes.
> >    http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00024.html

Sure.  Here's what I have in mind:

This is the structure currently used in the domain mapping to specify name
server host objects:

<element name="ns" type="eppcom:labelType"
 minOccurs="0" maxOccurs="unbounded"/>

This can be changed to be a choice of either host objects or host
attributes, like this:

<element name="ns" type="domain:nsType" minOccurs="0"/>
<!-- Name servers are optional. -->

<complexType name="nsType">
  <choice>
    <element name="hostObj" type="eppcom:labelType"
     maxOccurs="unbounded"/>
    <element name="hostAttr" type="domain:hostAttrType"
     maxOccurs="unbounded"/>
  </choice>
</complexType>
<!-- Name servers are either objects or attributes. -->

<complexType name="hostAttrType">
  <sequence>
    <element name="name" type="eppcom:labelType"/>
    <element name="addr" type="host:addrType"
     minOccurs="0" maxOccurs="unbounded"/>
  </sequence>
</complexType>
<!-- If attributes, addresses are optional and follow the
structure defined in the host mapping. -->

I'd then have to add text to explain how this works in the descriptions of
the <create> and <update> commands, but that text would be pretty
straightforward.  Note that this structure allows one to use either host
objects as name servers or host attributes as name servers, but it doesn't
allow mixing of the two on a domain object.  I remember there being some
opposition to the idea of mixing the modes back when this was originally
discussed on the list, so I've elected to not allow it here.

The benefit to this is that it allows client and server to specify name
servers without using host objects if they so desire.  A server operator
would be free to implement a policy that requires host objects if they're
supported, or to not support host objects at all.

I might have to replicate all of the host address elements in the domain
mapping to completely eliminate the dependency on the host mapping (note
that the elements above require an import of the host schema to obtain the
address data type).  Consider what you see above as a proposal that might
need to be modified once I start testing it a bit.

-Scott-