Subject: [Sip] draft-ietf-sip-location-conveyance-03.txt Comments

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 29 Jun 2006 23:03:27 +0200

Hi Brian,
Hi James

I have a few questions concerning the latest SIP location conveyance 
document.

* Usage Cases

I think we need to consider the following scenarios:

(a) Location transport per-value (a1) and per-reference (a2)

(b) Location transport in the header (b1) and in the body (b2)

(a) and (b) has to be combined to produce a reasonable combination.

Let me go through the individual cases:

- If SIP UA Alice wants to convey location information to SIP UA Bob 
then it should put the PIDF-LO into the body (and apply S/MIME to it). 
(Case a1+b2)

- If a proxy wants to add location information to a SIP message then it 
creates the PIDF-LO and a reference to it. The reference is placed into 
the SIP header. (Case a2+b1)
Would the proxy use M2M/M2E security?

- If SIP UA Alice has to perform location-based routing (e.g., as used 
in emergency scenarios) then it has to place something into the SIP 
header since the proxy is not supposed to inspect the body (particularly 
since it can be encrypted). What is SIP UA Alice supposed todo? I think 
it is not realistic to assume that the SIP UA creates a reference and 
makes it available by running a webserver on the end host. It cannot add 
location information to the SIP header (as a base64 encoded PIDF-LO) 
since this functionality is not provided by the draft.

This would be case a1+b1.

- What happens if the SIP UA Alice only has a location reference and she 
wants to send it to SIP UA Bob (where intermediaries must not process 
the location information)? Is she able to place the reference into the 
body of the message? I don't think you cover this option in your draft.

This would be case a2+b2.

- What happens if you want to perform location-based routing (i.e., 
processing of the PIDF-LO by intermediaries) and conveyance to the other 
end point? Do you include the information only in the header and not in 
the body or in the header and the body?

* I think that the following text is already covered in the PIDF-LO 
profile draft:

"
    More than one location representation or format MAY be included in
    the same message body part, but all MUST point at the same position
    on the earth (altitude not withstanding), as this would confuse the
    recipient by pointing at more than one position within the same
    message body part.  There MAY be a case in which part or parts of
    one location format and part or parts of another format exist in the
    same message body part.  These complementary pieces of information
    MUST point at the same position on the earth, yet are incomplete
    within their own format. For example, there maybe be a latitude and
    longitude in coordinate format and a civic altitude value to
    complete a 3-dimensional position of a thing (i.e. which floor of a
    building the UA is on in a building at a particular lat/long
    coordinates pair).
"

* PIDF-LO in SIP Header

You write:
"
    The amount
    of information that is necessary to appropriately transmit location
    information in a format that is understandable is larger than a SIP
    header could realistically include.
"

What is the upper limit?

* Scenario Description

In the introduction you list three scenarios (actually four).

I assume that Scenario #1 refers to the scenario in Figure 2 of Section 
4 where the end point performs location-based routing. Correct?

Thinking about the service URN draft one could get the impression that a 
solution scenario according to Scenario #3B could also be designed to 
accomplish the goal of Scenario #1.

I might be good to combine the scenario description of Section 1 with 
the text and the figures in Section 4.

Ciao
Hannes

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 29 Jun 2006 16:32:25 -0500

At 11:03 PM 6/29/2006 +0200, Hannes Tschofenig wrote:
>Hi Brian,
>Hi James
>
>I have a few questions concerning the latest SIP location conveyance document.

I moved this discussion to the SIP list, as that's the home of this ID.

>- If SIP UA Alice wants to convey location information to SIP UA Bob then 
>it should put the PIDF-LO into the body (and apply S/MIME to it). (Case a1+b2)

this is covered

>the SIP header. (Case a2+b1)

this is covered

>Would the proxy use M2M/M2E security?

this is orthogonal

>- If SIP UA Alice has to perform location-based routing (e.g., as used in 
>emergency scenarios) then it has to place something into the SIP header 
>since the proxy is not supposed to inspect the body (particularly since it 
>can be encrypted).

not true

Nothing in SIP prevents a proxy from inspecting a body.  A proxy just 
cannot add or modify a body.

>What is SIP UA Alice supposed todo?

Alice can include location by-value or by-reference.

>I think it is not realistic to assume that the SIP UA creates a reference 
>and makes it available by running a webserver on the end host.

I tend to agree, therefore I believe Alice includes location by-value if 
she has it

>It

what is "it" in this context?

>cannot add location information to the SIP header (as a base64 encoded 
>PIDF-LO) since this functionality is not provided by the draft.

I think you're operating under the impression that proxies cannot read 
bodies, which they can.  Any B2BUA or SBC can modify bodies, or add bodies 
- but we cannot assume there will be one in the message path.

>wants to send it to SIP UA Bob (where intermediaries must not process the 
>location information)? Is she able to place the reference into the body of 
>the message? I don't think you cover this option in your draft.

SIP Headers can be placed in a message body already.  Do you want that 
specified here too?

>end point?

by-value covers this I believe

>Do you include the information only in the header and not in the body or 
>in the header and the body?

either a header or body

The proxies can read and route based on the body, and

Bob can dereference a header if that's all that's in the message.

>    building the UA is on in a building at a particular lat/long

This needs to be in the "Using Protocol's" document too IMO.  I do not 
believe this is inconsistent with the PIDF-LO profile doc.

>    header could realistically include.

I do not know, but I do not believe it is 27 CATypes as separate fields in 
a Location header.  I think Henning worked out a 500 byte <location-info> 
element, and while that's allowable I believe, I think it's hard to read.

>I assume that Scenario #1 refers to the scenario in Figure 2 of Section 4 
>where the end point performs location-based routing. Correct?

agreed

>accomplish the goal of Scenario #1.

yes, but I choose to call them out separately to have a reader understand 
the different scenarios

>I might be good to combine the scenario description of Section 1 with the 
>text and the figures in Section 4.

I was told explicitly to reduce my figures in section 4.  Therefore, I have 
a basic request/response transaction (figure 1), a request/response 
transaction involving an intermediary performing routing based on the 
location contents of the request (figure 2) and then articulate how 
Location can be conveyed in a specific SIP Request type (INVITE here).  I 
have been told by the WG chairs in SIP to not have more than this.  This 
doesn't prevent a user-cases ID from being generated giving these 
examples.  I think that would be appropriate once this ID reaches RFC status.

>Geopriv mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 30 Jun 2006 09:34:08 +0200

Hi James

thanks for your quick response and your clarifications.
Please find my response below:

James M. Polk wrote:
>> - If a proxy wants to add location information to a SIP message then 
>> it creates the PIDF-LO and a reference to it. The reference is placed 
>> into the SIP header. (Case a2+b1)
> 
> 
> this is covered
> 

I thought that this issue is important and would deserve a discussion in 
the document.
I could only find discussions about S/MIME usage for end-to-end security.

>> header since the proxy is not supposed to inspect the body 
>> (particularly since it can be encrypted).
> 
> 
> not true
> 
>> I think it is not realistic to assume that the SIP UA creates a 
>> reference and makes it available by running a webserver on the end host.
> 
> 

It=the SIP proxy

The SIP proxy cannot add location information to the SIP header (as a 
base64 encoded PIDF-LO) since this functionality is not provided by the 
draft.

> bodies, which they can.  Any B2BUA or SBC can modify bodies, or add 
> bodies - but we cannot assume there will be one in the message path.

The SIP proxy cannot read the body if it is encrypted.

>> - What happens if the SIP UA Alice only has a location reference and 
>> she wants to send it to SIP UA Bob (where intermediaries must not 
>> process the location information)? Is she able to place the reference 
>> into the body of the message? I don't think you cover this option in 
>> your draft.
> 
> 

Ok. That's fine.

>> processing of the PIDF-LO by intermediaries) and conveyance to the 
>> other end point?
> 
> 

I suspect that you want to put the location header into the message to 
let the proxy know where to find the PIDF-LO and that it actually has to 
look for one.

If you don't want intermediaries to process it then you want to apply 
S/MIME and if not available (=quite likely) then you wouldn't put the 
location header into the message. Right?

> 
>> Do you include the information only in the header and not in the body 
>> or in the header and the body?
> 
> 
> either a header or body
> 

I think the PIDF-LO profile document is more precise on these issues and 
  repeating it does not add value.

> I do not know, but I do not believe it is 27 CATypes as separate fields 
> in a Location header.  I think Henning worked out a 500 byte 
> <location-info> element, and while that's allowable I believe, I think 
> it's hard to read.

Why is it a problem if you assume that the SIP proxies will inspect the 
body? He has to read the same XML document.

>> I assume that Scenario #1 refers to the scenario in Figure 2 of 
>> Section 4 where the end point performs location-based routing. Correct?
> 
> 
> agreed
> 
> 
>> Thinking about the service URN draft one could get the impression that 
>> a solution scenario according to Scenario #3B could also be designed 
>> to accomplish the goal of Scenario #1.
> 
> 
> yes, but I choose to call them out separately to have a reader 
> understand the different scenarios

Ok. That's fine.

> I was told explicitly to reduce my figures in section 4.  Therefore, I 
> have a basic request/response transaction (figure 1), a request/response 
> Location can be conveyed in a specific SIP Request type (INVITE here).  
> I have been told by the WG chairs in SIP to not have more than this.  
> This doesn't prevent a user-cases ID from being generated giving these 

I am fine with the number of message flows but Section 1 talks about 
scenarios without figures and later you talk again about scenarios with 
figure and there is no link between them.

Ciao
Hannes