"private" Element Attribute

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

A heads-up to the WG related to IESG comment #8, described here [1]:

In the ongoing IESG discussion of our EPP documents, we (Patrik and I) have
come to the conclusion that we might need to add a new attribute to every
object element in the domain, contact, and host mappings.  This boolean
attribute, "private", will be used to note that the value of an element
should not be disclosed to third parties.  It will have a default value of
"false" meaning it is ok to disclose info.  Additional constraints can be
defined using the protocol extension mechanism.

Here are some examples:

<contact:email private="true">jdoe@example.com</contact:email>

<domain:name private="false">example.com</domain:name>

<host:addr ip="v4" private="true">192.1.2.3</host:addr>

<extension>
  <noWhois><contact:email></noWhois>
</extension>

(This extension example isn't syntactically valid, but I wanted it to be
short, clear, and to the point without the clutter needed to make it valid.
In this case it means that the email address should not be published via
whois.)

Patrik's point is that we start getting into the policy issues that bogged
us down earlier if we try to pick and choose the elements to which the
attribute should be added.  That's a good point that can get us past where
we failed a year or so ago, but it means that server operators might have to
deal with some operational inconsistencies.  We'll have to add some notes to
explain that server policy might not recognize the value of an attribute if
it's turned on (like in the address example above) when turning on the
attribute is counter to some policy.

If anyone has any issues with this approach, please mention them now.

-Scott-

[1]
http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.html