Re: [sipcore] SIPCORE Location Conveyance -00 submitted

 

> -----Original Message-----
> From: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk
> Sent: 24 June 2009 19:56
> To: sipcore@ietf.org
> 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-locatio
n-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.
[JRE] Why does this constitute a toning down? I though SHOULD NOT and
NOT RECOMMENDED were the same in RFC 2119. Can somebody please explain
the subtle distinction?

John


> 
> - 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
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>