1 © 2001, Cisco Systems, Inc. All rights reserved. © 2004, Cisco Systems, Inc. All rights reserved. Location Conveyance in SIP draft-ietf-sipping-location-requirements-02 James M. Polk Brian Rosen 11 Nov 04

© 2001, Cisco Systems, Inc. All rights reserved. 2 2 © 2004, Cisco Systems, Inc. All rights reserved. 2 Location Conveyance Goal is to define SIP as an RFC3693 Using Protocol Incorporate the Geopriv LO into SIP by – adhering to all requirements of 3693 – add necessary requirements unique to SIP for location conveyance

© 2001, Cisco Systems, Inc. All rights reserved. 3 3 © 2004, Cisco Systems, Inc. All rights reserved. 3 Types of Location Conveyance in SIP User Agent to User Agent – i.e. person to person, UA to Location service User Agent to Proxy Server – i.e. message routing based on location of User Agent Client (the initiator of a message) – this has one use-case identified: 911/112-type emergency communications

© 2001, Cisco Systems, Inc. All rights reserved. 4 4 © 2004, Cisco Systems, Inc. All rights reserved. 4 What changed since version -01 Several things changed in this version: added requirements for 2 new 4XX error responses (Bad Location Information) and (Retry Location Body) added "Bad Location Information" as section 8.6 added "Retry Location Body " as section 9.3 added support for session mode to cover packet sizes larger than the single packet limit in the message body added requirement for a SIP entity to SUBSCRIBE to another for location information

© 2001, Cisco Systems, Inc. All rights reserved. 5 5 © 2004, Cisco Systems, Inc. All rights reserved. 5 added SUBSCRIBE and NOTIFY as section 8.5 added requirement to have user turn off any tracking created by subscription removed doubt about which method to use for updating location after a INVITE is sent (update) removed use of reINVITE to convey location cleaned up which method is to be used if there is no dialog existing (message) What changed since version -01 II

© 2001, Cisco Systems, Inc. All rights reserved. 6 6 © 2004, Cisco Systems, Inc. All rights reserved. 6 clarified that UAs include element of PIDF-LO when placing an emergency call (to inform ERC who supplied Location information) added to IANA Considerations section for the two new 4XX level error responses requested in the last meeting What changed since version -01 III

© 2001, Cisco Systems, Inc. All rights reserved. 7 7 © 2004, Cisco Systems, Inc. All rights reserved. 7 Existing Open Issues Should a Proxy somehow label its location information in the proposed 425 (Retry Location Body) message? – a PIDF-LO question? Still have not determined if/how a UAC can request the UAS return its location in a 1XX or 2XX response – maybe just use a SUB/NOT (if supported)? Still have not determined if a Redirect model should be accounted for (if the 3XX response includes LI, does that get included in the new/next Request by the UAC?)

© 2001, Cisco Systems, Inc. All rights reserved. 8 8 © 2004, Cisco Systems, Inc. All rights reserved. 8 This document needs to be renamed 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? Existing Open Issues II

© 2001, Cisco Systems, Inc. All rights reserved. 9 9 © 2004, Cisco Systems, Inc. All rights reserved. 9 New Open Issues (thanks Cullen) Suggestion for WG to make multipart message bodies mandatory If you can put an LO in a 200, what happens if the 200 is too big? how does a proxy tell the UAS what LO to put in the answer? Problems with thinking Proxies have to remember that the last request failed (for whatever reason), but to *not* fail the subsequent request – proxies shouldnt fail what it shouldnt fail this doesnt work if the initial try is with security, and the second is without due to the first failure Allow situation: A to send an LO to B, but it is only viewable by a proxy in between and *not* B

© 2001, Cisco Systems, Inc. All rights reserved. 10 © 2001, Cisco Systems, Inc. All rights reserved. 10 © 2004, Cisco Systems, Inc. All rights reserved. 10 Include a requirement for an intermediary to include a location indication about the UAC, but not from the UAC – just brought up, dont have this scoped completely (yet) smells like adding a body as one option... New Open Issues (thanks Keith)

© 2001, Cisco Systems, Inc. All rights reserved. 11 © 2001, Cisco Systems, Inc. All rights reserved. 11 © 2004, Cisco Systems, Inc. All rights reserved. 11 Whats next? Solve open issues through discussion and Chair/AD guidance Need to (start, then) finish sections on SUBSCRIBE/NOTIFY and PUBLISH If creating the Response Codes is acceptable, that makes this a SIP item, right? One idea is to break this ID into a Requirements ID (in SIPPING) and a Solutions ID (in SIP) – because the requirements are 98% done