Subject: [Ecrit] Additional Data: Version -08

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 05 May 2013 14:29:57 +0300

Hi all,

I just posted an interim update (as version -08) for the additional data 
draft. It captures some of the discussions we had on the mailing list 
recently but it is not a complete update yet since there are a number of 
other issues that need to be addressed.

Here is the updated version:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data

 From the diff you can see that I
* updated the introduction,
* added terminology (related to the discussion about service provider),
* updated the XML schemas,
* included extension points to the schemas,
* added more examples (which have been validated against the schemas),
* added the vCard/xCard XML schema,
* fixed various bugs, and
* updated references

Ciao
Hannes

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 May 2013 23:07:21 -0400

I haven't looked at this for several versions, so this comment is not 
specific to this version...

I see no mention of use of Content-Disposition in this draft.
It really ought to talk about that and show it in examples.
Take a look at RFC5621 for issues to consider. A couple of main points:

- In cases where the data is in the message and referenced from 
Call-Info, the Content-Disposition should be 'by-reference'.

- Think carefully about how you want to set the handling parameter.

	Thanks,
	Paul

On 5/5/13 7:29 AM, Hannes Tschofenig wrote:
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 10 May 2013 09:35:22 -0400

Yeah, we definitely want 'by-reference' for Content-Disposition

Usually, I would expect to see the handling parameter for the multipart/mixed be 'optional', but that's because I'm only thinking that we might see SDP,] location and and additional-data parts and nothing else.  But who knows what might happen in the future.

But what about the additional-data part itself?  'render' is probably okay.  Is there something better?

Brian

On May 9, 2013, at 11:07 PM, Paul Kyzivat <[email-masked]> wrote:

> I haven't looked at this for several versions, so this comment is not specific to this version...
> 
> - In cases where the data is in the message and referenced from Call-Info, the Content-Disposition should be 'by-reference'.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 May 2013 16:10:58 -0400

> Usually, I would expect to see the handling parameter for the multipart/mixed be 'optional', but that's because I'm only thinking that we might see SDP,] location and and additional-data parts and…

If what you have is a multipart/mixed containing SDP and 
additional-data, then it is essential that the SDP be processed. To 
ensure that the multipart/mixed must be 'required'. Then the SDP can be 
'required' and the additional-data 'optional'.

Even RFC5621 neglected to specify what the Content-Disposition value 
should be for multipart bodies. By default it is 'render' which doesn't 
make a lot of sense. But I think we consider it grandfathered. Its also 
the default (for everything except SDP), and 'required' is also default, 
so you can omit Content-Disposition in those cases. But if you want the 
entire multipart to be optional then you will need to specify
    Content-Disposition:render;handling=optional

> But what about the additional-data part itself?  'render' is probably okay.  Is there something better?

That is the one that should be 'by-reference'. That means that what to 
do with it is determined by the reference. In your case, that is the 
Call-info:...purpose=emergencyCallData...

So I think the example in Section 10 should be:

       INVITE sips:[email-masked] SIP/2.0
       Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
       Max-Forwards: 70
       To: Bob <sips:[email-masked]>
       From: Alice <sips:[email-masked]>;tag=9fxced76sl
       Call-ID: [email-masked]
       Call-Info: <http://wwww.example.com/alice/photo.jpg>
         ;purpose=icon,
         <http://www.example.com/alice/> ;purpose=info,
         <cid:[email-masked]>
             ;purpose=emergencyCallData.ProviderInfo
       Geolocation: <cid:[email-masked]>
       Geolocation-Routing: no
       Accept: application/sdp, application/pidf+xml,
          application/emergencyCallProviderinfo+xml
       CSeq: 31862 INVITE
       Contact: <sips:[email-masked]>
       Content-Type: multipart/mixed; boundary=boundary1

       Content-Length: ...

       --boundary1

       Content-Type: application/sdp

       ... can omit Content-Disposition because defaults are ok
       ...SDP goes here

       --boundary1

       Content-Type: application/pidf+xml
       Content-ID: <[email-masked]>
       Content-Disposition: by-reference;handling=optional

       \0x2026PIDF-LO goes here

       --boundary1--

       Content-Type: application/emergencyCall.ProviderInfo+xml
       Content-ID: <[email-masked]>
       Content-Disposition: by-reference;handling=optional

       ...Additional Data goes here

       --boundary1--

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 12 May 2013 20:19:23 +0300

Hi Paul, Hi Brian,

I am OK to add the Content-Disposition line to the example but I am 
wondering how much value it adds. I have just been looking at RFC 6442 
("SIP Location Conveyance") and we don't use Content-Disposition there 
either. From a high-level point of view I don't think that the 
additional data document is much different from adding location to the 
body of the SIP message and to have a reference in the header.

Ciao
Hannes

On 05/10/2013 11:10 PM, Paul Kyzivat wrote:
>> Usually, I would expect to see the handling parameter for the
>> multipart/mixed be 'optional', but that's because I'm only thinking
>> that we might see SDP,] location and and additional-data parts and
>> nothing else.  But who knows what might happen in the future.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 12 May 2013 20:14:43 -0400

> body of the SIP message and to have a reference in the header.

It should have been used there too. I'm sorry I didn't catch that.

The problem is that without it the rules for how to process multipart 
bodies are ambiguous and ad hoc. In the past there was very little use 
of that, and we have been getting by with ad hoc. But as more complex 
usages come up (and they are) it gets harder and harder to do the right 
thing that way.

	Thanks,
	Paul

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 13 May 2013 10:18:53 +0200 (CEST)

It is obviously not a huge addition to add this line

"

"

to the payloads.

So, if there is some value in doing that I am fine with it.

Gesendet: Montag, 13. Mai 2013 um 02:14 Uhr

Von: "Paul Kyzivat" <[email-masked]>

An: "Hannes Tschofenig" <[email-masked]>

Cc: "Brian Rosen" <[email-masked]>, [email-masked]

Betreff: Re: [Ecrit] Additional Data: Version -08

thing that way.

Thanks,

Paul

>>> But what about the additional-data part itself? 'render' is probably

>>> okay. Is there something better?

>>>>> I just posted an interim update (as version -08) for the additional

>>>>> data

>>>>> recently but it is not a complete update yet since there are a

>>>>> number of

>>>>> * added terminology (related to the discussion about service

>>>>> provider),

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 May 2013 11:23:33 -0400

> Content-Disposition: by-reference;handling=optional

Note that the choice of optional/required may depend on context. The WG 
may want to discuss that. But, since it is being referenced from a 
header field, and processing of the header field is itself in general 
optional, maybe optional is the only meaningful choice. If you want it 
to be required, then you may need to use a sip option.

	Thanks,
	Paul

> *Gesendet:* Montag, 13. Mai 2013 um 02:14 Uhr
> *Von:* "Paul Kyzivat" <[email-masked]>
> *An:* "Hannes Tschofenig" <[email-masked]>
> *Cc:* "Brian Rosen" <[email-masked]>, [email-masked]
> *Betreff:* Re: [Ecrit] Additional Data: Version -08
>
>