RE: [Geopriv] Location-by-value in a SIP Location Header

At the moment, I do not see the location by reference as unsolveable. 

There are specific security considerations that need to be taken into account, and these are by no means complete at the moment. 

I do not at the moment see putting a location within a SIP header as an alternative to location by reference; rather I see it as another potential solution which SIP have discussed and rejected in the past.

regards

Keith

> -----Original Message-----
> From: Marc Linsner [mailto:[email protected]]
> Sent: 19 July 2006 14:32
> To: 'Drage, Keith (Keith)'
> Cc: [email protected]; [email protected]
> Subject: RE: [Geopriv] Location-by-value in a SIP Location Header
> 
> 
> Keith,
> 
> A couple of issues with your statements below:
> 
> - As you point out in #2, the SIP group has identified two mechanisms,
> location by value in the body and location by reference in 
> the header.  The
> issue stems from the fact that location by reference is yet to be a
> mechanism.  This has been mired down with technical 
> discussions in GeoPriv
> for a long time.
> 
> - Your list of reasons needs to be expanded to include 'the identified
> mechanism has no technical solution'.
> 
> As you express, there are many reasons to complete this work 
> quickly, but to
> have a total solution it is important to examine these alternatives
> mechanisms.  Like you, I certainly hope this comes to a 
> resolution very
> soon.
> 
> Thanks,
> 
> -Marc-
> 
> 
> 
> > 
> > (As SIP WG chair)
> > 
> > Just to set some limits to this discussion, let me state 
> > where we are in the progression of this work item. Remember 
> > it is now being classed as urgent and we need to get an RFC 
> > out of the door, and the SIP chairs are working with the 
> > GEOPRIV chairs as to the quickest way to do this:
> > 
> > 1)	The requirements in the document have been approved by 
> > the SIPPING group (a long time ago) and therefore we should 
> > not be inventing new requirements without a clear use case 
> > that has clear agreement.
> > 
> > 2)	The SIP group have already identified that two 
> > mechanisms to support these requirements should be documented 
> > (e.g. the location by value in a body, and the location by 
> > reference in a header. These two mechanisms appear to support 
> > all the current requirements. In other words, SIP have agreed 
> > the technical solution, and we are in the stage of trying to 
> > document it.
> > 
> > 3)	Using a data URL appears to add a third mechanism, if 
> > only because it will at least need to have a different set of 
> > security considerations documented for it. 
> > 
> > We should only be adding a third mechanism if:
> > 
> > a)	the existing mechanism can be shown not to meet all the 
> > requirements; or
> > b)	the use case where it offers advantages is clearly 
> > identified; and
> > c)	the compatibility issues are addressed (i.e. does the 
> > UAS need to support all of what is now three mechanisms or is 
> > there some other support requirement); and
> > d)	this can be shown as impossible to be discussed as a 
> > future extension.
> > 
> > Could I also suggest (in addition to the above) that if 
> > people want to proceed with this discussion, it would be 
> > appropriate to submit an i-d targeted at the SIP WG 
> > identifying the technical solution proposed (with as much 
> > completeness as is possible). And remember if you think this 
> > discussion is needed, it needs to occur quickly. 
> > 
> > regards
> > 
> > Keith
> > 
> > > -----Original Message-----
> > > From: Thomson, Martin [mailto:[email protected]]
> > > Sent: 19 July 2006 00:15
> > > To: Rosen, Brian; Henning Schulzrinne
> > > Cc: [email protected]; [email protected]
> > > Subject: RE: [Geopriv] Location-by-value in a SIP Location Header
> > > 
> > > 
> > > If you want technically feasible, I can post a URI to the 
> list that 
> > > includes a complete PIDF-LO with DSig.  It's a little long though.
> > > 
> > > I'm not suggesting that this a good idea, but I see no reason to 
> > > prevent it.
> > > 
> > > > -----Original Message-----
> > > > From: Rosen, Brian [mailto:[email protected]]
> > > > Sent: Tuesday, 18 July 2006 11:07 PM
> > > > To: Henning Schulzrinne
> > > > Cc: [email protected]; [email protected]
> > > > Subject: RE: [Geopriv] Location-by-value in a SIP 
> Location Header
> > > > 
> > > > Perhaps some enlightenment is in order.  It's not clear to
> > > me how you
> > > > dsig a Data uri in a Location header (or maybe you mean
> > > dsig the pidf-lo
> > > > and put both the pidf-lo and the signature in the Data 
> > URI) somehow?
> > > > Are there some examples of this kind of thing elsewhere?
> > > > 
> > > > If we are ignoring technical arguments (as opposed to use
> > > cases), it's
> > > > out of forgetfulness, and not willfulness.  What were you
> > > referring to?
> > > > 
> > > > Brian
> > > > 
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Henning Schulzrinne [mailto:[email protected]]
> > > > Sent: Tuesday, July 18, 2006 8:59 AM
> > > > To: Rosen, Brian
> > > > Cc: [email protected]; [email protected]
> > > > Subject: Re: [Geopriv] Location-by-value in a SIP 
> Location Header
> > > > 
> > > > Brian, James:
> > > > 
> > > > this is simply false. If desired, XML-DSIG is a well-known and 
> > > > accepted mechanism to achieve integrity. Such 
> specification is no 
> > > > longer than the MUST NOT that you propose. You are also 
> willfully 
> > > > ignoring the other technical arguments made as part of this
> > > discussion.
> > > > 
> > > > Henning
> > > > 
> > > > On Jul 18, 2006, at 8:48 AM, Rosen, Brian wrote:
> > > > 
> > > > > There was a desire expressed by Hannes to provide a way
> > > for a proxy to
> > > > > insert location-by-value.  He had proposed a SIP 
> > Location header 
> > > > > specific way.  In IETF66, Henning suggested just using 
> > a data URI.
> > > > >
> > > > > Doing this may run afoul of the geopriv location 
> > privacy concerns, 
> > > > > because there is no way for the user to sign the header 
> > to provide 
> > > > > assurance that the PIDF, and specifically the retention 
> > and other 
> > > > > policy bits are preserved.  Note that S/MIME provides 
> sufficient
> > > integrity
> > > > > protection for a body.  It's probably okay to use TLS 
> > per hop to 
> > > > > provide privacy, but not integrity protection.  The authors
> > > believe that there
> > > > > is no really compelling use case for this feature, and
> > > the effort to
> > > > > define acceptable security mechanisms for location data
> > > in a header
> > > > > would be a significant effort, further delaying the draft.
> > > > >
> > > > > We propose, therefore, to state in 
> > sip-location-conveyance, that a 
> > > > > Data URI MUST NOT be used in the Location header until a
> > > standards track
> > > > > RFC
> > > > > defines a suitable security mechanism to protect the 
> > PIDF in the 
> > > > > header.
> > > > >
> > > > > Brian and James
> > > > >
> > > > > _______________________________________________
> > > > > Geopriv mailing list
> > > > > [email protected]
> > > > > https://www1.ietf.org/mailman/listinfo/geopriv
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Geopriv mailing list
> > > > [email protected]
> > > > https://www1.ietf.org/mailman/listinfo/geopriv
> > > 
> > > --------------------------------------------------------------
> > > ----------------------------------
> > > This message is for the designated recipient only and may contain 
> > > privileged, proprietary, or otherwise private information.
> > > If you have received it in error, please notify the sender 
> > immediately 
> > > and delete the original.  Any unauthorized use of this email is 
> > > prohibited.
> > > --------------------------------------------------------------
> > > ----------------------------------
> > > [mf2]
> > > 
> > 
> > _______________________________________________
> > 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