Subject: Re: [Ecrit] Additional Data: Transport Related Question

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 3 Jun 2013 11:32:03 +0800

Hi Hannes,

I think I would change the last sentence of the proposed new text to:
"For transport in SIP or HTTP, the additional data is
        defined as a series of MIME objects, one for each of the
        data structure types."

This allows multiple structures of the same type to be fetched at the same time.
For example a NENA LIF could return multiple emergencyCall.ProviderInfo structures depending on what is provisioned.

Cheers
James

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Saturday, 1 June 2013 12:47 AM
To: Randall Gellens
Cc: Hannes Tschofenig; Winterbottom, James; Brian Rosen; [email-masked]
Subject: Re: [Ecrit] Additional Data: Transport Related Question

Thanks for the feedback. 

To close this open issue I am suggesting to make the following change to the draft for improved clarity:

Change from

"
        To be conveyed in a SIP body additional data about a call is
        defined as a series of MIME objects, each with an XML data
        structure contained inside.
"

to: 

"
        For transport in SIP or HTTP, the additional data is
        defined as a series of MIME objects, one for each of the
        data structures.
"

I would also suggest to add the example to the draft. 

Ciao
Hannes

On May 31, 2013, at 3:28 AM, Randall Gellens wrote:

> Hi everyone,
> 
> James' response matches my understanding: there is no wrapping or encapsulation; the MIME type is used to identify the type of data.  In the example Hannes provided, the MIME type "application/emergencyCall.SubInfo+xml" identifies the data.
> 
> (When the data is carried in the SIP body, MIME Multipart/Mixed is 
> used to separate the body parts, so in that sense, Multipart/Mixed 
> encapsulates the data, but at least for body parts which are XML or 
> other textual data, the individual MIME types of each body part only 
> identifies the data, there is no extra encapsulation.)
> 
> 
> 
> 
> At 6:42 AM +0800 5/29/13, James Winterbottom wrote:
> 
>> I don't entirely agree with this last point.
>> For starters I don't think that you are "wrapping" the XML object with MIME, you are simply signaling to the receiver that the contents of the body are xml that refer to a specific type of object. This is kind and cost nothing since the MIME types already exist.
>>  
>> Secondly, it can be used in the header of the actual request to indicate what the receiver is expecting to get back.
>>  
>> I will add that both HELD and LoST specify and use MIME types in their HTTP bindings, so it isn't clear to me why this should be different.
>>  
>> Cheers
>> James
>>  
>>  
>>  
>>  
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Brian Rosen
>> Sent: Tuesday, 28 May 2013 10:47 PM
>> To: Hannes Tschofenig
>> Cc: [email-masked]
>> Subject: Re: [Ecrit] Additional Data: Transport Related Question
>>  
>> We need the MIME types to separate them in the body and reference them with the CID.  Wrapping the XML object with MIME provides no benefit when you get them by reference.
>>  
>> Brian
>>  
>> On May 28, 2013, at 4:04 AM, Hannes Tschofenig <[email-masked]> wrote:
>> 
>> 
>> Hi all,
>>  
>> in offlist discussions Randy raised an interesting question regarding -08 (http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-08) I would like to bring to your attention.
>> Randy wrote:
>>  
>> In Section 4 first numbered hanging indent there is text:
>>  
>> "
>>         To be conveyed in a SIP body additional data about a call is
>>         defined as a series of MIME objects, each with an XML data
>>         structure contained inside.
>> "
>>  
>> and soon after there is this text:
>>  
>> "
>>        When additional data is
>>         provided by reference (in SIP signaling or Provided-By), each
>>         HTTPS URL references one block; the data is retrieved with an
>>         HTTP GET operation, which returns one of the blocks as an XML
>>         object.
>> "
>>  
>> I thought that even when HTTPS is used, the XML data is still 
>> identified as a MIME type?  That is, the HTTP response indicates that 
>> data of MIME type 'application/emergencyCall.ProviderInfo+xml' or 
>> whatever is being sent?
>>  
>> If I'm incorrect and the data is not identified as a MIME type, then 
>> the first text should be reworded for clarity as:
>>  
>> "
>>        To be conveyed in a SIP body, the additional data is
>>         defined as a series of MIME objects, one for each of the
>>         XML data structures.
>> "
>>  
>> Otherwise (if the data is identified using MIME types) then we should 
>> change the first text to:
>>  
>> "
>>         For transport in SIP or HTTP, the additional data is
>>         defined as a series of MIME objects, one for each of the
>>         data structures.
>> "
>>  
>> I think it was slightly misleading to talk about the MIME type 
>> "containing" the XML data structure, since there is no additional 
>> encapsulation (aside from any 8-bit character considerations); 
>> rather, the MIME type is used to identify the data.  This is separate 
>> from the use of MIME body parts inside the SIP body to delineate the 
>> various parts.
>>  
>> My understanding so far was that MIME encapsulation is used for data that is carried in SIP and in HTTP.
>>  
>> Here is an example. Imagine that a PSAP obtains an HTTPS URI pointing to Owner/Subscriber Information data.
>>  
>> This would lead to the following request:
>>  
>> GET /path/file.html HTTP/1.1
>> Host: www.example.com
>> Accept: text/*, text/html, application/emergencyCall.SubInfo+xml
>>  
>> Here is an example response:
>>  
>> HTTP/1.1 200 OK
>> Date: Mon, 27 Jul 2009 12:28:53 GMT
>> Server: Apache
>> Cache-control: private
>> Content-Type: application/emergencyCall.SubInfo+xml;charset=utf-8
>> Content-Length: tbd
>>  
>> <?xml version="1.0" encoding="UTF-8"?> <ad:emergencyCall.SubInfo
>>      xmlns:ad="urn:ietf:params:xml:ns:emergencyCall.SubInfo"
>>      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>>     <xc:SubscriberData xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">
>>         <vcards xmlns="urn:ietf:params:xml:ns:vcard-4.0">
>>             <vcard>
>>                 <fn><text>Simon Perreault</text></fn>
>>                 <n>
>>                     <surname>Perreault</surname>
>>                     <given>Simon</given>
>>                     <additional/>
>>                     <prefix/>
>>                     <suffix>ing. jr</suffix>
>>                     <suffix>M.Sc.</suffix>
>>                 </n>
>>                 <bday><date>--0203</date></bday>
>>                 <anniversary>
>>                     <date-time>20090808T1430-0500</date-time>
>>                 </anniversary>
>>                 <gender><sex>M</sex></gender>
>>                 <lang>
>>                     <parameters><pref><integer>1</integer></pref>
>>                     </parameters>
>>                     <language-tag>fr</language-tag>
>>                 </lang>
>>                 <lang>
>>                     <parameters><pref><integer>2</integer></pref>
>>                     </parameters>
>>                     <language-tag>en</language-tag>
>>                 </lang>
>>                 <org>
>>                     <parameters><type><text>work</text></type>
>>                     </parameters>
>>                     <text>Viagenie</text>
>>                 </org>
>>                 <adr>
>>                     <parameters>
>>                         <type><text>work</text></type>
>>                         <label><text>Simon Perreault
>>                             2875 boul. Laurier, suite D2-630
>>                             Quebec, QC, Canada
>>                             G1V 2M2</text></label>
>>                     </parameters>
>>                     <pobox/>
>>                     <ext/>
>>                     <street>2875 boul. Laurier, suite D2-630</street>
>>                     <locality>Quebec</locality>
>>                     <region>QC</region>
>>                     <code>G1V 2M2</code>
>>                     <country>Canada</country>
>>                 </adr>
>>                 <tel>
>>                     <parameters>
>>                         <type>
>>                             <text>work</text>
>>                             <text>voice</text>
>>                         </type>
>>                     </parameters>
>>                     <uri>tel:+1-418-656-9254;ext=102</uri>
>>                 </tel>
>>                 <tel>
>>                     <parameters>
>>                         <type>
>>                             <text>work</text>
>>                             <text>text</text>
>>                             <text>voice</text>
>>                             <text>cell</text>
>>                             <text>video</text>
>>                         </type>
>>                     </parameters>
>>                     <uri>tel:+1-418-262-6501</uri>
>>                 </tel>
>>                 <email>
>>                     <parameters><type><text>work</text></type>
>>                     </parameters>
>>                     <text>[email-masked]</text>
>>                 </email>
>>                 <geo>
>>                     <parameters><type><text>work</text></type>
>>                     </parameters>
>>                     <uri>geo:46.766336,-71.28955</uri>
>>                 </geo>
>>                 <key>
>>                     <parameters><type><text>work</text></type>
>>                     </parameters>
>>                     <uri>
>>                     http://www.viagenie.ca/simon.perreault/simon.asc
>>                     </uri>
>>                 </key>
>>                 <tz><text>America/Montreal</text></tz>
>>                 <url>
>>                     <parameters><type><text>home</text></type>
>>                     </parameters>
>>                     <uri>http://nomis80.org</uri>
>>                 </url>
>>             </vcard>
>>         </vcards>
>>     </xc:SubscriberData>
>> </ad:emergencyCall.SubInfo>
>>  
>> Ciao
>> Hannes
>>  
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>  
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
> 
> 
> --
> 
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: --------------- 640K ought to be 
> enough for anybody.  --Bill Gates, 1981

---

From: Brian Rosen <[email-masked]>
Date: Mon, 3 Jun 2013 10:00:26 -0400

That would mean we would need the Additional Data by Reference to be a web service where you could list all the mime types and get them all in one operation.

The current situation is that you get a URI for each block with a parameter that tells you what type it is, and you fetch them one by one.  

Brian

On Jun 2, 2013, at 11:32 PM, "Winterbottom, James" <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Thanks for the feedback. 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> 
> iQEcBAEBCgAGBQJRqLfwAAoJEGhJURNOOiAtL4YH/imeY3yr7trGPHzgRWj7v76P
> a+d6EUbopG3/j8K3llaSeuT6lcYEXgn6PRqL4gMffttlCYZNeVbByVpfiOq5AE3z
> bTT8xb6/1LWXCJ/xb8zb3wFMAkcQbunbat6cgWKmfqQ6hXR90boV4nMdid407Efc
> Ku1uDQ/ePhaZVWwjNzFjmo0WvaQfky8FXevGTP35hhGBWBRXoMeksjrP66pXF0Fp
> 2tdC70PksCJECF6HMnfY0p0d3TP+Pgq0zs8j4A4zog1wO8PHpqQrTsZ63vJ9cLTO
> 2ZQAZEeE9krWivBaAQDe+f1Di2ReuVuvmMwcgC1ynhp9PtWpK3LXb4lcQqpikW4=
> =05bX
> -----END PGP SIGNATURE-----

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 4 Jun 2013 04:53:09 +0800

No, I have two companies that provide that access service.
In this case I want a single URI that return two provider data blobs. 

Cheers
James

----- Original Message -----
From: Brian Rosen [mailto:[email-masked]]
Sent: Monday, June 03, 2013 10:00 PM
To: Winterbottom, James
Cc: Hannes Tschofenig <[email-masked]>; Randall Gellens <[email-masked]>; Brian Rosen <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Ecrit] Additional Data: Transport Related Question

Brian

---

From: Brian Rosen <[email-masked]>
Date: Mon, 3 Jun 2013 16:58:01 -0400

Sorry, I don't understand this case.

An access network would provide a PIDF with a provided-by that had the URI in it.  That would be the (single) access provider who provided the PIDF.

How do I get two access providers and how does one PIDF have data from both of them?

Brian

---

From: Randall Gellens <[email-masked]>
Date: Mon, 3 Jun 2013 15:26:12 -0700

The model of one URI = one block makes sense for a number of reasons, 
including that it makes it easy for the emergency service agency to 
decide which blocks to access.

-------------- Randomly selected tag: ---------------
Did you know that clones never use mirrors?

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 4 Jun 2013 06:39:51 +0800

Brian,

I can have up to 3 different organizations coming together to provide a domestic broadband service in many countries. In my case, my ISP knows who my layers 2 and physical access providers are. They could easily therefore have three provider data blobs one for them and one for each of the others. In this case I want to only provide a single URI and get back all three data provider blobs. This would be valid using the MIME in the HTTP header anyway. All I am asking for is for the text to say so.

Cheers
James

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, 4 June 2013 6:58 AM
To: Winterbottom, James
Cc: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [Ecrit] Additional Data: Transport Related Question

Brian

On Jun 3, 2013, at 4:53 PM, "Winterbottom, James" <[email-masked]> wrote:

> Cc: Hannes Tschofenig <[email-masked]>; Randall Gellens 
> <[email-masked]>; Brian Rosen <[email-masked]>; 
> [email-masked] <[email-masked]>
>>>> identified as a MIME type?  That is, the HTTP response indicates 
>>>> that data of MIME type 'application/emergencyCall.ProviderInfo+xml' 
>>>> or whatever is being sent?
>>>> 
>>>> If I'm incorrect and the data is not identified as a MIME type, 
>>>> then the first text should be reworded for clarity as:
>>>> 
>>>> "
>>>> Otherwise (if the data is identified using MIME types) then we 
>>>> should change the first text to:
>>>> 
>>>> "
>>>> rather, the MIME type is used to identify the data.  This is 
>>>> separate from the use of MIME body parts inside the SIP body to 
>>>> delineate the various parts.
>>>> 
>>> -------------- Randomly selected tag: --------------- 640K ought to 
>>> be enough for anybody.  --Bill Gates, 1981
>>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 3 Jun 2013 19:12:34 -0400

The stated reason for having separate blocks is to allow PSAPs to control what they download.  This is going in the other direction.
It also begs the question of who hosts the blocks for the other providers, but they could decide that themselves.  

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 4 Jun 2013 07:29:02 +0800

I don't think that they can decide it for themselves easily Brian.
There is not enough granularity in the current ref Uri definitions to provide the degree of visibility that you describe here, so at present it seems to me that either we allow multiple blocks of the same type to be returned from the same fetch or the information ins't provided to the PSAP at all.

Cheers
James

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, 4 June 2013 9:13 AM
To: Winterbottom, James
Cc: Brian Rosen; [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [Ecrit] Additional Data: Transport Related Question

Brian

On Jun 3, 2013, at 6:39 PM, "Winterbottom, James" <[email-masked]> wrote:

>>>> other textual data, the individual MIME types of each body part
>>>> only identifies the data, there is no extra encapsulation.)
>>>>
>>>>
>>>>
>>>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 4 Jun 2013 11:05:24 +0800

Hi Randy,

Some of what you are suggesting are is right, some seemed to diverge.
See inline.

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]]
Sent: Tuesday, 4 June 2013 10:33 AM
To: Winterbottom, James; Brian Rosen
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: [Ecrit] Additional Data: Transport Related Question

Hi James,

Let me see if I understand your case:

        The ISP knows the underlying access provider and has a business relationship with it (one example I'm guessing would be your National Broadband Network).  The ISP is happy to supply Provider Info blocks for itself and the underlying NBN.
[AJW] Yes, this right.

In this case, there are multiple possible ways to make the Provider Info blocks available.  E.g.,
        - The ISP adds two Provider Info URIs: its own and another for the NBN
        [AJW] This is "sort of" the case I am discussing. If the ISP adds two URIs then there is no way for the PSAP to look at the URI and say "AH!! I want this one", it has to deference both and then look at the various elements in the responses to work out which order to interpret them in. I am proposing that the ISP supply one Data Provider URI. Accessing this URI will only return Data Provider elements, but it may return more than one Data Provider element if the ISP is providing information for more than just itself. Under the current scheme this is legal.

or
        - The ISP adds one URI for its own Provider Info and
        - The NBN uses the provided-by element in a PIDF-LO to supply a URI for its info
        [AJW] No, not this case.

But you seem to be discussing a case where multiple entities need to use the provided-by element of a PIDF-LO.  Is that right?  If so, the problem is that the PIDF-LO schema restricts <provided-by> to zero or one occurrence, prohibiting the use of two <provided-by> elements.
[AJW] This is not what I am suggesting at all.

At 7:29 AM +0800 6/4/13, James Winterbottom wrote:

>  There is not enough granularity in the current ref Uri definitions to
> provide the degree of visibility that you describe here, so at present
> it seems to me that either we allow multiple blocks of the same type
> to be returned from the same fetch or the information ins't provided
> to the PSAP at all.
>
>  Cheers
>  James
>
>
>  Cc: Brian Rosen; [email-masked]';
> [email-masked]'; [email-masked]'
>  The stated reason for having separate blocks is to allow PSAPs to
> control what they download.  This is going in the other direction.
>  It also begs the question of who hosts the blocks for the other
> providers, but they could decide that themselves.
>
>  Brian
>
>  On Jun 3, 2013, at 6:39 PM, "Winterbottom, James"
> <[email-masked]> wrote:
>
>>  Brian,
>>
>>  I can have up to 3 different organizations coming together to
>> provide a domestic broadband service in many countries. In my case,
>> my ISP knows who my layers 2 and physical access providers are. They
>> could easily therefore have three provider data blobs one for them
>> and one for each of the others. In this case I want to only provide a
>> single URI and get back all three data provider blobs. This would be
>> valid using the MIME in the HTTP header anyway. All I am asking for
>> is for the text to say so.
>>
>>  Cheers
>>  James
>>
>>  Cc: [email-masked]'; [email-masked]';
>> [email-masked]'; [email-masked]'
>   > An access network would provide a PIDF with a provided-by that had
> the URI in it.  That would be the (single) access provider who
> provided the PIDF.
>>
>>  On Jun 3, 2013, at 4:53 PM, "Winterbottom, James"
>> <[email-masked]> wrote:
>>
>>>  That would mean we would need the Additional Data by Reference to
>>> be a web service where you could list all the mime types and get
>>> them all in one operation.
>>>
>>>  The current situation is that you get a URI for each block with a
>>> parameter that tells you what type it is, and you fetch them one by
>>> one.
>>>
>>>  Brian
>>>
>>>  On Jun 2, 2013, at 11:32 PM, "Winterbottom, James"
>>> <[email-masked]> wrote:
>>>
>>>>  Hi Hannes,
>>>>
>   >>> For example a NENA LIF could return multiple
> emergencyCall.ProviderInfo structures depending on what is
> provisioned.
>>>>
>>>>  Cheers
>>>>  James
>>>>
>>>>
>>>>
>>>>  To close this open issue I am suggesting to make the following
>>>> change to the draft for improved clarity:
>>>>
>>>>  Change from
>>>>
>>>>  "
>>>>>  James' response matches my understanding: there is no wrapping or
>>>>> encapsulation; the MIME type is used to identify the type of data.
>>>>> In the example Hannes provided, the MIME type
>>>>> "application/emergencyCall.SubInfo+xml" identifies the data.
>>>>>
>>>>>  (When the data is carried in the SIP body, MIME Multipart/Mixed
>>>>> is  used to separate the body parts, so in that sense,
>>>>> Multipart/Mixed  encapsulates the data, but at least for body
>>>>> parts which are XML or  other textual data, the individual MIME
>>>>> types of each body part  only identifies the data, there is no
>>>>> extra encapsulation.)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>  For starters I don't think that you are "wrapping" the XML
>>>>>> object with MIME, you are simply signaling to the receiver that
>>>>>> the contents of the body are xml that refer to a specific type of
>>>>>> object. This is kind and cost nothing since the MIME types
>>>>>> already exist.
>>>>>>
>>>>>>  Secondly, it can be used in the header of the actual request to
>>>>>> indicate what the receiver is expecting to get back.
>>>>>>
>>>>>>  I will add that both HELD and LoST specify and use MIME types in
>>>>>> their HTTP bindings, so it isn't clear to me why this should be
>>>>>> different.
>>>>>>
>>>>>>  Cheers
>>>>>>  James
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  We need the MIME types to separate them in the body and
>>>>>> reference them with the CID.  Wrapping the XML object with MIME
>>>>>> provides no benefit when you get them by reference.
>>>>>>
>>>>>>  Brian
>>>>>>
>>>>>>  in offlist discussions Randy raised an interesting question
>>>>>> regarding -08
>>>>>> (http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-08)
>>>>>> I would like to bring to your attention.
>   >>>>> Randy wrote:
>>>>>>
>>>>>>  Here is an example. Imagine that a PSAP obtains an HTTPS URI
>>>>>> pointing to Owner/Subscriber Information data.
>>>>>>
>>>>>>  Content-Type:
>>>>>> application/emergencyCall.SubInfo+xml;charset=utf-8
>>>>>>  Content-Length: tbd
>>>>>>
>>>>>  -------------- Randomly selected tag: --------------- 640K ought
>>>>> to  be enough for anybody.  --Bill Gates, 1981
>>>>

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- It is bad luck to be superstitious.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 3 Jun 2013 23:55:56 -0700

Hi James,

Thanks for the clarification, that was helpful.  So, if I understand 
your case, the ISP is happy to provide Data Provider Info for both 
itself and the access network.  This saves the access network from 
the trouble of adding a <provided-by> item to the PIDF-LO, but 
introduces your concern regarding the emergency services agency 
determining which URI it wishes to access and knowing which is for 
which provider.

Is this case different from the more general case where multiple Data 
Provider Info blocks are provided?  Either way, assuming each block 
is referenced by its own URI, the the emergency services agency is 
confronted with multiple URIs for Data Provider Info blocks.  I'm not 
sure if the order in which the URIs appear is significant, or if the 
emergency services agency cares.

It seems to me that in both your specific example and in the general 
case, the emergency services agency determines in advance if they are 
interested in Data Provider Info blocks, and assuming they are, 
fetches all available.  Inside each block, the Type of Data Provider 
indicates if the block is for an access network provider, an ISP, or 
what.

So, I'm not sure what benefit there is in your specific example of 
having the ISP return both its Data Provider Info block and that of 
the access network via a single URI -- either way the emergency 
services agency needs to look inside the blocks to see which is 
which, and either way the emergency services agency accesses both 
blocks.

At 11:05 AM +0800 6/4/13, James Winterbottom wrote:

>          The ISP knows the underlying access provider and has a 
> business relationship with it (one example I'm guessing would be 
> your National Broadband Network).  The ISP is happy to supply 
> Provider Info blocks for itself and the underlying NBN.
>  [AJW] Yes, this right.
>
>          [AJW] This is "sort of" the case I am discussing. If the 
> ISP adds two URIs then there is no way for the PSAP to look at the 
> URI and say "AH!! I want this one", it has to deference both and 
> then look at the various elements in the responses to work out 
> which order to interpret them in. I am proposing that the ISP 
> supply one Data Provider URI. Accessing this URI will only return 
> Data Provider elements, but it may return more than one Data 
> Provider element if the ISP is providing information for more than 
> just itself. Under the current scheme this is legal.
>
>  or
>  But you seem to be discussing a case where multiple entities need 
> to use the provided-by element of a PIDF-LO.  Is that right?  If 
> so, the problem is that the PIDF-LO schema restricts <provided-by> 
> to zero or one occurrence, prohibiting the use of two <provided-by> 
> elements.

-------------- Randomly selected tag: ---------------
Language is a virus from outer space.  --William S. Burroughs

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 5 Jun 2013 07:40:45 +0800

Hi Randy,

The main advantage is a single request and this indicates that the data is coming from a single point. However, as I have said before, the mechanism we are using doesn't prohibit multiple blobs of the expected type being returned from a single request. It seems ridiculous to me to :
a) Introduce a completely artificial constraint that serves no purpose other than to force two fetch operations
b) have the same entity produce two different URIs that the PSAP cannot distinguish between for two blobs of the same kind of data that are both required to define the service.

Cheers
James

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]]
Sent: Tuesday, 4 June 2013 4:56 PM
To: Winterbottom, James; Randall Gellens; Brian Rosen
Cc: [email-masked]'; [email-masked]'
Subject: RE: [Ecrit] Additional Data: Transport Related Question

Hi James,

Thanks for the clarification, that was helpful.  So, if I understand your case, the ISP is happy to provide Data Provider Info for both itself and the access network.  This saves the access network from the trouble of adding a <provided-by> item to the PIDF-LO, but introduces your concern regarding the emergency services agency determining which URI it wishes to access and knowing which is for which provider.

Is this case different from the more general case where multiple Data Provider Info blocks are provided?  Either way, assuming each block is referenced by its own URI, the the emergency services agency is confronted with multiple URIs for Data Provider Info blocks.  I'm not sure if the order in which the URIs appear is significant, or if the emergency services agency cares.

It seems to me that in both your specific example and in the general case, the emergency services agency determines in advance if they are interested in Data Provider Info blocks, and assuming they are, fetches all available.  Inside each block, the Type of Data Provider indicates if the block is for an access network provider, an ISP, or what.

So, I'm not sure what benefit there is in your specific example of having the ISP return both its Data Provider Info block and that of the access network via a single URI -- either way the emergency services agency needs to look inside the blocks to see which is which, and either way the emergency services agency accesses both blocks.

At 11:05 AM +0800 6/4/13, James Winterbottom wrote:

> business relationship with it (one example I'm guessing would be your
> National Broadband Network).  The ISP is happy to supply Provider Info
> blocks for itself and the underlying NBN.
>  [AJW] Yes, this right.
>
>          [AJW] This is "sort of" the case I am discussing. If the ISP
> adds two URIs then there is no way for the PSAP to look at the URI and
> say "AH!! I want this one", it has to deference both and then look at
> the various elements in the responses to work out which order to
> interpret them in. I am proposing that the ISP supply one Data
> Provider URI. Accessing this URI will only return Data Provider
> elements, but it may return more than one Data Provider element if the
> ISP is providing information for more than just itself. Under the
> current scheme this is legal.
>
>  or
>  But you seem to be discussing a case where multiple entities need to
> use the provided-by element of a PIDF-LO.  Is that right?  If so, the
> problem is that the PIDF-LO schema restricts <provided-by> to zero or
> one occurrence, prohibiting the use of two <provided-by> elements.
>>   There is not enough granularity in the current ref Uri definitions
>> to  provide the degree of visibility that you describe here, so at
>> present
>>> and one for each of the others. In this case I want to only provide
>>> a  single URI and get back all three data provider blobs. This would
>>> be
>>    > An access network would provide a PIDF with a provided-by that
>> had  the URI in it.  That would be the (single) access provider who
>> provided the PIDF.
>>>
>>>>   Cc: Hannes Tschofenig <[email-masked]>; Randall
>>>> Gellens  <[email-masked]>; Brian Rosen <[email-masked]>;
>>>>>>   James' response matches my understanding: there is no wrapping
>>>>>> or  encapsulation; the MIME type is used to identify the type of data.
>>>>>>> the contents of the body are xml that refer to a specific type
>>>>>>> of  object. This is kind and cost nothing since the MIME types
>>>>>>> already exist.
>>>>>>>
>>>>>>>   Secondly, it can be used in the header of the actual request
>>>>>>> to  indicate what the receiver is expecting to get back.
>>>>>>>
>>>>>>>   I will add that both HELD and LoST specify and use MIME types
>>>>>>> in  their HTTP bindings, so it isn't clear to me why this should
>>>>>>> be  different.
>>>>>>>
>>>>>>>   Cheers
>>>>>>>   James
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   From: [email-masked] [mailto:[email-masked]]
>>>>>>> On  Behalf Of Brian Rosen
>>>>>>>   If I'm incorrect and the data is not identified as a MIME
>>>>>>> type,  then the first text should be reworded for clarity as:
>   >>>>>>
>>>>>>>   "
>>>>>>> "containing" the XML data structure, since there is no
>>>>>>> additional  encapsulation (aside from any 8-bit character
>>>>>>> considerations);  rather, the MIME type is used to identify the
>>>>>>> data.  This is  separate from the use of MIME body parts inside
>>>>>>> the SIP body to  delineate the various parts.
>>>>>>>
>>>>>>>   My understanding so far was that MIME encapsulation is used
>>>>>>> for  data that is carried in SIP and in HTTP.
>>>>>>>
>>>>>>   -------------- Randomly selected tag: --------------- 640K
>>>>>> ought  to  be enough for anybody.  --Bill Gates, 1981
>>>>>

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- Language is a virus from outer space.  --William S. Burroughs