Subject: [Ecrit] Thoughts on -rosen-ecrit-additional-data

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 18 Aug 2010 11:24:53 +0800

What this draft attempts to do is corral a number of different - albeit superficially related - beasts into the same pen.  It then applies a very generic label and leaves it at that.

You see, there's already a mechanism for the generic bucket: multipart/mixed.

What if this document instead concentrated on identifying the different types of call information that might be relevant to an emergency call, defined a purpose label for each, and defined formats for those that don't already have formats (vCard does nicely, thanks).  New formats need new MIME types too.

The generic container idea is not really necessary, particularly when it is clear that this information can come from multiple sources.

--Martin

p.s.  I'll point out the strong similarities between Call-Info and the HTTP Link header [1], substituting "rel" for "purpose".  There is a lot of knowledge and experience built into that specification that could be relied upon here.

[1] http://tools.ietf.org/html/draft-nottingham-http-link-header

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 18 Aug 2010 11:07:38 +0300

This would be worth a try. 

This would leave us with a number of 
* defined MIME types (for the data that is exchanged), 
* a description about the security and privacy mechanisms, and 
* a description of how the information is conveyed (reference within
Call-Info).

Right? 

Ciao
Hannes 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of ext Thomson, Martin
> Sent: Wednesday, August 18, 2010 6:25 AM
> To: 'ecrit'
> Subject: [Ecrit] Thoughts on -rosen-ecrit-additional-data
> 
> What this draft attempts to do is corral a number of 
> different - albeit superficially related - beasts into the 
> same pen.  It then applies a very generic label and leaves it at that.
> 
> What if this document instead concentrated on identifying the 
> different types of call information that might be relevant to 
> an emergency call, defined a purpose label for each, and 
> defined formats for those that don't already have formats 
> (vCard does nicely, thanks).  New formats need new MIME types too.
> 
> The generic container idea is not really necessary, 
> particularly when it is clear that this information can come 
> from multiple sources.
> 
> --Martin
> 
> p.s.  I'll point out the strong similarities between 
> Call-Info and the HTTP Link header [1], substituting "rel" 
> for "purpose".  There is a lot of knowledge and experience 
> built into that specification that could be relied upon here.
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 18 Aug 2010 08:57:00 -0400

I'm certainly not worried about the decoration around the data, so multipart/mime is fine with me.

I care about two aspects:
1. There is a URI in a SIP message (Call-Info header) that points to the data structure, retrievable with a simple https GET
2. There is a precise, interoperable definition of each of the allowed components

I don't care how the components or the outer envelope is structured.

I would point out that in the proposed structure, there are two vCard thingies - contact information on the source of the data, and "subscriber" contact information.  Of course one could have two vCards, each in a part, but something has to mark which one is which.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 19 Aug 2010 04:22:53 +0800

My concern a bit is that we are already finding some things in the access provider information working group that don't logically fit into a vCARD, and won't, necessarily, be conveyed in a SIP header. This makes the current set of proposals rather ugly and bordering on unworkable.

Cheers
James

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian Rosen
> Sent: Wednesday, 18 August 2010 10:57 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: ecrit; Thomson, Martin
> Subject: Re: [Ecrit] Thoughts on -rosen-ecrit-additional-data
> 
> 1. There is a URI in a SIP message (Call-Info header) that points to the
> data structure, retrievable with a simple https GET
> I would point out that in the proposed structure, there are two vCard
> thingies - contact information on the source of the data, and "subscriber"
> contact information.  Of course one could have two vCards, each in a part,
> but something has to mark which one is which.
> 
> Brian
> 
> 
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 18 Aug 2010 16:50:20 -0400

The vCard is just for contact data.  Other info would be in another component, which if we did what Martin is suggesting would mean we create a new mime type.

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 19 Aug 2010 06:48:26 +0800

That's about right.  There are probably some wrinkles to work out, but that would be the idea.

> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:[email-masked]]
> Sent: Wednesday, 18 August 2010 6:08 PM
> To: Thomson, Martin; ecrit
> Subject: RE: [Ecrit] Thoughts on -rosen-ecrit-additional-data
>