Subject: [Sip] Multiple body-parts in one INFO

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Nov 2008 14:53:27 -0500

Ignoring the multiple *packages* per INFO for this email - this one is about multiple *body parts* per INFO.

Was there consensus/hum on documenting that explicitly in this draft, in Minneapolis?

Of course the INFO message has to support multiple body-parts, as does any SIP message.

The question is:
1) can we just say in the draft it must support it and point to the relevant RFCs, or...
2) do we have to explicitly describe how it's supported/handled for INFO in particular?

Doing 2 implies handling multiple body-parts has some unique issues for INFO.

Since the Subscribe/Notify RFC does not have any such text, AFAICT, I fail to see what is unique about INFO package usage from Subscribe/Notify event packages or even just MESSAGE messages, with regards to handling of multiple body-parts.
I have tried to glean that answer from the numerous emails about this issue, but they were intertwined with multiple packages per INFO, and I can't seem to find the answer.

-hadriel
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Nov 2008 16:07:14 -0500

Hadriel,

I agree that the problem of identifying which body part is the info 
package is not a unique problem to INFO.

It is however a problem that hasn't been clearly and adequately 
addressed in any of the RFCs, leading to the need for the body handling 
draft. As we move forward we are well advised to do a better job of what 
we now realize is not quite as simple as people had assumed, mostly 
because they rarely thought about multiple body parts.

I agree that we ought not have *special* normative language in one 
draft, for behavior that should be general. But IMO it is still 
advisable to provide informative language about this. And, there does 
need to be *some* way to associate the info package semantics with the 
proper body part(s). Hence the cid reference in the Info-Package header. 
The alternative would have been a special Content-Disposition, which I 
suggested. Either would work, and Eric preferred the CID reference, 
which is fine with me.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 28 Nov 2008 22:47:46 +0100

Hi,

I also preferred the special Content-Disposition. And, since C-D is per
MIME, I see no difference in having a single package or a mutlipart with
multiple packages - each package will have an associated C-D.

The CID mechanism also works, but I think we would need that even if we
only allow a single package, but at the same time still allow mutlipart.

Regards,

Christer 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, November 28, 2008 11:07 PM
To: Hadriel Kaplan
Cc: SIP List; Christer Holmberg
Subject: Re: [Sip] Multiple body-parts in one INFO

Hadriel,

	Thanks,
	Paul

Hadriel Kaplan wrote:
> Since the Subscribe/Notify RFC does not have any such text, AFAICT, I
fail to see what is unique about INFO package usage from
Subscribe/Notify event packages or even just MESSAGE messages, with
regards to handling of multiple body-parts.
> I have tried to glean that answer from the numerous emails about this
issue, but they were intertwined with multiple packages per INFO, and I
can't seem to find the answer.
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Nov 2008 17:18:47 -0500

> Sent: Friday, November 28, 2008 4:07 PM
>

Yup, we must reference that draft - no debate there.

> proper body part(s).

If we don't support multiple packages, then I assume the case for multiple body-parts in an INFO is what I'll call the "piggy-back" case.  You've got something going on that piggy-backs its bodies onto messages of all/any type.  Like for example sipfrag or geo-loc.  Right?

So let me ask this: how would one handle multiple body-parts in SUBSCRIBE, NOTIFY, or MESSAGE as defined today?  Or in INFO today?  MESSAGE, for example, has native support for text/plain and message/cpim, so what if the piggy-backer happens to use one of those content-types in a MESSAGE request?

I think/guess there are three possible answers:
1) We have to go back and update Sub/Not and Message for them to do CID's as well.
2) We make only piggy-backers use CID for their body parts.
3) We say "don't do that".

Would (2) work??

> Hence the cid reference in the Info-Package header.

I'm with Eric: cid handling has to be done for other things anyway, so if we *have* to do something let's keep it to CID.

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 28 Nov 2008 23:29:04 +0100

Could someone show an INFO message example if we would use CID?

Regards,

Christer 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Saturday, November 29, 2008 12:19 AM
To: Paul Kyzivat
Cc: SIP List; Christer Holmberg
Subject: RE: [Sip] Multiple body-parts in one INFO

> addressed in any of the RFCs, leading to the need for the body 
> handling draft.  As we move forward we are well advised to do a better

> job of what we now realize is not quite as simple as people had 
> assumed, mostly because they rarely thought about multiple body parts.

> proper body part(s).

If we don't support multiple packages, then I assume the case for
multiple body-parts in an INFO is what I'll call the "piggy-back" case.
You've got something going on that piggy-backs its bodies onto messages
of all/any type.  Like for example sipfrag or geo-loc.  Right?

So let me ask this: how would one handle multiple body-parts in
SUBSCRIBE, NOTIFY, or MESSAGE as defined today?  Or in INFO today?
MESSAGE, for example, has native support for text/plain and
message/cpim, so what if the piggy-backer happens to use one of those
content-types in a MESSAGE request?

I think/guess there are three possible answers:
1) We have to go back and update Sub/Not and Message for them to do
CID's as well.
2) We make only piggy-backers use CID for their body parts.
3) We say "don't do that".

Would (2) work??

> suggested. Either would work, and Eric preferred the CID reference, 

I'm with Eric: cid handling has to be done for other things anyway, so
if we *have* to do something let's keep it to CID.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Nov 2008 18:40:18 -0500

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Friday, November 28, 2008 5:29 PM
>

----BEGIN----
INFO sip:[email-masked] SIP/2.0
Call-ID: [email-masked]
From: <sip:[email-masked]>;tag=27285
To: <sip:[email-masked]>;tag=GR52RWG346-34
CSeq: 2 INFO
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK-6110000000000893
Max-Forwards: 70
Info-Package: dtmf-relay;cid=sleepy%40tryptophan.com
Content-Length: 10
Content-Type: application/dtmf-relay
Content-ID: <[email-masked]>

Signal=1
----END----

Or...

----BEGIN----
INFO sip:[email-masked] SIP/2.0
Call-ID: [email-masked]
From: <sip:[email-masked]>;tag=27285
To: <sip:[email-masked]>;tag=GR52RWG346-34
CSeq: 2 INFO
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK-6110000000000893
Max-Forwards: 70
Info-Package: dtmf-relay;cid=sleepy%40tryptophan.com
Geolocation: cid:[email-masked]
Content-Length: 917
Content-Type: multipart/mixed;boundary="boundary1"

--boundary1
Content-Type: application/dtmf-relay
Content-ID: <[email-masked]>

Signal=1
--boundary1
Content-Type: application/pidf+xml
Content-ID: <[email-masked]>

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:[email-masked]">
    <tuple id="sg89abcd">
     <status>
      <gp:geopriv>
       <gp:location-info>
        <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"
          xmlns:gml="http://www.opengis.net/gml">
         <gml:pos>90.0 0.0</gml:pos>
        </gml:Point>
       </gp:location-info>
      </gp:geopriv>
     </status>
     <timestamp>2008-12-25T20:57:29Z</timestamp>
    </tuple>
</presence>
--boundary1--
----END----

-hadriel
p.s. I did it by hand obviously, so I'm just guessing on content-length and such.  And I have no idea if the geo-loc stuff I created is right - I can't seem to find one example SIP message with it in a draft, and it's damn confusing. (and an impressive amount of overhead to describe a latitude+longitude, address, or well-known string)

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Nov 2008 18:47:59 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hadriel Kaplan
> Sent: Friday, November 28, 2008 6:40 PM
>
> p.s. I did it by hand obviously, so I'm just guessing on content-length
> and such.  And I have no idea if the geo-loc stuff I created is right - I
> can't seem to find one example SIP message with it in a draft, and it's
> damn confusing. (and an impressive amount of overhead to describe a
> latitude+longitude, address, or well-known string)

Oops, spoke too soon.  There's a sip-location-conveyance draft and it has an example.  Nice.  I sure hope the example in that draft is right, because I'm guessing it will become normative in practice. ;)

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 30 Nov 2008 13:12:21 +0100

Hi,

This is what I was afraid of...

I think that having to use URIs in order to recognize the info package
is anything but simple...

Regards,

Christer 

----BEGIN----

Signal=1
----END----

Or...

----BEGIN----

--boundary1

Signal=1
--boundary1

----END----

-hadriel
p.s. I did it by hand obviously, so I'm just guessing on content-length
and such.  And I have no idea if the geo-loc stuff I created is right -
I can't seem to find one example SIP message with it in a draft, and
it's damn confusing. (and an impressive amount of overhead to describe a
latitude+longitude, address, or well-known string)

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 30 Nov 2008 12:28:58 -0500

> Sent: Sunday, November 30, 2008 7:12 AM
>
> Hi,
>

Agreed.  But I don't think we need to.  Legacy INFO is already deployed.  Subscribe/Notify is already deployed.  UPDATE is already deployed. MESSAGE is already deployed.  None of them use a CID for the body part that is germane to their method's context, AFAIK.  It is up to the piggy-backer uses that want to add other body-parts to use CID for their parts.  For example, if you wanted to add a body part for geo-loc to a Notify message that was sent for a presence package, the Geolocation header would contain a CID, not the Event header.

This "problem" already exists for current SIP messages, and it's up to the new extensions that add body-parts to solve it in a backward-compatible way for all message methods.  We don't need to solve it specifically for INFO.

-hadriel

---

From: Eric Burger <[email-masked]>
Date: Sun, 30 Nov 2008 15:55:21 -0500

Don't forget, a Content-ID is a TOKEN, not a URI.  One may use a URI,  
because a URI is a token.

Does anyone read the draft before they comment?  Folks have been  
saying, "What would an INFO with multiple body parts look like?"
READ PAGES 31-32!!!

The example there uses a Content-ID of abcd9999qq and abcd1234zz.   
Does not look like a URI to me...

On Nov 30, 2008, at 12:28 PM, Hadriel Kaplan wrote:

> Agreed.  But I don't think we need to.  Legacy INFO is already  
> deployed.  Subscribe/Notify is already deployed.  UPDATE is already  
> deployed. MESSAGE is already deployed.  None of them use a CID for  
> the body part that is germane to their method's context, AFAIK.  It  
> is up to the piggy-backer uses that want to add other body-parts to  
> use CID for their parts.  For example, if you wanted to add a body  
> part for geo-loc to a Notify message that was sent for a presence  
> package, the Geolocation header would contain a CID, not the Event  
> header.
>
> This "problem" already exists for current SIP messages, and it's up  
> to the new extensions that add body-parts to solve it in a backward- 
> compatible way for all message methods.  We don't need to solve it  
> specifically for INFO.
>
> -hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 30 Nov 2008 22:51:28 +0100

Hi, 

>Does not look like a URI to me...

According to RFC2392, the ABNF of content-id is:

content-id    = url-addr-spec
url-addr-spec = addr-spec  ; URL encoding of RFC 822 addr-spec

Doesn't anyone read RFC2392 before they start using content-id?

...or, are you talking about a content-id specified somewhere else? ;)

Regards,

Christer

On Nov 30, 2008, at 12:28 PM, Hadriel Kaplan wrote:

>> I think that having to use URIs in order to recognize the info 
>> package is anything but simple...
>
> deployed. MESSAGE is already deployed.  None of them use a CID for the

> body part that is germane to their method's context, AFAIK.  It is up 
> to the piggy-backer uses that want to add other body-parts to use CID 
> for their parts.  For example, if you wanted to add a body part for 
> geo-loc to a Notify message that was sent for a presence package, the 
> Geolocation header would contain a CID, not the Event header.
>
> This "problem" already exists for current SIP messages, and it's up to

> the new extensions that add body-parts to solve it in a backward-

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 30 Nov 2008 22:58:25 +0100

Hi, 

to the piggy-backer uses that want to add other body-parts to use CID
for their parts.  For example, if you wanted to add a body part 
>for geo-loc to a Notify message that was sent for a presence package,
the Geolocation header would contain a CID, not the Event header.

Sounds ok.

But, doesn't the Info-Package header syntax still have to allow the
piggy-backer to:

1) List multiple info packages
2) For each listed info package, provide the cid

?

Regards,

Christer

---

From: Anders Kristensen <[email-masked]>
Date: Sun, 30 Nov 2008 14:18:37 -0800

Actually, Content-Id is defined for MIME in RFC 2045 as:

      id := "Content-ID" ":" msg-id

where msg-id is defined in RFC 2822 as:

msg-id          =       [CFWS] "<" id-left "@" id-right ">" [CFWS]

RFC 4228 registers Content-Id for HTTP. The actual definition of 
Content-Id for HTTP is in

    [20]  Hoff, A., Payne, J., Hapner, M., Carter, S., and M. Medin, "The
          HTTP Distribution and Replication Protocol", W3C NOTE NOTE-
          drp-19970825, August 1997.

Content-Id is not defined for SIP ;)
http://www.iana.org/assignments/sip-parameters

Anders

---

From: Eric Burger <[email-masked]>
Date: Sun, 30 Nov 2008 17:28:49 -0500

Whoopsie :-)

I stand (sort of, but not really) corrected.

On Nov 30, 2008, at 5:18 PM, Anders Kristensen wrote:

>>> The example there uses a Content-ID of abcd9999qq and  
>>> abcd1234zz.   Does not look like a URI to me...
>>> deployed.  Subscribe/Notify is already deployed.  UPDATE is  
>>> already deployed. MESSAGE is already deployed.  None of them use a  
>>> CID for the
>>> body part that is germane to their method's context, AFAIK.  It is  
>>> up to the piggy-backer uses that want to add other body-parts to  
>>> This list is for NEW development of the core SIP Protocol Use [email-masked] 
>>>  for questions on current sip Use [email-masked] for new  
>>> developments on the application of sip

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 30 Nov 2008 20:26:01 -0500

> Sent: Sunday, November 30, 2008 4:58 PM
>
> Sounds ok.

Nope.  We've already said we're going to not bother doing multiple packages. (or at least I think people have agreed with that, I hope)
So the next question was on multiple body-parts.  Since INVITE, UPDATE, PRACK, SUBSCRIBE/NOTIFY, MESSAGE, and legacy INFO, can all carry bodies and not one of them defined a CID mechanism for the body part that was specific to their message method context, we shouldn't need to for INFO either.

A "piggy-backer" is an extension to SIP that piggy-backs bodies onto any message method types.  Geolocation is an example of one.  Since it's the responsibility of the piggy-backer to handle identifying its specific body-part and dis-ambiguating it from the method's, we don't have to do anything.  In other words, Geolocation would already have to deal with current INFO message and body syntax.

For example, let's suppose someone creates an INFO package for sending virtual location information in a game, using a content-type of application/pidf+xml.  (whether they should have done it in SIP vs. the media layer is orthogonal)  And let's suppose for whatever reason the SIP stack always adds Geolocation information of the UA's physical location.
Here is what it would look like:

----BEGIN----
INFO sip:[email-masked] SIP/2.0
Call-ID: [email-masked]
From: <sip:[email-masked]>;tag=27285
To: <sip:[email-masked]>;tag=GR52RWG346-34
CSeq: 2 INFO
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK-6110000000000893
Max-Forwards: 70
Info-Package: virtual-loc
Geolocation: <cid:whereami@invalid>
Content-Length: [whatever]
Content-Type: multipart/mixed;boundary="boundary1"

--boundary1

[xml stuff goes here]
--boundary1
Content-Type: application/pidf+xml
Content-Disposition: by-reference
Content-ID: whereami@invalid

[xml stuff goes here]
--boundary1--