Subject: [sipcore] SIPCORE Location Conveyance -00 submitted

From: "James M. Polk" <[email-masked]>
Date: Wed, 24 Jun 2009 13:56:27 -0500

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 24 Jun 2009 18:06:18 -0500

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: Thursday, 25 June 2009 4:56 AM
> To: [email-masked]
> Subject: [sipcore] SIPCORE Location Conveyance -00 submitted
> 
> SIPCORE WG
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> 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]

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 24 Jun 2009 19:03:09 -0500

At 06:06 PM 6/24/2009, Thomson, Martin wrote:
>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.

your previous emails have never had any details to know what you're 
talking about... just as this one doesn't. Since I cannot determine 
what you want changed, knowing I'm not a mind reader, the text 
remains as it is.

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

Please read the parts you say you didn't read this time to read the 
text that's been in the doc for quite some time now that discusses this.

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

here's a hint: this is (and has always been) done in the PIDF-LO, 
this is not (and never has been) part of any of the SIP headers.

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 24 Jun 2009 19:33:39 -0500

Inline,

> From: James M. Polk [mailto:[email-masked]]
> Sent: Thursday, 25 June 2009 10:03 AM
> To: Thomson, Martin; [email-masked]
> Subject: RE: [sipcore] SIPCORE Location Conveyance -00 submitted
> 

I don't have time right now to detail the myriad ways.  For now all I can do is suggest that you validate the XML.  Before you do though, ensure that you remove all instances of processContents="lax" so that the validator doesn't decide to skip validation on anything.

Offhand, I noted that provided-by usage is incorrect (remove it), you omitted the mandatory deviceID element from device, timestamp comes after status, retransmission-allowed is of the 'xs:boolean' type which means s/no/false/ (contrary to what might be indicated in RFC4119).

> text that's been in the doc for quite some time now that discusses

I just re-read the first 10 pages, plus the descriptions of UAC and UAS behaviour without finding anything other than vague hints.  In all cases you talk about "target", "Target" or "Alice" without describing how that identity is established or linked to any protocol parameters.  I'd expect this to be more clearly described before you get into the protocol details.

I did find this hidden at the bottom of S4.1:

        The <dm:device id>
        element [RFC5491] in the PIDF-LO XML indicates whose location
        is contained in the PIDF-LO.

This is potentially of no use:  SIP peers do not necessarily have the necessary context to make sense of these identifiers; deviceID is not mandatory; and for privacy reasons I would recommend to anyone implementing this that they do not provide this information.

(The correct reference here is RFC 4479 - presence data model, which defines this field; and I suspect that you mean <deviceID>...</deviceID>, not <device id="xxx">, which has other semantics.)

> this is not (and never has been) part of any of the SIP headers.

Now this is a problem indeed.  The possibility that the PIDF-LO contains an unlinked pseudonym (c.f. RFC 3693) has to be considered.  Note also the above problems.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 25 Jun 2009 15:18:40 +0200

So what IS the semantics of something like:
Geolocation: <tel:+351912795300; inserted-by="node1.example.com"

Does it express the location of the sender?
Can it express the location of the receiver?
Can the meaning depend on who inserted it?
Where does it say so?

Also the use of the word Target is extremely confusing in a SIP setting,
even if you define it to mean something else then what it means normally.

BR,
/Hans Erik van Elburg

On Thu, Jun 25, 2009 at 2:33 AM, Thomson, Martin
<[email-masked]>wrote:

> I don't have time right now to detail the myriad ways.  For now all I can
> do is suggest that you validate the XML.  Before you do though, ensure that
> you remove all instances of processContents="lax" so that the validator
> doesn't decide to skip validation on anything.
>
> Offhand, I noted that provided-by usage is incorrect (remove it), you
> omitted the mandatory deviceID element from device, timestamp comes after
> status, retransmission-allowed is of the 'xs:boolean' type which means
> s/no/false/ (contrary to what might be indicated in RFC4119).
>
> I just re-read the first 10 pages, plus the descriptions of UAC and UAS
> behaviour without finding anything other than vague hints.  In all cases you
> talk about "target", "Target" or "Alice" without describing how that
> identity is established or linked to any protocol parameters.  I'd expect
> this to be more clearly described before you get into the protocol details.
>
> This is potentially of no use:  SIP peers do not necessarily have the
> necessary context to make sense of these identifiers; deviceID is not
> mandatory; and for privacy reasons I would recommend to anyone implementing
> this that they do not provide this information.
>
> (The correct reference here is RFC 4479 - presence data model, which
> defines this field; and I suspect that you mean <deviceID>...</deviceID>,
> not <device id="xxx">, which has other semantics.)
>
> Now this is a problem indeed.  The possibility that the PIDF-LO contains an
> unlinked pseudonym (c.f. RFC 3693) has to be considered.  Note also the
> above problems.
>
> >
> > >--Martin
> > >
>
>