RE: [ietf-provreg] Proposed Text for Contact Mapping Disclosure Elements

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

> 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.

No one else had any issues or inputs, so I let them go.  Since you've
brought them up again I'll address them now.

> 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>.

I disagree with the basic premise.  We already have a situation in the
protocol where fields might not be disclosed if the querying client fails to
provide authorization information.  If you're authorized, you see it all.
If you're not, you don't.  So do I need to add a sentence in the <info>
description that describes the primacy of authorization?

> "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 <check> command doesn't disclose attribute information.  The object
being checked isn't marked with dnd="true", so <check> behavior should
remain as currently specified.

> 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.

What impact, other than in a <create>?  The description of the <create>
command will be modified to describe how the information can be set
initially.  This change is what I meant by my "consistency" statement at the
end of the proposal.

> 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. ;))

The description of the <info> command will be modified to describe how the
information can be viewed.  The description of the <update> command will be
modified to describe how the information can be changed.  That's again what
I meant by my "consistency" statement at the end of the proposal.

> 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.

I only see one "should", but I'll check for others.

-Scott-