Re: [ietf-provreg] legal entity vs individual person

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

Suppose a non-null <dcp> is contained in <greeting>.

Suppose the reply (to <greeting>) is <login>

Suppose a subsequent <contact:create> element containes a <contact:disclose>
element.

  An EPP error response MUST be returned if a <create> command can not  
  be processed for any reason.

  2308    "Data management policy violation"

We don't actually know the following:

	1. how to compare the comparable (if any) child elements of the
	   server-side <dcp> and the client-side <c:d>.

It is possible that dcpRecipientType=="ours" means the same thing as the
<contact:disclose flag="0">, but so far this is unspecified.

	2. if 1 (above) were answered, and the evaluation of the two blobs
	   of syntax returned a result other than "equal", which of the two
	   blobs would take precident.

It is possible that inequality (unspecified) could be totally, or partially
ordered (also unspecified), and some evaluations result in a 2308, and some
not.

  A server MAY end a session due to client inactivity or excessive
  client session longevity.  The parameters for determining excessive
  client inactivity or session longevity are a matter of server policy
  and are not specified by this protocol.

	3. if 2 (above) were answered, and some evaluation could result in
	   2308, and servers MAY terminate sessions for reasons not specified,
	   which of the two, 2308 or sever-side session termination, takes
	   precident.

It is possible that a server could "drop" sessions that would result in an
2308 error, and establish a new session with an "improved" <dcp> that would
not cause a 2308 error.

	4. if 3 (above) were answered, and a server "tunes" its <dcp> to not
	   generate a 2308 for a specific <contact:disclose>, what changes
	   to the <dcp> that are not strictly required to avoid a 2308 are
	   allowed. (I know this can be restated better.)

It is possible that a server could "abandon" its <dcp> upon discovery of a
<contact:disclose>, and restate its <dcp> as the offered :disclose only.
A non-null <contact:disclose> could remove any restriction on the collection
policy, without detection by a client.

Well, I've got to take care of some real-life stuff. I see evaluation as a
non-trivial problem. In simple terms, Randy tells GoDaddy to <dnp> him out
of whois:43, GoDaddy says "Yup", and flogs a <c:d f=0> at VGRS, which had
a EU-friendly <dcp> in its greeting, with "strong protection" (burn before
reading, no body gets anything, etc.). VGRS sees the GoDaddy <c:d f=0>, and
flickers the session, now with a DoubleClick-friendly <dcp>, which has Randy
opt-in to arbitrary repurpose, infinite data retention, and infrequent baths.
Randy isn't in whois:43. Is he happy?

Scott wrote:
> Well, that's the proposed text, with appropriate changes required elsewhere
> in the document to maintain consistency.  Fire away.

OK. I hope this helps. Of course, hopes and effects are rarely coincident.

Appologies to GoDaddy and VGRS, I simply needed some real names to (ab)use.

Eric