Re: "private" Element Attribute

[janusz sienkiewicz <janusz@libertyrms.info>]

Wouldn't it be more convenient to redefine private attribute as enumeration
versus boolean? For example:

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

could be replaced by:

<contact:email access=enumValue>jdoe@example.com</contact:email>

Where enumValue could be: private, public, noWhois, etc.

Among other petential benefits this approach could eliminate the inconvenience
of using <extension>.

Regards,

Janusz Sienkiewicz

"Hollenbeck, Scott" wrote:

> 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