RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol

"Drage, Keith \(Keith\)" <[email protected]>
Newsgroups gmane.ietf.sip,gmane.ietf.geopriv
Message-ID <[email protected]>
(As individual)

At the moment I'm afraid I don't buy the argument.

Starting from RFC 3693, section 3 defines:

	Using Protocol: A protocol that carries a Location Object.

For which we also have:

      Location Object (LO): An object conveying location information
         (and possibly privacy rules) to which Geopriv security
         mechanisms and privacy rules are to be applied.

Section 4 defines the primary GEOPRIV entities and 
this defines a model:

(Now for SIP location by value, the using protocol is SIP, and the SIP
UAC is the location server, and the SIP UAS (or possibly proxy) is the
location recipient.)

For SIP location by reference, the using protocol is the dereferencing
protocol, i.e. the reader of the Location header is the location
recipient, and the server referenced by the URI is the location server.
The SIP protocol is this case is not a using protocol, because it does
not contain a location object. Therefore it falls outside the rules of
using protocols specified by GEOPRIV.

I see nothing in RFC 3693 that prevents a third party entity holding
location on behalf of a user, and in fact some of the examples seem to
show exactly that.

Now presumably all the security and privacy constraints relating to the
user are covered by the using protocol. The fact that I tell you that X
has my location doesn't mean you are entitled to receive it. Further,
while there may be some other protocol (or bilateral agreement or
whatever) that covers the relationship between X and the user, I do not
see any requirement in RFC 3963 that mandates that.

At the moment you seem to be arguing that information about who has my
location is subject to some form of consent framework over and above
that required by the using protocol itself. I'm afraid I do not see that
argument at all. Agreed the URI of the server may say something about
the user's location, but to me this is covered by the following
statement in RFC 3693:

   Excluded from this definition is the determination of location
   information wholly without the knowledge or consent of the Target (or
   the Target's network or access service provider), based on generally
   available information such as an IP or e-mail address.  In some
   cases, information like IP address can enable someone to estimate (at
   least roughly) a location.  Commercial services exist that provide
   rough location information based on IP addresses.  Currently, this
   type of location information is typically less precise than the type
   of location information addressed in this document.  Although this
   type of location computation still raises significant potential
   privacy and public privacy concerns, such scenarios are generally
   outside the scope of this document.

We have specified lots of things in SIP and many other protocols that
need lots more rules if this is going to become an issue.

Furthermore, if I follow your argument to its logical conclusion, then I
would seem to need lots more work before I can put a URI that points at
a location server in an ordinary email, yet I seem to be able to do that
today.

So in conclusion, I see location by reference as two independent
protocols:

-	a location using protocol which is the deferencing protocol, and
which obviously has to meet the using protocol requirements.

-	a URI carried by SIP which is subject to no normative
constraints about who can read or whatever, which identifies the
location server.

I agree that there may be arguments for giving more information to the
location recipient so that the location recipient knows how to populate
the dereferencing protocol. Some of this may however already be covered
by other SIP protocol work, and to me is not directly necessary to make
the protocol work. If we agree any information in time, we can include
it, otherwise it can be added at a later stage. 



Regards

Keith

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email protected]] 
> Sent: 27 July 2006 16:36
> To: Andrew Newton
> Cc: IETF SIP List; GEOPRIV
> Subject: Re: [Geopriv] teasing apart: http as a GEOPRIV using protocol
> 
> Hi Andy,
> 
> if we talk about location-by-reference then I think all 
> solutions need more specification work.
> 
> If we talk about end host adding a reference then we need to 
> have a story about the source of the reference. This is 
> subject to the current
> Geopriv-L7 DT work that is not yet finished.
> 
> If we are talking about the case where the SIP proxy adds a 
> reference (no matter what type of reference it is) then also 
> further work is needed.
> 
> I think we should develop an HTTP based solution since it is 
> very simple.
> 
> Btw, I am not sure that the name 'using protocol' is actually 
> appropriate in this case. We haven't used the term using 
> protocol for the Geopriv L7 work either. Terminology is hell 
> in this area.
> 
> Ciao
> Hannes
> 
> Andrew Newton wrote:
> > There have been a number of opinions regarding HTTP as a 
> using protocol.
> > 
> > I'd like to know, how many people believe that HTTP requires no or  
> > very little specification to meet the requirements in RFC 3693 and  
> > RFC 3694.  If you believe this, what basis do you have for this 
> > conclusion?  Or do you believe more specification needs to 
> be done,  
> > but it is possible for HTTP to be a GEOPRIV using protocol?
> > 
> > Finally, how many people believe that HTTP should not be a 
> using  protocol?
> > 
> > -andy
> > 
> > _______________________________________________
> > Geopriv mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> > 
> > 
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.