[ietf-provreg] Question regarding contact:disclose behaviour.

[Alexander Mayrhofer <axelm@nic.at>]

Hi,

we're moving towards EPP enabling .at, but there is an open question
regarding how "contact:disclose" should work (we are going to use that for
hiding certain elements in a legacy whois service). Section 2.9 of RFC3733
contains the following example about "contact:disclose":

   Example <contact:disclose> element, flag="0":

   <contact:disclose flag="0">
     <contact:email>
     <contact:voice>
   </contact:disclose>

   In this example, the contact email address and voice telephone number
   can not be disclosed.  All other elements are subject to disclosure
   in accordance with the server's data collection policy.

   Example <contact:disclose> element, flag="1":

   <contact:disclose flag="1">
     <contact:name type="int">
     <contact:org type="int">
     <contact:addr type="int">
   </contact:disclose>

   In this example, the internationalized contact name, organization,
   and address information can be disclosed.  All other elements are
   subject to disclosure in accordance with the server's data collection
   policy.

What is unclear to me: What happens to the elements which are _not_
mentioned in the disclose section? The text is not entirely clear to me,
because it refers to the data collection policy of the server - i'd see two
options:

1) Elements which are not mentioned in a "contact:disclose" section are
automatically set to the opposite state, eg. a:

  <contact:disclose flag="0">
     <contact:email/>
  </contact:disclose>

would mean that fax, addr, etc. are automatically set to "flag=1".

or...

2) Elements which are not mentioned in a "contact:disclose" section retain
the state they had before, so a sequence of

  [first command]

  <contact:disclose flag='0'>
     <contact:email/>
  </contact:disclose>

  [second command]

  <contact:disclose flag='0'>
     <contact:fax/>
  </contact:disclose>

would still keep "email" set to "flag=0".


I'd appreciate feedback on how that was originally intended, and would like
to see some clarifying text about this in 3733bis...

Additionally, i'd like to hear from implementors about their currently
implemented policy regarding this - i think it would be very confusing to
clients if server behave differently...

thanks,

Alex Mayrhofer
nic.at / enum.at