using protocols

While I tend to agree with the sentiment that the term "using protocol" has been lawyered into obsolence in this discussion, I do think the term remains material to the scope of the location conveyance draft, and the question of how restrictive or permissive the URI schemes defined for the Location header might be.

Strictly speaking, when a SIP message carries only a reference to location information, it isn't really "conveying" location at all - the protocol that is used to follow that reference and retrieve location information is the "using protocol" as understood in RFC3693. Placing a CID, or SIP/SIPS, and for the most part PRES URI scheme in the Location header are all cases where SIP does or will do the work of conveyance, and will serve as a using protocol. That seems to me to be as good a reason as any to draw a line in the sand and say that these schemes are what the baseline SIP location conveyance draft will cover. I.e., When a SIP/SIPS URI appears in the Location header, the location will end up being conveyed by SIP; it seems pretty reasonable for the SIP location conveyance draft to cover this case.

I don't think that the syntax of the Location header should forbid the use of any particular URI schemes. Moving forward there's no obstacle to a separate draft defining HTTP conveyance or whatever else. The early failures of the GEOPRIV working group to arrive at a consensus on an approach to HTTP were mostly caused by the use cases which were being proposed, which were out of parity with much of what the rest of the group was trying to accomplish (and by "early" here I mean pre-HELD by a long shot).

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email protected]]
> Sent: Thursday, July 27, 2006 12:27 PM
> To: Henning Schulzrinne
> Cc: IETF SIP List; GEOPRIV; Andrew Newton
> Subject: Re: [Geopriv] Re: [Sip] teasing apart: http asa GEOPRIV using
> protocol
> 
> 
> Hi Henning,
> 
> I would very much appreciate to treat this topic in the way 
> you proposed 
> it below.
> 
> A few minor comments:
> 
> Henning Schulzrinne wrote:
> > With hindsight, I think the term 'using protocol' has been 
> the source of 
> >  more word-lawyering than engineering insight. I personally 
> find the 
> > distinctions
> > 
> >   - first person vs. third person (i.e., find out location 
> about myself 
> > vs. find out location about some third party)
> > 
> >   - location vs. location + identity
> > 
> >   - token-based authorization vs. identity-based authorization
> > 
> > more helpful.
> > 
> > Token-based authorization hands the recipient a key that 
> allows him to 
> > get a location object, without caring as to who is retrieving the 
> > object. ("Anybody seeing this SIP request can convert the 
> token into an 
> > LO.") Identity-based naturally uses some authenticated identity to 
> > release that information.
> 
> 
> In past common policy discussions we also differentiated between 
> limited use addresses and trait-based authorization. A token 
> would match 
> the latter.
> 
> In some sense we seem to be using limited use addresses in 
> most of the 
> cases when we talk about the location-by-references. The difference 
> between limited use addresses and trait-based authorization 
> is small in 
> this particular usage environment.
> 
> 
>   Strictly speaking, this is only a question of
> > a level of indirection, since proving identity usually 
> involves proving 
> > possession of a secret.
> 
> I guess there are some further differences with regard to the 
> lifetime 
> of the different identifiers, the ability to revoke rights, 
> the number 
> of entities that one can hide behind these identifiers and 
> the storage 
> implications.
> 
> > We've been trying to get at some of these distinctions with 
> the sighting 
> > vs. using protocol terminology, but that distinction also seems to 
> > degenerate into discussions more suited for a law school or 
> theology 
> > department than an engineering organization.
> > 
> > For example, by strict definition, LoST would be a 'Using Protocol' 
> > since it "carries a Location Object", but I hope we all 
> agree that this 
> > is silly. We had earlier agreed that the location-by-DHCP 
> also were not 
> > Using Protocol, even though they obviously carry a location 
> object of 
> > some form.
> 
> Currently LoST is not a using protocol since it does not 
> carry a PIDF-LO 
> although some folks would like to use a PIDF-LO; HELD was a using 
> protocol before we turned the problem into a Location Configuration 
> problem; RELO never was a using protocol;
> 
> Isn't this confusing?
> 
> > 
> > Privacy issues apply iff
> >   - third person
> >   - location + identity (not just location)
> > 
> > The L7 discussion was about 'first person' and 'location 
> only' (although 
> > the latter is subject to debate, depending on whether one 
> considers an 
> > IP address of identifying an individual or not).
> 
> That was before we added the Location-by-Reference and 
> subscription-URI 
> concept ....
> 
> > 
> > Depending on the circumstances, SIP-based retrieval can 
> either involve 
> > privacy concerns (subscribe to [email protected]) or not 
> (subscribe to 
> > location of one-time random unlinkable identifier 
> > [email protected]). There can also be different 
> privacy concerns 
> > depending on the perspective. For example, if a SIP request 
> contains 
> > both an identity and the location retrieval reference, this raises 
> > privacy concerns for the proxy, but the LIS may not have any such 
> > concerns since it may only be the repository of these 
> randomly-named 
> > objects, without tie to an identity.
> 
> Ciao
> Hannes
> 
> > Henning
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 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