Subject: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3

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

I focused on sections 1 to 3, since they have been subject to
substantial changes. I think the changes on the whole are an
improvement, but I still have some minor comments and nits.

Minor comments:
- "Location Information Server (LIS) - a logical server that stores 
      geolocation records of Targets, which correspond to LbyR URIs."
Several problems with this definition:
a) What are "geolocation records"? Elsewhere in the document we talk
about just "location" or "location information" - I doubt the need to
introduce yet another term "geolocation record", which does not seem to
be used elsewhere.
b) What exactly "correspond" to LbyR URIs. Targets certainly do not
"correspond" to LbyR URIs. Also I don't think geolocation records
"correspond" to LbyR URIs. Is it trying to say something like "these
records being identified by LbyR URIs"?
c) I don't think this definition of the term LIS is in line with usage
within GEOPRIV documents, e.g., lis-discovery or HELD. In HELD, a LIS
provides either a location by value or a reference. A URI provided as a
reference will result in a recipient contacting a server to provide the
location value, but that server is not necessarily a LIS, I believe. At
least I don't believe it acts as a LIS in this circumstance, even if the
same physical server can also be a LIS. I think where we use the term
LIS in location-conveyance, we should perhaps consider using something
like "dereferencing server" instead.

- "This document describes how Location can be "conveyed" from one SIP 
   entity unsolicited to another entity using SIP [RFC3261]."
I think it would be worth mentioning that it applies only to SIP
requests:
   "This document describes how Location can be "conveyed" in a SIP [RFC
3261] request from one SIP entity unsolicited to another SIP entity."

- Later in the same paragraph: "The phrase "location conveyance" 
   describes scenarios in which a SIP user agent client (UAC) is 
   informing a user agent server (UAS) or intermediate SIP server 
   without being previously asked where the UAC is."
This is more restrictive than the sentence in the preceding comment (in
that conveyance is constrained to start at the UAC, rather than at a
proxy). The sentence does not seem to add any value and can be dropped.

- "Location Conveyance is different from a UAC, Alice, seeking the 
   location the UAS, Bob.  Location conveyance, using SIP, never asks 
   for another entity's location be in a response.  Asking for someone 
   else's location is not discussed in this document."
This is redundant, since the sentence two comments back already says
"unsolicited". If we really need to say anything, we can much more
simply say:
   "Requesting an entity to convey its location via SIP is outside the
scope of this document."

- "This document describes the
   extension to SIP for how it complies with the Using Protocol 
   requirements, "
I think this would be better worded as:
  "This document specifies an extension to SIP to allow it to be a Using
Protocol in compliance with the requirements of [RFC 3693]."

- "Common terms are in Section 1. Section 3 provides an overview of SIP
   location conveyance.  Section 4 details the modifications necessary 
   to accomplish location conveyance.  Section 5 gives decode examples 
   of geolocation within SIP requests, both LbyV and LbyR.  Section 6 
   articulates the SIP element type behaviors for location conveyance. 
   Section 7 discusses Geopriv privacy considerations.  Section 8 
   discusses security considerations.  Section 9 IANA registers the 
   modifications made to SIP by this document from section 4."
This duplicates the table of contents (well, it hardly adds anything) -
delete.

- "Section 4 gets into guidance and limitations of this behavior."
Section 4 seems to specify normative behaviour, so I would hardly call
it guidance. I would delete this sentence. If we really need to retain
such a sentence, we should use more precise wording than "gets into".

- "It is possible, and it fact, planned in certain 
   circumstances to have SIP requests routed based on the location of 
   the target. This means SIP servers can be location recipients. If 
   this is not desired by a location inserter - the act of including 
   location into this request, then a separate indication is given in 
   the Geolocation header it this usage is allowed."
I am not sure what the last sentence means - a "location inserter" is
not an "act of including location into this request". I think what might
be undesirable is not the fact that SIP servers can be location
recipients, but the fact that they might use location information for
routing. I think the last sentence should be rewritten something like
this.
  "The location inserter is able to include a separate indication in the
Geolocation header field to denote whether routing on the basis of the
target's location is permitted."

If we do this, then the last sentence seems to follow on nicely from the
first sentence, and the second sentence seems to get in the way, so
delete the second sentence. If we really need to retain the second
sentence, at least change "SIP servers" to "SIP proxies" (since a UAS is
also a SIP server).

- "There is no mechanism by which the veracity of these parameters can 
   be verified."
It is not clear what "these parameters" refers to, because the term
"parameter" has not been used in the preceding text. It would be best to
enumerate the particular fields that this refers to.

- "They are hints to downstream entities on how the 
   location information in the message was originated, intended and 
   used."
The words "was ... used" do not make sense - the information has not yet
been used - merely conveyed. I am not sure what is intended here.

- " LbyR refers to a UA 
   including a location URI in a SIP request header field which can be 
   dereferenced by a Location Recipient to receive Alice's Location 
   Object, in the form of a PIDF-LO."
The header field is not dereferenced, it is the location URI that is
dereferenced. I would suggest (also making other parts of the sentence
more generic):
   "LbyR refers to a Location Server
   including in the header of a SIP request a location URI that can be 
   dereferenced by a Location Recipient to receive a Location 
   Object, in the form of a PIDF-LO, representing the Target's
location."

Nits:

- In the abstract, "where SIP servers 
   make routing decisions based on the location of the user agent 
   clients"
Change "clients" to "client", since a SIP request can have only one UAC.

- "directly or indirectly from transmitting SIP 
   entity"
Change to
  "directly or indirectly from a transmitting SIP 
   entity"

- "In 
   other works"
Change to
  "In 
   other words"

- "a new SIP header"
Change to:
  "a new SIP header field"
(and likewise for "a new header" later. Also other places in the
document where "header" is used rather than "header field", even though
we are referring to only a part of the SIP header.)

- "that points to the where the
   location is"
Change to:
  "that points to where the
   location is"

- "either in the SIP request itself "
I think it would be more accurate to say:
  "either in the body of the SIP request"

- "or on an external server (LbyR)"
It is not clear what "external" is relative to. Change to:
  "or on a server (LbyR)"

- "Transport Layer Security is expected when a request contains 
   a target's location.  Some implementations will choose to have 
   S/MIME to encrypt message bodies from source to destination."
Shouldn't we have a paragraph break before this?

John

---

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

>improvement, but I still have some minor comments and nits.

John -- thanks for the review.

>       geolocation records of Targets, which correspond to LbyR URIs."

I agree this term definition is fuzzy, and planned on doing more with 
it when I rev the doc before the -01 deadline.

>records being identified by LbyR URIs"?

I'll change the wording.

>location value, but that server is not necessarily a LIS, I believe.

I think it is, but will verify.

>At
>least I don't believe it acts as a LIS in this circumstance,

I think this is the exact circumstance in which this acts this way, 
but could be wrong, and will verify with Mary Barnes (author of 
HELD). I didn't look to the HELD docs - that have to describe this 
same thing - for a way of stating/defining all this, and I should have.

>even if the

that works for me, but within geopriv-speak, they use the term LIS 
for this (or I can't tell when this isn't applied in this way). I'll verify.

>3261] request from one SIP entity unsolicited to another SIP entity."

this is a good suggestion - and I'll easily do this.

>proxy). The sentence does not seem to add any value and can be dropped.

it is basically repeating, so I'll drop it.

>    "Requesting an entity to convey its location via SIP is outside the

I had a sentence saying this, but took it out. I guess I shouldn't have.

>Protocol in compliance with the requirements of [RFC 3693]."

good suggestion

>This duplicates the table of contents (well, it hardly adds anything) -

many many docs have a paragraph like this, and have a TOC, so I kept 
it here because of that practice.

I can easily drop it - because you're right, if someone had read the 
TOC, nothing here is new.

>such a sentence, we should use more precise wording than "gets into".

fair

>not an "act of including location into this request".

the inserter term does come out of the blue, so I'll clarify this, as 
it is an important point.

>I think what might
>routing.

you do not like the idea of servers routing a request based on the 
contained location?

can you clarify, please

if you do feel this way, then I disagree with you, as this is central 
to emergency services and other source based routing (i.e., directing 
the message based on where the UAC is, instead of what the 
destination address is).

>I think the last sentence should be rewritten something like
>this.

regardless of hte above, this sentence is not wrong, and does make a 
good point, so I'll look at including it.

>sentence, at least change "SIP servers" to "SIP proxies" (since a UAS is

wrt proxies vs. servers -- I tried to account for there being B2BUAs 
at the same place as proxies would be, to attempt to get them to 
behave in nearly identical ways based on this spec.

>enumerate the particular fields that this refers to.

fair comment

>been used - merely conveyed. I am not sure what is intended here.

I'll make this clearer

>dereferenced.

this is an artifact of the acronym "LbyR" being considered an 
archiecture by the Geopriv WG for about a year (some still feel it 
is), where I believe LbyR is just a location URI.  This is an attempt 
to have the Geopriv folks understand that the Location URI, which is 
the Geolocation header value is used to dereference the Target's location.

>I would suggest (also making other parts of the sentence
>more generic):

interesting suggestion... connecting the UAC as the Target that's 
really acting as a Location Server. While true, this might confuse 
SIP specific folks.  Then again, maybe not - given that what you 
state above is accurate.

>Change "clients" to "client", since a SIP request can have only one UAC.

fair

>   "directly or indirectly from a transmitting SIP

good catch

>    other words"

thanks!

>we are referring to only a part of the SIP header.)

fair, in fact, I did this sweep before, but obviously didn't catch 
all of the replacements.

>   "that points to where the

thanks

>   "either in the body of the SIP request"

fair

>It is not clear what "external" is relative to. Change to:

it is meant to emphasize that LbyR is a location URI pointing towards 
the location record that does not reside on the location target 
itself (even if the target is an LS), it is on another entity. 
perhaps I do not need to make this point.

>Shouldn't we have a paragraph break before this?

we could... and I will  ;-)

Thanks

James

>John
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore

---

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

James,

Thanks for attending to my comments. Just some remarks on the ones you
queried.

> it is an important point.
[JRE] Sorry, perhaps my comment was not clear, but the way the sentence
is constructed suggests that "a location server" is "the act of
including...". I don't have a problem with the term "inserter", but with
the words that follow and the general sentence construction.

> you do not like the idea of servers routing a request based on the 
[JRE] My comment is misunderstood. I am talking about what the inserter
does not desire. I believe the text is trying to cover the case where
the location inserter does not desire that location be used for routing.

> can you clarify, please
[JRE] I hope my explanations above are clear.

> behave in nearly identical ways based on this spec.
[JRE] SIP RFCs have traditionally not specified B2BUA behaviour (whether
or not that is good, I don't wish to debate here). Also, if you do want
to include B2BUAs, you would need to make it more clear, e.g., define
server as meaning proxy or B2BUA (maybe redirect too, I guess). On the
other hand, a UAS, although it is a server, cannot route, so maybe my
point is moot.

> the Geolocation header value is used to dereference the 
[JRE] I agree, but my original complaint still holds, i.e., it is the
URI that is dereferenced, not the header field. The header field
contains more than just the URI.

> SIP specific folks.  Then again, maybe not - given that what you 
[JRE] The point I was trying to make is that we also allow a proxy to be
a Location Server, i.e., to insert the location. Location Server is
therefore more accurate than UA.

> perhaps I do not need to make this point.
[JRE] It is not clear to me, so I would indeed prefer to remove
"external".

John

---

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

>the words that follow and the general sentence construction.

that makes more sense now, thanks

>the location inserter does not desire that location be used for routing.

thanks again

>[JRE] I hope my explanations above are clear.

yep

>other hand, a UAS, although it is a server, cannot route, so maybe my

yeah - I know this is a tough one, and someone else said making this 
small change to "server" does give one more leverage to mean more 
than proxy if the discussion goes that way (anywhere). theoretically, 
we cannot really do anything about b2buas, but this is a - perhaps 
vein - attempt to include them in the discussion to keep them 
behaving, while not getting into the argument of calling them out and 
having to explain that (which would be an endless argument from 
someone who wants to dig in their heels).

>URI that is dereferenced, not the header field.

I agree, and will make it clear by saying it's the header value that 
is used to make the dereference

>The header field

you're right, and I was clarifying that the target - if that's the 
UAC that created the PIDF-LO and inserted it in the SIP request - is 
also a Location Server.  I'll make this clear on all accounts.

>[JRE] It is not clear to me, so I would indeed prefer to remove

ok, I will.

Thanks again!

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 2 Jul 2009 18:28:29 -0500

Hi James,

John is correct about use of LIS and LS.  A LIS is a specialized term that is used only in the location configuration protocol (LCP) context only.

When a location recipient (LR) retrieves location information (LI) from a location URI the entity that it contacts is (or acts as) a location server (LS).

If you look at the latest version of Richard's architecture draft or the HELD deference draft, the basic idea is that LS is a role assumed by an entity that provides LI to an LR.

I have a few minor things below.

> for this (or I can't tell when this isn't applied in this way). I'll
... 
> the Geolocation header value is used to dereference the Target's

"Location by reference" refers to the process of conveyance where a location URI is used instead of a location object.  You can't say "LbyR == location URI".

The fact that this process is not especially complex, or even special from your perspective, doesn't mean that we don't need unambiguous labels.  There are very good reasons for coining the nomenclature.  Misusing it doesn't help; it only foments confusion.

> SIP specific folks.  Then again, maybe not - given that what you

I like John's wording, but tend to agree - the fact that the UAC becomes an location server might be lost on some readers.

Then again, the Target-UAC connection still isn't made.  Are we assuming this still?
------------------------------------------------------------------------------------------------
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: Thu, 02 Jul 2009 22:59:38 -0500

At 06:28 PM 7/2/2009, Thomson, Martin wrote:
>Hi James,
>
>John is correct about use of LIS and LS.  A LIS is a specialized 
>term that is used only in the location configuration protocol (LCP) 
>context only.

I have to admit - I didn't ever get this limitation about a LIS (that 
it's only for LCPs).

FWIW -- I thoroughly disagree with this definition, but may be in the minority.

Upon determining that I'm in the minority, I will remove "LIS" from 
conveyance and replace it with LS and Location Server.

>When a location recipient (LR) retrieves location information (LI) 
>from a location URI the entity that it contacts is (or acts as) a 
>location server (LS).

this is really a geopriv discussion - because to me, only an LCP 
delivers LI, and SIP is no where near any LCP.  SIP is concerned with 
LOs (either by-value in a SIP request, or attained via a dereference 
transaction). LOs are PIDF-LOs that can be message bodies in SIP requests.

>If you look at the latest version of Richard's architecture draft

I've been raising a point about this since he began that ID because I 
have never agreed to his interpretation of the Geopriv architecture.

>or the HELD deference draft, the basic idea is that LS is a role 
>assumed by an entity that provides LI to an LR.

LS is also a role that a SIP proxy takes on when it uses the location 
in the SIP request (by-value or by-reference) to make routing 
decisions for that request.  Remember, he only changed his arch where 
LSs were every location aware intermediary along the message path 
towards the ultimate destination in the -05 version. This concept 
didn't exist in the -04 version of Loc-sec.

>I have a few minor things below.

ok

>"Location by reference" refers to the process of conveyance where a 
>location URI is used instead of a location object.

ok

>You can't say "LbyR == location URI".

grrr!

>The fact that this process is not especially complex, or even 
>special from your perspective, doesn't mean that we don't need 
>unambiguous labels.  There are very good reasons for coining the 
>nomenclature.  Misusing it doesn't help; it only foments confusion.
>
>I like John's wording, but tend to agree - the fact that the UAC 
>becomes an location server might be lost on some readers.
>
>Then again, the Target-UAC connection still isn't made.

that has been going on in the background, offlist

>Are we assuming this still?

we can't.

signaling is easily decomposed from a presence document.

the target is identified as the "entity=" attribute within the 
<presence> element. Check section 5 of conveyance (i.e., my LbyV 
example) to see.

Therefore, the target identifier is found there, even if it is an 
unlinkable pseudonym to intermediary entities. If it is not 
understood by the location recipient, then it is ignored because it 
cannot attach identity to it.

I will take your advice (based on reading RFC 4479) and delete - and 
not mention - the <deviceID> as this is providing too much 
information that might reveal a link to the target's identity.

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 2 Jul 2009 23:22:28 -0500

Inline..

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Friday, 3 July 2009 2:00 PM
> To: Thomson, Martin; Elwell, John; [email-masked]
> Subject: RE: [sipcore] Review of draft-ietf-sipcore-location-
> conveyance-00 sections 1 to 3
> 

I have no problem with someone labelling the piece of hardware or software as a LIS.  We do that.  But the important point is that the role assumed is that of a Location Server.

A LIS isn't the only sort of entity that could provide the location URI.  This could just as easily be a presence service, or a static web site (for an http[s]: URI).  I am aware of services that already exist; some of them might even be able to provide PIDF-LO.

But you're right, let's nut this out in GEOPRIV.  Can you start the ball rolling?  Or would you prefer that I did?

...
> that has been going on in the background, offlist

Please let me know what the outcome is.  I'm sure we're all interested.

> >Are we assuming this still?

You'll have to justify that.  I don't only think it's possible, I think that it's necessary.
 
> signaling is easily decomposed from a presence document.

Sure, but when you remove the presence document it loses any meaning it might have gained from being attached to the signalling.

> <presence> element. Check section 5 of conveyance (i.e., my LbyV

The Target is "identified" by the entity attribute, but there's no guarantee that the recipient can make use of that identifier.  An unlinked pseudonym wouldn't offer any clues. 

> cannot attach identity to it.

So you are saying that if the presence document contains an identifier that cannot be linked to the UAC by a recipient, then that document possibly refers to another entity.  A proxy performing location-based routing would ignore the request, or regard location information as absent.

I offer a different possibility: that the location information pertains to the entity that makes the request, regardless of the identifier used within the document.

> information that might reveal a link to the target's identity.

Thanks.

--Martin

---

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

inline

At 11:22 PM 7/2/2009, Thomson, Martin wrote:
>I have no problem with someone labelling the piece of hardware or 
>software as a LIS.  We do that.  But the important point is that the 
>role assumed is that of a Location Server.
>
>A LIS isn't the only sort of entity that could provide the location 
>URI.  This could just as easily be a presence service, or a static 
>web site (for an http[s]: URI).  I am aware of services that already 
>exist; some of them might even be able to provide PIDF-LO.
>
>But you're right, let's nut this out in GEOPRIV.  Can you start the 
>ball rolling?  Or would you prefer that I did?

I don't care

>Please let me know what the outcome is.  I'm sure we're all interested.

actually - I said this below already, and verified this with Mr. 
Peterson this week.

>Sure, but when you remove the presence document it loses any meaning 
>it might have gained from being attached to the signalling.

exactly, and what's the problem with this?  a presence document is 
intended to be useful on its own, without signaling.

>The Target is "identified" by the entity attribute, but there's no 
>guarantee that the recipient can make use of that identifier.

exactly

>An unlinked pseudonym wouldn't offer any clues.

but at this point, this is the advantage. There is no identity 
information revealed to who doesn't know the pseudonym (which is the 
point, right?)

If Alice doesn't use an unlinknable pseudonym, and uses something 
that is readable to her identity (like an AOR or contact address), 
the this presence document is linkable to her identity with or 
without signaling information.

>So you are saying that if the presence document contains an 
>identifier that cannot be linked to the UAC by a recipient, then 
>that document possibly refers to another entity.

not exactly.

I'm saying regardless of who signaled the document (for example, 
whether from Bob to Alice, or Alice to Carol), the entity= attribute 
identifies to who hte target is for this document without the 
signaling. If this is Bob's location, he is the target. If it can be 
linked to him, then both Alice and Carol know this is Bob's target 
location (no matter who sent it to Alice or Carol).  If this is 
unlinkable, even if Bob sent it to Alice *and* Carol, neither know 
this is Bob's target location. They cannot assume this is Bob's 
location, because they can't verify the identity within the document 
(which is necessary).

Furthering the Alice, Bob and Carol example, let's say Bob told Alice 
his location, and Alice passed this on to Carol, along with Alice's 
location. This is possible because the entity= attribute in both 
PIDF-LO documents that Carol received identify which location goes to 
which entity (Alice and Bob respectfully). This assumes that Bob set 
his retransmission-allowed to "yes" or true, and the retention-expiry 
hasn't elapsed.

>A proxy performing location-based routing would ignore the request, 
>or regard location information as absent.

yes

this would necessitate a 424 (bad location) response, with a error 
code set to 100 (cannot process location).

I would normally want to add a new error code specifically in the 1XX 
range indicating the problem specifically is (to the effect of) 
"received *a* location, but couldn't link this to your location to 
use for location based routing -- please provide your linkable 
identity and try again". However, a few of you want me to remove the 
error section entirely, so adding a new one doesn't make much sense, 
right? (***even though it would address THIS EXACT PROBLEM***)...

<mumble>

>I offer a different possibility: that the location information 
>pertains to the entity that makes the request, regardless of the 
>identifier used within the document.

that links the identity to the SIP request, even if the use doesn't 
want this link. That doesn't seem right.

> > information that might reveal a link to the target's identity.

no problem.

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 3 Jul 2009 01:14:07 -0500

I can sympathize with your desire to keep everything within the PIDF, but it's just not practical.

If this were a file transfer protocol, then I can see the sense in being able to ship arbitrary PIDF documents around.  However, we're talking about attaching semantics to these documents in the context of signalling.  The Geolocation header makes a binding between the request and the document.  That binding had better have some well-understood meaning or this all fails.

If you want to pass around unrelated information, you're free to do so without a Geolocation header.

There are two use cases that make what you propose very difficult from a practical standpoint.  One is a very real problem; the other can be argued to be less so, but continues to plague us, so it's probably still important.

1) If we use your interpretation, then location URIs need to be dereferenced before anyone can even be sure that they are relevant.

1b) Furthermore, your LS - especially if it is a LIS - might not use the identity that you want.  It probably can't.  It is unlikely that a LIS is able to assert that sips:[email-masked] was present at the given location and time.  It's going to say that the entity that requested location information at that time was at that location and give them a name...an unlinked pseudonym.

2) The other is digital signing and integrity.  The binding between location and identity is often made in a context that is unaware of SIP identities.  Therefore, a signed PIDF document might not include an identity that is meaningful in the signalling context.

There's no reason that you can't assign meaning to the Geolocation header that says: whomever inserted this header asserts that the UAC is at the indicated location.  That doesn't necessarily imply that the entity identified in the document is the same as the UAC, or vice versa, all it does is provide a binding between identity in one context (the UAC) and another (the Target of the PIDF).

(In your example, the semantic web folks would assert that a URI tells you nothing, only the context where it appears gives you the information necessary to put it into context.  Maybe Alice can tell Carol that the location she just received was Bob's location; or it can identify Bob directly.)

--Martin

> Sent: Friday, 3 July 2009 3:42 PM

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 03 Jul 2009 07:22:02 +0100

> is used to make the dereference
[JRE] No, it is not the entire header field value (including its
parameters) - it is only the URI.

John

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 04 Jul 2009 15:22:52 -0500

>parameters) - it is only the URI.

Sorry, that's what I meant to say, but didn't. It is the URI.

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 04 Jul 2009 16:18:29 -0500

>PIDF, but it's just not practical.

That's the way presence it built, and I'm not going to try and change 
that model - not because of a single header value.

>If this were a file transfer protocol, then I can see the sense in 
>being able to ship arbitrary PIDF documents around.

I'm missing how shipping around message bodies isn't just like 
shipping files around...?

Whether it be in an INVITE or a NOTIFY based on a subscription that 
was accepted. A PIDF is something that signaling cannot remain a part 
of (i.e., these are decomposed).

>However, we're talking about attaching semantics to these documents 
>in the context of signalling.

no, we really aren't. The information in the signaling doesn't have 
to be in the message body, and visa versa. For example, if Alice has 
Carol's PIDF-LO, and understands that Alice is allowed to retransmit 
that information and the retention timer hasn't expired, there is 
nothing in the RFC 4119 (or any update) that declares Alice cannot 
tell Bob where Carol is. How Bob determines who is identified within 
a or each document is by the "entity=" attribute within that document.

>The Geolocation header makes a binding between the request and the document.

no, the Geolocation header determines *where* the LO is (local in the 
SIP request, or remote via a dereferencable URI).  The Geolocation 
header also says which SIP entity inserted each location value and 
whether or not that value can be used for routing. It doesn't 
bind  an entity, for 1 reason, because is just isn't that easy to 
accomplish the equivalent of an unlinkable pseudonym - which is a 
requirement for PIDF-LOs based on the rules within RFC 3693. 
Anonymity is just hard in SIP, and not practiced very much (outside 
of gov agencies  ;-)

>That binding had better have some well-understood meaning or this all fails.

It's the binding that's the problem for something that is meant to be 
decomposed.

>so without a Geolocation header.

I do not agree with this on several counts.  a presence document MUST 
NOT be forced to be linked to signaling, is the most important one.

>There are two use cases that make what you propose very difficult 
>from a practical standpoint.  One is a very real problem; the other 
>can be argued to be less so, but continues to plague us, so it's 
>probably still important.
>
>1) If we use your interpretation, then location URIs need to be 
>dereferenced before anyone can even be sure that they are relevant.

Firstly, they shouldn't be if the "routing-allowed" is set to no, 
therefore these entities shouldn't be looking at location at all.

Secondly, if a presence document's entity isn't understood, this is a 
security measure, and maybe the entity owner doesn't want you looking 
at it in the first place (and figuring out how it's about).

>1b) Furthermore, your LS - especially if it is a LIS - might not use 
>the identity that you want.

you define a LIS as a sender of LI (location Information), which has, 
by definition, no identity information -- so there's no "might" at 
all about identity from a LIS. A PIDF-LO has identity information, 
which is why we've gone to great lengths to make the information in 
it secure and private.

>It probably can't.  It is unlikely that a LIS is able to assert that 
>sips:[email-masked] was present at the given location and time.

wow (said sarcastically) -- now you are seeing why I don't believe in OBO...

seriously, a LIS, which you define as a LI provider via an LCP 
(location configuration protocol) such as DHCP or LLDP-MED cannot 
provide identity information, so no, it is the LI recipient - the UA 
- that attaches the identity information to the LI to form a LO 
(Location Object). A PIDF-LO is the one example that's standardized 
now for this. It contains an entity= attribute that the UA places 
it's identity information that is the *binder* of identity to the 
accompanying location information.

I agree that putting unlinked pseudonyms in this attribute can cause 
problems, especially when a SIP request that contains a PIDF-LO wants 
to have that message routed based on the contained location. I am 
going to add text saying this scenario is to be avoided in the next 
rev (-01) of the doc. It isn't there now, and that's a mistake.

>It's going to say that the entity that requested location 
>information at that time was at that location and give them a 
>name...an unlinked pseudonym.

LI doesn't provide identity because LCPs do not provide 
identity.  It's the identity of the UA that attaches identity (even 
unlinkable) to the LI when it forms an LO.

>2) The other is digital signing and integrity.  The binding between 
>location and identity is often made in a context that is unaware of 
>SIP identities.  Therefore, a signed PIDF document might not include 
>an identity that is meaningful in the signalling context.

But what's signed? It's the PIDF-LO *after* the entity= attribute is 
populated. It's the UA that chooses to bind it's identity (i.e., the 
currently registered user to that UA) to the presence document that 
happens to carry a location object.  Remember, RFC 4119 created the 
LO in the existing PIDF, and the entity= attribute was already 
defined in every PIDF (and it's not optional BTW).

>There's no reason that you can't assign meaning to the Geolocation 
>header that says: whomever inserted this header asserts that the UAC 
>is at the indicated location.

The text has always said location can only be conveyed in a PIDF-LO 
(which is part of PIDF -- i.e., presence). In resolving the idea that 
servers can insert location just as UACs can, the text then included 
the inserter= indication is included by the entity that inserted 
*this* locationValue (i.e., location URI by-value or by-reference).

The target identity has always had to be part of the presence 
document. The Location Generator (that's also a Location Server) 
creates the PIDF-LO. In that, is this entity= attribute that can be a 
linkable or unlinkable identity.

>That doesn't necessarily imply that the entity identified in the 
>document is the same as the UAC, or vice versa, all it does is 
>provide a binding between identity in one context (the UAC) and 
>another (the Target of the PIDF).

this means you want to through out the whole idea of unlinkable 
pseudonyms and their beneficial use, because that's what you are 
doing. In order for an unlinkable pseudonyms to still be useful in 
your usage - the SIP signaling will also have to be anonymous.  Have 
you looked at how hard that is? Have you looked at how many header 
values contain linkage to the owner and/or owner's domain? Look at 
RFC 3323 and ask how many have implemented it...

>(In your example, the semantic web folks would assert that a URI 
>tells you nothing, only the context where it appears gives you the 
>information necessary to put it into context.

>Maybe Alice can tell Carol that the location she just received was 
>Bob's location; or it can identify Bob directly.)

err, that's what I've been saying. The Alice to Carol SIP request 
that contains the PIDF that is associated with Bob will have to have 
an entity= attribute that says "this is Bob's document", likely by 
his AOR or Contact address. If Carol doesn't understand that entity= 
indicator, then the document is useless, just as an unlinkable 
pseudonym would be...

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 5 Jul 2009 19:14:19 -0500

James,

If the Geolocation header isn't linking PIDF documents into signalling, I'm at a loss to explain why it is there at all.

> wow (said sarcastically) -- now you are seeing why I don't believe in

No one but you has brought up that term.  It's not even relevant to the discussion.

--Martin

> Sent: Sunday, 5 July 2009 7:18 AM
> To: Thomson, Martin; [email-masked]
> Subject: Re: draft-ietf-sipcore-location-conveyance-00 : identity
> binding (was: something else)
>