Subject: Re: [sipcore] SIPCORE Location Conveyance -00 submitted

From: "Elwell, John" <[email-masked]>
Date: Thu, 02 Jul 2009 10:50:42 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James M. Polk
> Sent: 24 June 2009 19:56
> To: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 02 Jul 2009 12:28:02 -0500

>NOT RECOMMENDED were the same in RFC 2119. Can somebody please explain

I thought (think?) (NOT) RECOMMENDED doesn't need to be implemented, 
and SHOULD (NOT) does, for PS to DS movement.

I can change the text to "inadvisable"  otherwise

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 02 Jul 2009 19:11:03 +0100

> From: James M. Polk [mailto:[email-masked]] 
> Sent: 02 July 2009 18:28
> To: Elwell, John; [email-masked]
> Subject: RE: [sipcore] SIPCORE Location Conveyance -00 submitted
> 
[JRE] RFC 2119 states:
"4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label."

Therefore they mean the same thing.

> I can change the text to "inadvisable"  otherwise
[JRE] If you want to tone it down, you would indeed need to use
non-normative text. But it depends what the WG wants - I don't have an
opinion.

John

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 02 Jul 2009 15:18:04 -0500

>Therefore they mean the same thing.

I obviously have to re-read 2119 again...  <mumble>...

(especially bad for a WG chair not to remember this)

>non-normative text. But it depends what the WG wants - I don't have an

This is text that has been in the ID for a number of years now, 
perhaps 6-8 wg reversions - if not since the the concept of servers 
inserting location was introduced with LbyRs, without changing 
meaning. So I don't want to change the normative  meaning too much - 
and definitely not from normative to informative. I was responding to 
one opinion that wanted the whole text removed, by trying to soften 
it. I obviously blew that...

James

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 03 Jul 2009 00:14:38 -0500

At 08:18 AM 6/25/2009, Hans Erik van Elburg wrote:
>So what IS the semantics of something like:
>Geolocation: <tel:+351912795300; 
>inserted-by="<http://node1.example.com>node1.example.com"

Conveyance mandates that a URI be in the locationValue of a 
Geolocation header value. A tel: number is not supported.

Only 4 URI schemes are supported:
- a RFC 2392 defined cid-URL that indicates the location is by-value 
as a message body in the SIP request;
- a sip:-, sips:- and pres:-uri which are location URIs to 
dereference the PIDF-LO are also supported.

if a cid: doesn't appear in the Geolocation header value, then the 
URI MUST be deferencebale at a Location Server.  a tel: doesn't 
accomplish this.

According to Conveyance, everything must end up with  location in a 
PIDF-LO format.

anything else is proprietary at this point, or requires an extension 
in a future RFC to become a standard in any form.

>Does it express the location of the sender?

it can, but doesn't have to.

in the PIDF-LO, there is a <presence> element with a entity= 
attribute which identifies the target - whether the UAC or another entity.

>Can it express the location of the receiver?

yes it can.

>Can the meaning depend on who inserted it?

it depends on who the presence document is identifying. if there are 
more than 1 presence documents in the SIP request (by-value or 
by-reference), the target identifier identifies who each is 
identifying (see below).

>Where does it say so?

Is "it" the ID or is "it" asking where is this identified?

If "it" is the ID, I will make this clearer in the next rev, but here 
is answer:

The <presence> element of the PIDF-LO has a entity= attribute that 
identifies who the target is for *this* location.

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

"Target" in Geopriv is very similar to "presentity" in Presence, 
which is close to SIP.

wrt changing these terms -- that ship has sailed, my friend

>BR,
>/Hans Erik van Elburg
>
>On Thu, Jun 25, 2009 at 2:33 AM, Thomson, Martin 
><<mailto:[email-masked]>[email-masked]> wrote:
>Inline,
>
> > Sent: Thursday, 25 June 2009 10:03 AM
> > To: Thomson, Martin; <mailto:[email-masked]>[email-masked]
> > 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.
>
>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).
>
> > >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.
>
>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 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.
>
>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
> > >
>
>------------------------------------------------------------------------------------------------
>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]
><mailto:[email-masked]>[email-masked]