draft-ietf-sip-location-conveyance-03.txt Comments

Hannes Tschofenig <[email protected]>
Newsgroups gmane.ietf.sip,gmane.ietf.geopriv
Message-ID <[email protected]>
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 protected] for questions on current sip
Use [email protected] for new developments on the application of sip
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.