Subject: RE: Contractual Rules again

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 22 Jul 2003 14:03:56 -0400

Well, I guess I was thinking primarily about 3, which I
expect is really the most common case, but on reflection,
I guess I have to agree with you that it's just wasted bits.
I think the actual problem occurs in 1, where the contract
governs what the service provider would accept from a user
and the legal issue raises its head when the user specifies
something different from the contract when he sends the LO,
but I understood the direction is usually wrong for bits in 
the object in that case.  

So, I guess I withdraw my suggestion.

It does make me wonder if we need to say, somewhere, that
there has to be a mechanism, possibly in the using protocol?
to specifically reject the proffered rule.  I expect the
text would have to say that in that case the recipient
could not make use of, or retain the location information.

Brian 

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, July 21, 2003 6:03 PM
> To: John Morris
> Cc: Rosen, Brian; [email-masked]
> Subject: Re: Contractual Rules again
> 
> 
> I think there may be two different views of which direction 
> the contract 
> goes and what the model is. There are at least three cases, all with 
> different requirements:
> 
> (1) Service provider sets contract: For example, my map-and-direction 
> service provider wants to tell me what privacy rules it 
> commits to when 
> I upload my location information. There is no way that any service 
> provider will inspect or honor any pointer to an agreement 
> offered by an 
> individual - just doesn't scale. This pointer can't be in the 
> LO object 
> that I upload to the map-and-direction provider, obviously. 
> Thus, I need 
> to be able to retrieve these privacy rules before I send the LO since 
> sending the object has to indicate agreement with those rules.
> 
> (2) User-to-user: I hand my location to a friend and want to tell him 
> what he can do with this information. I doubt that a reference to a 
> contract is very helpful there. Individual users aren't going 
> to draft 
> their individual contracts, so either we'll have millions of amateur 
> lawyers or, more likely, common standard contracts that can just be 
> enumerated ("European Data Protection rules apply"). If I have to 
> inspect and understand a twenty-page contract in legalese each time a 
> buddy sends me his location information, the system is effectively 
> unusable. <notes> rules, kept very short, will do the trick for real 
> needs, as in "I'm buying a present for my wife, so don't tell 
> her where 
> I am".
> 
> (3) Service provider to third party: E.g., my map-and-directions 
> provider sends my location information to some subcontractor. 
> If the two 
> have a contractual, long-term relationship, there is little point in 
> including the reference to that contract a few million times a day.
> 
> Thus, I'm trying to figure out under which scenario this 
> truly adds value.
> 
> 
> John Morris wrote:
> 
> > At 4:11 PM -0400 7/21/03, Rosen, Brian wrote:
> > 
> > <snip>
> > 
> >> I don't think there is any point in having an IETF document
> >> opine what happens if there is a written contract, there
> >> are rules expressed in the LO, and they conflict.
> > 
> > 
> > To be clear, I am not suggesting that an IETF document 
> declare that "in 
> > the event of a conflict between protocol rules and external 
> contract, 
> > then rules will or should prevail."  Instead, I would 
> suggest that the 
> > protocol documents would say "whether or not there is any 
> reference to 
> > an external contract, to be geopriv compliant the application must 
> > enforce the rules provided in this protocol." Thus, I would 
> avoid any 
> > suggestion of a legal analysis, and instead simply provide 
> clear and 
> > unambiguous guidance to the folks actually coding a geopriv 
> application.
> > 
> > But, if even this guidance is deemed inappropriate, then I 
> think the 
> > inclusion of a pointer to a contract (or even a flag saying 
> "a contract 
> > applies to this transaction")  would introduce ambiguity without 
> > actually advancing anyone's legal interest, so I would vote 
> (or hum) to 
> > omit it altogether.   If the IETF goes out of its way to include a 
> > contract flag or URI, but then is silent as to the effect 
> of the flag or 
> > URI, then at best an implementor faces an ambiguous 
> situation, and at 
> > worst the protocol invites a service provider to make the 
> privacy rules 
> > irrelevant by contract.
> > 
> > A service provider may well (at least in some countries) be able to 
> > declare by contract that "we will ignore any privacy rules 
> that you set 
> > when you send location," and the effectiveness (or lack of 
> > effectiveness) of such a provision would be unaffected if 
> the protocol 
> > omits any contract reference.   In other words, if an 
> > override-by-contract is permitted, it would be permitted 
> even without a 
> > flag.
> > 
> > All in all, FWIW, I would omit any reference to a contract. 
>  But as I 
> > said in my prior e-mail, perhaps a URI reference to an 
> external relevant 
> > document (of any type) could be included without 
> introducing ambiguity.
> > 
> > John
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 22 Jul 2003 14:14:06 -0400

> could not make use of, or retain the location information.

The one case where this might occur is if a rule contains something like 
"do not pass to FBI" and I can't guarantee that I will be able to honor 
the rule. (Another one is a rule like "don't pass to Alice", when you 
are sending the LO to Alice, i.e., a misconfiguration.)

I don't think we want to go to the "here are my rules, please accept and 
I'll give you my location information" model, as that has some rather 
hairy negotiation issues. The best you can do is probably to do this 
implicitly, by handing the recipient an 'empty' LO (rules only) and if 
the recipient accepts it, deliver real information next time. This 
doesn't deal with recipients that change their mind ("now that I know 
that you're in a seedy part of town, I can't resist telling all my 
friends"), but we just need to assume some amount of consistency in the 
recipient during one subscription.

---

From: Chris Apple <[email-masked]>
Date: Wed, 23 Jul 2003 12:39:54 -0400

As far as the document is concerned, I think there needs to be a reference
for URI/URL added. I know what the terms mean, but the normative references
for those terms seem to be missing from the document. That's a defect that
should be repaired.

I also think there should be some text added to the Security Considerations
section exploring the issue of how, within the context of the protocol, you
should (or should not) expect to be able to determine the authenticity of
whatever document is being referenced by a URL/URI. The same could be said
for other security issues associated with externally referenced documents
(or even services)....you could argue that this protocol should or shouldn't
support such features natively - but the issues need to be described in
the Security Considerations section even if consensus is that such
(optionally
used?) features are not to be supported natively.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email-masked]

http://www.dsi-consulting.com