Subject: [Ecrit] Additional Data: Transport Related Question

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 28 May 2013 10:04:51 +0200 (CEST)

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

---

From: Brian Rosen <[email-masked]>
Date: Tue, 28 May 2013 08:47:25 -0400

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:

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 29 May 2013 06:42:47 +0800

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

Brian

On May 28, 2013, at 4:04 AM, Hannes Tschofenig <[email-masked]<mailto:[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<http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-08#section-5.5>) I would like to bring to your attention.
Randy wrote:

"

"
       When additional data is

"

"

GET /path/file.html HTTP/1.1
Host: www.example.com<http://www.example.com>
Accept: text/*, text/html, application/emergencyCall.SubInfo+xml

HTTP/1.1 200 OK

                    <uri>tel:+1-418-656-9254;ext=102</uri<tel:+1-418-656-9254;ext=102%3c/uri>>
                    <uri>tel:+1-418-262-6501</uri<tel:+1-418-262-6501%3c/uri>>
                    <text>[email-masked]<mailto:[email-masked]></text>
                    <uri>http://nomis80.org</uri><http://nomis80.org%3c/uri%3e>

Ciao
Hannes

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 29 May 2013 16:36:36 +0300

Hi James, 

calling it "wrapping" wasn't entirely correct, as the example shows. 

LoST and HELD indeed use the same approach. 

I personally prefer to use the same approach LoST and HELD already use. Since Randy spotted this ambiguity  in the current text I wanted to get feedback from the group. 

Ciao
Hannes

On May 29, 2013, at 1:42 AM, Winterbottom, James 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.
>  
> 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: Randall Gellens <[email-masked]>
Date: Thu, 30 May 2013 17:28:12 -0700

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

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

"

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

"

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

"

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:

Host: www.example.com

Accept: text/*, text/html,
application/emergencyCall.SubInfo+xml

Here is an
example response:

HTTP/1.1 200 OK

Server: Apache

Cache-control: private

Content-Type:
application/emergencyCall.SubInfo+xml;charset=utf-8

Content-Length: tbd

<?xml version="1.0"
encoding="UTF-8"?>

<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>

<given>Simon</given>

<additional/>

<prefix/>

<suffix>ing. jr</suffix>

<suffix>M.Sc.</suffix>

</n>

<anniversary>

</anniversary>

<lang>

</parameters>

</lang>

<lang>

</parameters>

</lang>

<org>

</parameters>

<text>Viagenie</text>

</org>

<adr>

<parameters>

2875 boul. Laurier, suite
D2-630

Quebec, QC, Canada

G1V
2M2</text></label>

</parameters>

<pobox/>

<ext/>

<region>QC</region>

<code>G1V 2M2</code>

</adr>

<tel>

<parameters>

<type>

<text>work</text>

<text>voice</text>

</type>

</parameters>

</tel>

<tel>

<parameters>

<type>

<text>work</text>

<text>text</text>

<text>voice</text>

<text>cell</text>

<text>video</text>

</type>

</parameters>

</tel>

<email>

</parameters>

</email>

<geo>

</parameters>

</geo>

<key>

</parameters>

<uri>

</uri>

</key>

<url>

</parameters>

</url>

</vcard>

</vcards>

</xc:SubscriberData>

Ciao

Hannes

Ecrit mailing list

[email-masked]

Ecrit mailing list

[email-masked]

--

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: Hannes Tschofenig <[email-masked]>
Date: Fri, 31 May 2013 17:47:12 +0300

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: 

"

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.)
> 
> 
> 
> 
> Opinions are personal;    facts are suspect;    I speak for myself only