Subject: RE: Contractual Rules again

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 21 Jul 2003 16:11:47 -0400

John

I think the rules the LO will be able to express will not
give sufficient precision in some (many?) reasonable
uses.  A written contract is more flexible.  
I also think we have some work to do to convince
providers, users and consumers of geolocation information
that the rules in the LO are enforced.  I think many
people will be much more comfortable with a written
document than a protocol mechanism they don't understand.
Over time, the latter may resolve itself.

I think many (most?) service providers will insist on
a written contract.  Again, IANAL, but I think many
HAVE to provide a written privacy policy to customers.
I think it will be some time before service providers
are confident that they understand the limits of
the LO privacy rules, and can reasonably be assured
that they can honor them in a way that is legally defensible
when things go wrong.  We can move these folks in the
direction we want by encouraging them to post the
contract, and including a pointer to it in the LO.
Much better than just having the contract and not
referring to it.

None of this is to suggest that the imbedded rules
have no value.  On the contrary, I think they will eventually
have great value.  I worry about getting started.

Therefore, I think:
	An indicator that a written agreement exists governing
		the use of the information is essential
	A URI pointing to it is useful, although not essential.
		I think it is more useful to the user and the
		consumer of the geoloc information than it is to
		the service provider.
	The URI should explicitly be named a pointer to
		a specimen of the contract.

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.

Brian

> -----Original Message-----
> From: John Morris [mailto:[email-masked]]
> Sent: Sunday, July 20, 2003 11:12 PM
> To: [email-masked]
> Subject: RE: Contractual Rules again
> 
> 
> Brian,
> 
> I think you and I actually agree.  My concern is that any uri 
> pointing to a 
> "contract" CANNOT be permitted to influence what the protocol 
> does.  People 
> designing a geopriv-compliant application cannot be left in a 
> position of 
> wondering "gosh, if a contract is referenced do I have to do anything 
> different because of that reference".  So I am suggesting 
> that if we refer 
> to a uri with a contract, the protocol document should say 
> something to the 
> effect that the uri is provided solely for reference and a geopriv 
> complaint application should not alter its actions in any way 
> because a uri 
> is referenced.
> 
> If we cannot say something like this, then perhaps we should 
> not have the 
> contract uri in the first place.  I would be concerned if a bunch of 
> privacy rules were stated in the location object, AND a uri was also 
> included to a "contract," an application developer would 
> wonder what he or 
> she should do about the contract (if anything).
> 
> Perhaps a better approach would be to avoid the use of the 
> work "contract" 
> altogether and instead include a "uri to an text document 
> that provides 
> additional relevant information" (and make clear that the 
> content of the 
> text document need not be read by a geopriv application and 
> will not affect 
> the result of a geopriv transaction).  A geopriv compliant 
> application MAY 
> offer an option to display the content to an end user.
> 
> John
> 
> At 07:59 PM 7/20/03 -0400, Rosen, Brian wrote:
> >You get into a legal issue and IANAL.
> >If you have a legally binding agreement between two parties
> >and one unilaterally decides to change the terms,
> >I think you have a problem.  I suspect the
> >other party can ignore the unilateral terms,
> >and use the terms in the contract.
> >
> >I think this is like a contract and the standard
> >boilerplate on a purchase order.  If a contract
> >exists, the boilerplate is not effective.
> >
> >I don't think this is a subject for an IETF
> >document.  I think allowing the uri is useful.
> >I don't think getting into which terms hold,
> >a written contract or the rules of an LO when
> >they conflict, should even be mentioned.  That's
> >not protocol, or object, design, it's
> >a legal interpretation.
> >
> >Brian
> >
> > > -----Original Message-----
> > > From: John Morris [mailto:[email-masked]]
> > > Sent: Thursday, July 17, 2003 11:25 AM
> > > To: [email-masked]
> > > Subject: RE: Contractual Rules again
> > >
> > >
> > > My 2 cents are that this could be a worthwhile element if its
> > > significance
> > > is unambiguously defined.  I would be concerned, for example,
> > > with any
> > > suggestion that a conflict between rules expressed in a LO
> > > are overridden
> > > by an external contract.  But if as  Brian suggests it 
> could be a uri
> > > provided for the sake of reference, that would be valuable. John
> > >
> > > At 07:54 AM 7/17/03 -0400, Rosen, Brian wrote:
> > > >Agree, how about
> > > >   The uri represents a prior mutual agreement, and its presence
> > > >   is used only as confirmation.  Even in the absence of 
> the document
> > > >   pointed to by the URI, the contract terms hold.  The contract
> > > >   terms in effect at the time the LO was received govern the
> > > >   rules for use of the LO.
> > > >
> > > >So, "prior" implies you can't get a contract by just 
> getting the LO.
> > > >
> > > >Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Henning Schulzrinne [mailto:[email-masked]]
> > > > > Sent: Thursday, July 17, 2003 7:20 AM
> > > > > To: Rosen, Brian
> > > > > Cc: [email-masked]
> > > > > Subject: Re: Contractual Rules again
> > > > >
> > > > >
> > > > > My concern with any external reference is
> > > > >
> > > > > - what happens if it can't be accessed
> > > > >
> > > > > - what happens if the content changes either 'naturally' or
> > > > > maliciously,
> > > > > before the time of retention expires?
> > > > >
> > > > > These are both solvable, but it needs to be clearly specified.
> > > > >
> > > > > Rosen, Brian wrote:
> > > > > > I expect that most often it will be the service
> > > provider's standard
> > > > > > contract.  The point of a uri is to be able to confirm that
> > > > > > the agreed rules apply.  I wouldn't want to limit this.
> > > > > > For that matter, a contract is not exclusive (unless it says
> > > > > > that it is); you may be able to use the rules defined in
> > > > > > the object, and in addition have some kind of subtlety not
> > > > > > expressible in the rules.
> > > > > >
> > > > > > I'd certainly be agreeable to stating that this is for
> > > a contract,
> > > > > > i.e. something both parties willingly entered into
> > > prior to sending
> > > > > > the information.  That would obviate the problem 
> you are worried
> > > > > > about (a statement of limits that the other party doesn't
> > > > > necessarily
> > > > > > agree to).  I think that limits the use, but it also limits
> > > > > the abuse.
> > > > > >
> > > > > > You certainly could imagine systems that refuse to accept or
> > > > > > provide location when it was subject to some 
> written contract
> > > > > > it didn't know about.  You could also imagine systems that
> > > > > > popped up panels that required you to accept the rules
> > > > > > before proceeding.
> > > > >
> > >
>

---

From: John Morris <[email-masked]>
Date: Mon, 21 Jul 2003 17:25:17 -0400

At 4:11 PM -0400 7/21/03, Rosen, Brian wrote:

<snip>
>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: Mon, 21 Jul 2003 18:03:19 -0400

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:

> 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.
> 
> 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.
> 
> 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.
> 
> 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: John Morris <[email-masked]>
Date: Mon, 21 Jul 2003 18:22:52 -0400

Henning's message highlights a difference between my  thinking and (I 
think) Brian's thinking.   I would view the "contract" flag/URI as, 
in theory, under the control of the Target/Rule Maker, not the 
service provider.  If a service provider has so much control over the 
geopriv application that it can force the user to set the contract 
flag/URI, then presumably the service provider can simply prevent the 
user from setting specific privacy rules the provider does not like. 
But I'm not sure it would be geopriv in that case....

At 6:03 PM -0400 7/21/03, Henning Schulzrinne wrote:
>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".
>
>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.
>
>>is any reference to an external contract, to be geopriv compliant 
>>the application must enforce the rules provided in this protocol." 
>>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 
>>(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.
>>
>>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: Andrew Newton <[email-masked]>
Date: Mon, 21 Jul 2003 20:16:41 -0400

John Morris wrote:
> [...], so I would vote (or hum) to 
> omit it altogether.

Speaking as somebody who reads RFC's and attempts to implement them, 
this is my preference.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Jul 2003 20:21:38 -0400

Can you describe the application where your model would be used? I don't 
see how any modest-scale provider can, even if willing, inspect the 
"contract". Any sane provider would simply have to reject anything with 
such a contract pointer, unless you want to provide employment for 
countless contract inspectors...

If it's just a presence provider, presumably it is just acting as 
something similar to a mail service or web storage provider, i.e., it 
just provides transmission (or storage) facilities. In that model, the 
rules file can be used by the service to limit disclosure to watchers, 
for example, but a 'contract' wouldn't do much good except as my second 
person-to-person case noted.

In other words, in any reasonable commercial setting that I can think 
of, individual targets can't realistically insist on personalized contracts.

John Morris wrote:

> think) Brian's thinking.   I would view the "contract" flag/URI as, in 
> theory, under the control of the Target/Rule Maker, not the service 
> provider.  If a service provider has so much control over the geopriv 
> application that it can force the user to set the contract flag/URI, 
> then presumably the service provider can simply prevent the user from 
> setting specific privacy rules the provider does not like. But I'm not 
> sure it would be geopriv in that case....