Subject: [Ecrit] Additional Data -07

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 20 Mar 2013 11:43:23 +0800

Hi Authors,

It is quite possible that I am misunderstanding things here and how the new Provided-By schema defined in section 14.3.1 is intended to be used, so let me present my use case.

The Location interworking Function (LIF) in NENA i3 essentially needs to be able to serve up existing ALI records but broken up into locations and additional data. The additional data that needs to be provided maps into several of the additional data XML containers defined in this document.

What I need to be able to do is to return:
1) A single structure with multiple URIs each URI to a different container type.
2) A single XML container with the actual XML structures I want.

What is provided doesn't seem to let me do that easily, and certainly isn't obvious.

I would like to propose the following schema as a replacement for what is currently in the document.

<?xml version="1.0"?>
<xs:schema
  targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:ad="urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData"
  xmlns:xml="http://www.w3.org/XML/1998/namespace"
  xmlns:pi="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"
  xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"
  xmlns:dev="urn:ietf:params:xml:ns:emergencyCall.DevInfo"
  xmlns:sub="urn:ietf:params:xml:ns:emergencyCall.SubInfo"
  xmlns:com="urn:ietf:params:xml:ns:emergencyCall.Comment"
  elementFormDefault="qualified" attributeFormDefault="unqualified">
	
  <!-- Additional Data By Reference -->
	
  <xs:element name="emergencyCallDataReference">
    <xs:complexType>
      <xs:sequence>
	  <xs:element name="emergencyProviderInfo" type="xs:anyURI" minOccurs="0" maxOccurs="1"/>
	  <xs:element name="emergencyServiceInfo" type="xs:anyURI" minOccurs="0" maxOccurs="1"/>
	  <xs:element name="emergencyDeviceInfo" type="xs:anyURI" minOccurs="0" maxOccurs="1"/>
	  <xs:element name="emergencySubscriberInfo" type="xs:anyURI" minOccurs="0" maxOccurs="1"/>
	  <xs:element name="emergencyComment" type="xs:anyURI" minOccurs="0" maxOccurs="1"/>
	  <xs:element name="anyOtherRefs" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
    </xs:ComplexType>
  </xs:element>
	
  <!-- Additional Data By Value -->
				
  <xs:element name="emergencyCallDataValue">
    <xs:complexType>
      <xs:sequence>
	  <xs:element name="emergencyProviderInfo" type="pi:emergencyCall.ProviderInfo"          
                    minOccurs="0" maxOccurs="1"/>
	  <xs:element name="emergencyServiceInfo" type="svc:emergencyCall.SvcInfo" 
                    minOccurs="0" maxOccurs="1"/>
	  <xs:element name="emergencyDeviceInfo" type="dev:emergencyCall.DeviceInfo" 
                    minOccurs="0" maxOccurs="1"/>
	  <xs:element name="emergencySubscriberInfo" type="sub:emergencyCall.SubInfo" 
                    minOccurs="0" maxOccurs="1"/>
	  <xs:element name="emergencyComment" type="com:emergencyCall.Comment" 
                    minOccurs="0" maxOccurs="1"/>
	  <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

This schema lets you send a single reference, or multiple references, as well as a single XML container with all the relevant blocks and provides extensions points. I think that this still meets the original intent.

Cheers
James

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 20 Mar 2013 12:41:41 +0800

The example in section 4.3 is inconsistent with the schema for emergencyCall.ProviderInfo defined in section 5.10. The schema requires a DataProviderString element.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Winterbottom, James
Sent: Wednesday, 20 March 2013 2:43 PM
To: [email-masked]
Subject: [Ecrit] Additional Data -07

Hi Authors,

<?xml version="1.0"?>
<xs:schema

	

Cheers
James

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Brian Rosen <[email-masked]>
Date: Wed, 20 Mar 2013 10:09:00 -0400

I think you misunderstand the mechanism, although what we provide isn't EXACTLY what you asked for.

You can
1) provide a single structure with multiple URIs, each URI to a different container type.  This would look like
<provided-by xmlns="urn:ietf:params:xml:ns:emergencyCallAddlData">
  <emergencyCallDataReference ref='http:addlData,example.com/ref1', purpose='emergencyCallData.ProviderInfo'/>
  <emergencyCallDataReference ref='http:addlData,example.com/ref2', purpose='emergencyCallData.SvcInfo'/>
   …
</provided-by>

2) provide a single XML container with the actual XML structure you want.  This would look like
<provided-by xmlns="urn:ietf:params:xml:ns:emergencyCallAddlData">
  <emergencyCallDataValue purpose='emergencyCallData.ProviderInfo>
    <emergencyCall.ProviderInfo>
        <DataProvider String>Example SP</DataProviderString>
        <ProviderID>11234</ProviderId>
    …
    </emergencyCall.ProviderInfo>
  </emergencyCallDataValue>
  <emergencyCallDataValue purpose='emergencyCallData.SvcInfo>
    <emergencyCall.SvcInfo>
      <ServiceEnvironment>Business</ServiceEnvironment>
    …
    </emergencyCall.SvcInfo>
  </emergencyCallDataValue>
</provided-by>

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 21 Mar 2013 06:22:31 +0800

Hi Brian,

I can see that this can be used to provide what will meet my needs, but it becomes a bit clunky in the URI case where a single source might provide multiple blocks and you need all (or more than one block) to get the information you need. In this case the client needs to fetch multiple data sets and then glue them together.

I think a useful addition to the document would be to allow the fetching of all the additional data blocks that an node has in one fetch. I can think of several ways that this could be done:
1) Allow a general purpose; purpose="emergencyCallData" and this would say to the receiving end that a GET to this URI will give you all I have.
2) Allow a compound purpose so that you can specify which blocks the URI can return (I don't like this because it requires specific parsing of the purpose field).
3) Change the semantics of the GET to any of define URI blocks so that the server is allowed to return whatever blocks it has providing that it returns at least the block type that the URI was for. For example, if I used the list of URI you provided below, a GET to https:addlData,example.com/ref1 would allow the server to return; emergencyCallData.ProviderInfo, emergencyCallData.SvcInfo, and any other blocks it has.

I know that this is an optimization, but as specified a PSAP in i3 will need to make 3 additional data queries to the LIF to get what it needs.

Cheers
James

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, 21 March 2013 1:09 AM
To: Winterbottom, James
Cc: [email-masked]
Subject: Re: [Ecrit] Additional Data -07

You can
1) provide a single structure with multiple URIs, each URI to a different container type.  This would look like <provided-by xmlns="urn:ietf:params:xml:ns:emergencyCallAddlData">
  <emergencyCallDataReference ref='http:addlData,example.com/ref1', purpose='emergencyCallData.ProviderInfo'/>
  <emergencyCallDataReference ref='http:addlData,example.com/ref2', purpose='emergencyCallData.SvcInfo'/>
   ...
</provided-by>

2) provide a single XML container with the actual XML structure you want.  This would look like <provided-by xmlns="urn:ietf:params:xml:ns:emergencyCallAddlData">
    ...
    ...