1. Additional Data related to an Emergency Call draft-ietf-ecrit-additional-data-00.txt Hannes Tschofenig Brian Rosen

2. Fundamental Idea Devices and services providers have data useful to PSAPs Examples of data include identification & contact data of SP, subscriber data, “class of service” provided by SP to subscriber Draft seeks to standardize the form of this data, and how it’s transported; – Re-uses the work done in the NENA additional data working group!

3. Transport HTTPS GET of an XML structure defined by this document URI to the XML carried in a SIP Call-Info header Device or any/all SPs in the path could add such a header Questions: – Security protection: signing data? – Do we need to bind the data to the SIP session?

4. Data itself Draft lists several kinds of data and the fields for each as if it was a completely new XML schema List discussion suggests using mime/multipart with a mime description of each “kind” As an example, SP and subscriber “contact” data is in vcard form, so use mime/vcard New mime types would be required for some of the data where there is no existing mime type

5. Problem: Multiple MIME Type Instances How do we deal with, e.g. multiple vcards? SP has a 24/7 contact which is a vcard Subscriber name and address is a vcard Emergency contacts are vcards What is the mechanism used to identify which of these is which?

6. What does the HTTP GET return? What does the outer envelope look like, within which the mime/multipart exists Related to the first problem – which vcard is which