Re: [sipcore] SIPCORE Location Conveyance -00 submitted

["Thomson, Martin" <[e-mail]>]

Hi James,

I'll preface this email with the usual note that it's shocking how old this document is.  This is an important document from my perspective, and it needs to be published.

Your rewritten intro is a great improvement.  I didn't read in detail beyond this, but it's certainly much clearer.

I note that the example PIDF-LO documents still contain errors.  Refer to 5491 or one of my previous reviews for details.

The one major flaw that I highlighted in my WGLC comments to the former SIP WG remains.  The document does not establish strict semantics for the location it conveys.  Is the location information indicated in a Geolocation header belong to the entity identified in the From header?  Or is it the UAC that sends the request?  While this might seem intuitive, it's not.  To complicate things, the PIDF-LO can contain alternative identification information, there is a potential for confusion or conflict.

This document needs to be really clear about who the location belongs to within the context of the exchange.

--Martin

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of James M. Polk
> Sent: Thursday, 25 June 2009 4:56 AM
> To: [e-mail]
> Subject: [sipcore] SIPCORE Location Conveyance -00 submitted
> 
> SIPCORE WG
> 
> I have just submitted draft-ietf-sipcore-location-conveyance-00.txt
> here
> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-
> conveyance-00.txt
> 
> This is the subsequent version from SIP Location Conveyance -13.
> 
> Here's what's changed in SIPCORE-00 compared to the SIP-13 version:
> 
> - Understanding that readability was a main concern - I reduced the
> Intro section to 4 paragraphs (less than half of what was in -13)
> 
> - simplified the Overview section, added a couple of flow figures to
> show how location is transmitted within a SIP request in a message
> body, and as a URI reference similar to content indirection.
> 
> - moved some of the Intro text to the Overview section, but cut out a
> lot of what was in the Overview section that is explained later in the
> draft.
> 
> - Removed all the UA-1 vs UA-2 stuff, and replaced it with Alice and
> Bob references, making this easier to read.
> 
> - I reduced the terminology section, and what was left that was
> already defined in another RFC, is now the same text from that RFC
> (which is also referenced each time).
> 
> - I toned down the 2119 text for servers inserting location into a
> request from SHOULD NOT to not RECOMMENDED, based on WG comment.
> 
> - I added RFC5491 (PIDF-LO Usage) and RFC 4483 (SIP Content
> Indirection) as references.
> 
> - I removed text saying future error codes can be specified in each
> category, as that seems to confuse some about the meaning of this.
> But added text saying more granular error codes that have the same
> action by a UA can be created.
> 
> - I'm not an S/MIME expert, and was told (a long time ago) it can be
> used just for signing, and not encrypting.  Two from this WG seemed
> to adamantly disagree with this, so I removed that text about signing
> only.
> 
> - Clarified a point that is allowed in PIDF-LO, and that SIP
> shouldn't attempt to overcome this - that if Bob sends Alice his
> location, and sets his <retransmission-allowed> to "yes"; within the
> <retention-expiry> time (in which the location is still valid), if
> Bob transfers Alice to Carol, that PIDF-LO privacy rules implicitly
> allow Alice to tell Carol where Bob is. This came up in another
> forum, and is a current byproduct of the policy rules within the
> PIDF-LO and this document cannot overcome those.
> 
> A benefit to this policy is that if Alice calls for emergency help,
> and somehow is routed to the wrong PSAP (emergency call center),
> PSAP-1 can transfer Alice's location to PSAP-2 (i.e., the correct
> PSAP serving Alice's area). Therefore, this PIDF-LO policy is not
> necessarily a hole.  BTW - the default value of
> <retransmission-allowed> has always been to "no".
> 
> - I removed the term sighter from the doc (a legacy term within
> Geopriv), and replaced it with locator.
> 
> Comments are welcome
> 
> James
> 
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore

------------------------------------------------------------------------------------------------
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]