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

From: "James M. Polk" <[email-masked]>
Date: Sat, 08 Jul 2006 21:37:25 -0500

At 09:34 AM 6/30/2006 +0200, Hannes Tschofenig wrote:
>Hi James
>
>thanks for your quick response and your clarifications.

I'm slower this time, sorry

>Please find my response below:
>
>
>James M. Polk wrote:
>>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.
>>
>>>* 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)
>>
>>this is covered
>>
>>>- 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
>>
>>>Would the proxy use M2M/M2E security?
>>
>>this is orthogonal
>
>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.

so far, a UAC shouldn't use S/MIME on a PIDF-LO message body if it knows a 
proxy will need to read that message body to route the message.  911/112 
calling is a good example of this, that can be coded in a phone to *not* 
use S/MIME (or any message body encryption to hide a PIDF-LO, knowing that 
info will be needed in transit).

Now, there has been a suggestion that every time a UAC sends location, it 
uses S/MIME (meaning location is always sent by-value from an endpoint). 
That only when the UAC receives an error to that request will it consider 
sending a subsequent request without S/MIME.  This will cause an extra 
round-trip to have the UAC send the request without S/MIME for the Proxy to 
be able to read the necessary location information to route the request to 
the appropriate destination.

What do you think of this language in the doc?

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

This is not true.  see this table that's been in the doc for some time:

    The following table extends the values in Table 2&3 of RFC3261
    [RFC3261].

       Header field             where proxy INV ACK CAN BYE REG OPT PRA
       ----------------------------------------------------------------
       Location                 Rr    ar     o   -   -   o   o   o   -

       Header field             where proxy SUB NOT UPD MSG REF INF PUB
       ----------------------------------------------------------------
       Location                 Rr    ar     -   -   o   o   o   o   -

adding a header value to a SIP message is standard procedure for SIP 
proxies. The above (unlabelled) table grants this ability explicitly to 
Location header usage.

>>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.
>
>The SIP proxy cannot read the body if it is encrypted.

fair

If we are to have an error response sent from a proxy that wants to read 
the PIDF-LO message body (it first has to assume there is one in the 
message), we can use the existing 424 (Bad Location Information) response 
message, and add a RFC 3326 Reason header with a 493 (Undecipherable) 
indication (the 493 is defined in RFC 3261). This could explicitly state to 
the UAC that a proxy cannot read the assumed PIDF-LO by-value message body, 
and to send a new request without encrypting that message body.

Is this desired, and do we want to have this text in this document, or 
ECRIT's phoneBCP (and maybe the Framework)?

>>>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.
>>
>>SIP Headers can be placed in a message body already.  Do you want that 
>>specified here too?
>
>Ok. That's fine.
>
>>
>>>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?
>>
>>by-value covers this I believe
>
>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.

most likely

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

right now, this spec states if location is conveyed in a message, that 
message MUST have a Location header (with a cid to the message body part, 
or a URI for the by-reference).

>>>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.
>>
>>
>>>* 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).
>>>"
>>
>>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.
>
>I think the PIDF-LO profile document is more precise on these issues 
>and  repeating it does not add value.

but this doc doesn't reference the PIDF-LO profile doc, so SIP folks will 
not necessarily find it anywhere else.

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

for one, it makes reading the SIP message harder to parse with a massive 
header in the middle of it (that currently only can be a message body).

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

ok. I need to link the two somehow.

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

_______________________________________________
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