To:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc:
"'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From:
Edward Lewis <edlewis@arin.net>
Date:
Mon, 21 Apr 2003 11:21:29 -0400
In-Reply-To:
<5BEA6CDB196A4241B8BE129D309AA4AF10E698@vsvapostal8>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] Proposed Text for Contact Mapping DisclosureElements
I've found that we have consensus to leave dcp as mandatory, not distinguish between personal and corporate data, and in general have no concerns about the words included below from Scott. BUT, in going back through relevant threads and what was verbally discussed in SF I have a couple of items that need to be addressed. There were questions from Joe Abley in http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00101.html that seem to be unaddressed by this proposal. Particularly: "2. A complete proposal should specify whether a "dnd"d field should be distinguished from a non-existent field when presenting data to clients (e.g. via <info> commands). If it should, then the proscribed manner in which that should be done should be included for <info>. "3. What should <check> return if the object being checked is marked as dnd="true" and the client doing the <check> is one to which disclosure is prohibited?" The proposed text here does not specify the impact of a private flag on the server's "write" functions. I think that this can be fixed by merely specifying the protocol actions in these cases. Adjunct to that discussion, the following needs to also be addressed: how can the setter of the privacy data check the privacy setting? How can it be changed? (I recall asking this in SF.) The closest that you come here is the text near the lower-case "should." (Which in itself is a no-no. ;)) PS - could you also make sure we haven't introduced other lower case RFC 2119 words in the documents. There are a few that have popped in (outside of the boilerplate) in recent edits. At 15:41 -0400 4/15/03, Hollenbeck, Scott wrote: >I'd like to propose adding the following text to section 2 of the contact >mapping document to move forward with the element privacy approach described >here: > >http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00134.html > >I am assuming that we are past the point of discussing whether or not the >direction described in this new text is one we need to follow. Specific >replacement text would be _most_ helpful if you see something that you don't >like. > >"2.9 Disclosure of Data Elements and Attributes > >The EPP core protocol requires a server operator to announce data collection >policies to clients; see section 2.4 of [EPP]. In conjunction with this >disclosure requirement, this mapping includes data elements that allow a >client to identify elements that require exceptional server operator >handling to allow or restrict disclosure to third parties. > >A server operator announces a default disclosure policy when establishing a >session with a client. When an object is created or updated, the client can >specify contact attributes that require exceptional disclosure handling >using an OPTIONAL <contact:disclose> element. A server operator MAY reject >any transaction that requests disclosure practices that do not conform to >the announced data collection policy. Once set, disclosure preferences can >be reviewed using a standard contact information query. > >If present, the <contact:disclose> element MUST contain a "flag" attribute. >The "flag" attribute contains an XML Schema boolean value. A value of >"true" or "1" (decimal one) notes a client preference to allow disclosure of >the specified elements as an exception to the stated data collection policy. >A value of "false" or "0" (decimal zero) notes a client preference to not >allow disclosure of the specified elements as an exception to the stated >data collection policy. > >The <contact:disclose> element MUST contain at least one of the following >child elements: > ><contact:name type="int"> ><contact:name type="loc"> ><contact:org type="int"> ><contact:org type="loc"> ><contact:addr type="int"> ><contact:addr type="loc"> ><contact:voice> ><contact:fax> ><contact:email> > >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 should >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." > >Well, that's the proposed text, with appropriate changes required elsewhere >in the document to maintain consistency. Fire away. > >-Scott- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I'm sorry, sir, your flight is delayed for maintenance. We are pounding out the dents from the last landing."