[Geopriv] New Location Conveyance ID posted

From: James M. Polk ^lt;jmpolk@cisco.com>
Date: Mon Jul 26 2004 - 13:31:32 EDT

SIPPING and GEOPRIV WGs

Below is the link to the new Location Conveyance ID recently posted. Brian
and I have added a solution section to document (taking the ID from ~ 11
pages to 45 pages) with many examples (including numerous "well-formed" SIP
messages with and without S/MIME), including the INVITE, MESSAGE, and
UPDATE Method messages, a 200 OK message and the unfinished PUBLISH Method
section. REFER is also addressed with a multipart location conveyance example.

http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirements-01.txt

We've added text to address how this effort addressed the Geopriv
Requirements of RFC 3693, with the intent of this effort satisfying the
"using protocol" stipulations of the Geopriv WG for location conveyance
(regarding privacy and security considerations).

There is (like in the past) a list of known open issues to be addressed by
the authors (based on input from the WGs). The current issue list is:

    1) How do we handle proxy authenticated location?

    2) What do we do in an Offer/Answer model where the INV contains an
       Offer to the UAS asking which format they want to receive?

    3) What do we do with Alice wanting Bob's Location in the 200 OK (to
       her INVITE with location)?

    4) What about a new 4XX error for unknown or bad location given?

    5) There is the case in the Proxy Routing in which a UAC sent an
       INVITE to sos@ without a location message body. Does this
       necessitate the need for a 4XX level error informing the UAC to
       "retry with the location message body included this time"?

       Another spin on this is if the UAC doesn't know it's location and
       wants to ask a Proxy server to include the UAC's location if it
       is known to the Proxy...

    6) How or should we get into a Redirect message from a PS that
       contains a Location body for that UAC? Should we RECOMMEND a UAC
       that receives a 3XX Reply to an INVITE that contains a Location
       body with a presence line signifying the UAC, the UAC MUST
       include that Location body in the new INVITE?

       6a) What if the UAC already sent a Location body in the original
           message, should it replace the location body with what the PS
           included, or include both?

          6ai) If we state "both", which we agreed in the past is a good
               idea, I see no way in the PIDF-LO or in MIME to denote
               which message body came from Alice and which came from
               the PS...

    7) The authors failed to get this document reclassified into a
       specification effort (from a requirements ID effort)

       7a) will re-request to the ADs after IETF60 for this

    8) Req U-PS7 (Proxy Assertion of a Location body) is not addressable
       yet in SIP (as Identity is barely addressable).

       8a) Should this requirement remain as a goal?

    9) From section 9.2 (Emergency call with an updated location), if
       Alice does venture into another coverage area, how does her new
       UPDATE with new location get sent to a second (and now
       appropriate) ERC(2)?

       The pending INVITE needs to be cancelled or able to be
       sequentially forked (which not all Proxies will be able to do).
       Without that occurring, the new UPDATE will not cause a new
       INVITE to be originated from the Proxy towards ERC2... and what
       happens to the UPDATE message (which cannot be an original
       request into ERC2)?

Comments are encouraged to any/all of these, as well as new issues not
mentioned

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Mon, 26 Jul 2004 12:31:32 -0500

This archive was generated by hypermail 2.1.8 : Mon Jul 26 2004 - 14:05:14 EDT