Subject: RE: Contractual Rules again

From: "Rosen, Brian" <[email-masked]>
Date: Sun, 20 Jul 2003 19:59:37 -0400

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 05:12:17 +0200

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