Subject: [Ecrit] Additional Data by value from more than one source

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 21 May 2012 17:49:38 -0400

Suppose two service providers are in the call path.  Both of them should add Additional Call Data.  Suppose they both do it by value.

Since we broke up the data structure into separate MIME types, there could be two blocks of the same type.  How do we know which belongs with which? For example, you can have two data provider blocks and two call service blocks.  How would you know which pair went together?

Best I can come up with is force separate Call-Info headers and assume all the blocks from one header come from the same provider.  Yuck.

Can't nest mime/multipart, so no way to actually structure the data.

I'm rethinking what the mime envelope of each block gets us.  Not clear its worth it over an XML object with optional elements.  If you had one mime type that was a top level Additional Call Data type, which contained a complex type with several optional subelements, each of which were the blocks, you could have more than one of them pointed to by the CIDs.

Brian

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 May 2012 15:16:26 -0700

What's wrong with a pointer from the content to the data provider?

Link: <cid:[email-masked]>; rel=via

See RFC 5988.  ("via" seemed the most appropriate from skimming
through the registry, but you could use another if you find a better
fit on semantics.  I couldn't see a link relation for the reverse
link, but it doesn't seem as useful.)

On 21 May 2012 14:49, Rosen, Brian <[email-masked]> wrote:
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 22 May 2012 06:17:46 +0800

Brian,

Each data-blob seems to have provider information in it anyway, so doesn't this allow the data to be aligned as you require?

The alternative would be to include a correlation-id in data elements that allows them to be linked.

Cheers
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rosen, Brian
> Sent: Tuesday, 22 May 2012 7:50 AM
> To: [email-masked] Org
> Subject: [Ecrit] Additional Data by value from more than one source
> 
> Suppose two service providers are in the call path.  Both of them should
> add Additional Call Data.  Suppose they both do it by value.
> 
> Since we broke up the data structure into separate MIME types, there could
> be two blocks of the same type.  How do we know which belongs with which?
> For example, you can have two data provider blocks and two call service
> blocks.  How would you know which pair went together?
> 
> Best I can come up with is force separate Call-Info headers and assume all
> the blocks from one header come from the same provider.  Yuck.
> 
> I'm rethinking what the mime envelope of each block gets us.  Not clear
> its worth it over an XML object with optional elements.  If you had one
> mime type that was a top level Additional Call Data type, which contained
> a complex type with several optional subelements, each of which were the
> blocks, you could have more than one of them pointed to by the CIDs.
> 
> Brian
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 22 May 2012 09:08:23 -0400

"Link" isn't a sip header is it?

Can we answer the question of what having multiple MIME types buys us?  I note that the normal case will be that the Call-Info has to have multiple CIDs, one for each block.
What do we get out of the MIME type itself over a single MIME type for AdditionalCallData, and an XML structure for the blocks?

The only advantage I can think of is a more natural extension point, but that seems to be a very small positive with several negatives offsetting it.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 22 May 2012 09:17:41 -0400

Yeah, we could specify that the CID have a domain that is the same for all of the blocks from a given provider.

That's probably the simplest answer.

I still would like to make sure separate MIME types has enough advantages to overcome this and the issue that the Call-Info header has to have multiple CIDs, one for each block.

Brian

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 May 2012 08:48:01 -0700

> "Link" isn't a sip header is it?

and?

If you don't like it, an explicit link in content requires a little
specification effort, but it is less implicit.  That is rather than:

  Call-Info -> info
  Call-Info -> info provider info

You can have:

  Call-Info -> info -> info provider info

Which is arguably cleaner semantically.

> Can we answer the question of what having multiple MIME types buys us?

Not having to define "an XML structure for the blocks?"

> The only advantage I can think of is a more natural extension point, but that seems to be a very small positive with several negatives offsetting it.

Several?  Or just one: clearer linkage between units of information.

Not having to implement XML vCard seems like an advantage in favour of
separate blocks.

--Martin

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 22 May 2012 12:28:30 -0400

>> "Link" isn't a sip header is it?
Can't use it.

> Which is arguably cleaner semantically.
Not sure how this would work.  One CID in Call Info points to the first block, with that block having a CID to another block?

> Not having to define "an XML structure for the blocks?"
You mean one complex type with an extensible list of blocks?

> Several?  Or just one: clearer linkage between units of information.
No, the XML also means the Call Info is crowded.  Instead of one URI per AdditionalCallData, there is one per block.

> Not having to implement XML vCard seems like an advantage in favour of
It's defined as using the XML vCARD, which is now a standard.  Among other things, the vCard is not the only element in the block, and there are vCards that represent more than one entity (subscriber, service provider, device owner, …)

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 May 2012 13:55:57 -0700

>>> "Link" isn't a sip header is it?

We sit at the cusp of what can and can't be used.  If we decide we
need it - and agree - we can use it.  It was simply a suggestion, my
preference is for explicit links from content, which offer clearer
semantics.

> Not sure how this would work.  One CID in Call Info points to the first block, with that block having a CID to another block?

That's the basic idea.

> You mean one complex type with an extensible list of blocks?
That's pretty much useless once you hit unique particle attribution:
you end up with the same sort of generic container that...multipart
MIME provides.  And then you have to uses XPointer to get your
references right, which isn't great.

> No, the XML also means the Call Info is crowded.  Instead of one URI per AdditionalCallData, there is one per block.
Unless you do as I suggest above.

--Martin