Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 20 Oct 2009 11:57:13 +0200

Hi,

Below are my comments on the feedback from John.

>1. I think the document would benefit from having a definition of Info 
>Package at some point early on. In section 1 we have "This document 
>defines a mechanism, using Info Packages, which provides the 
>possibility for UAs to indicate what INFO usages they support, and to 
>define content syntax and semantics for the data transported in the 
>INFO messages.", but that describes the mechanism, rather than defining
Info package. As a starter, how about something like:
>"A specified usage of the SIP INFO method, detailing the format and 
>semantics of information transported."

Sounds ok. Need to think where to put the text.

-----------

>2. In several places in the document (e.g., Abstract, section 1), it 
>talks about receiving Info Packages, but I think that is incorrect. 
>Shouldn't it really be worded along the lines of receiving information 
>within the context of an Info Package? (c.f., RFC 3265, where we don't
receive event packages in NOTIFY >requests, we receive events).

I guess an alternative is to talk about "receiving information
associated with an Info Package". It would be more words, though..

-----------

>3. Was there a reason why we decided to use "Recv-Info: nil" rather 
>than simply "Recv-Info:" if not willing to receive?

There was a discussion about that at some point, but I don't remember
the details. At the end of the day, I assume it's just a beauty contest.

I agree an empty header would maybe be more aligned with how we use
other headers, though.

-----------

>4. Although much of the document talks about INFO within the context of

>an invite dialog usage, there are many places that mention session, 
>which seems inconsistent. Session is used early in section 1, but that 
>is probably reasonable, as it describes the basic capability of SIP. 
>However, later we have "INFO messages are always part of, and share the

>fate of, an invite dialog usage.  INFO message can not be sent as part 
>of other dialog usages, and they can not be sent outside an existing
session."
>I cannot rationalise this mixture of invite dialog usage and session in

>the same sentence. In this particular case, I don't see what value "and

>they can not be sent outside an existing session" adds.

I will remove that particular sentence, and I will try to make the usage
of dialog versus session more consistent.

-----------

>Then later:
>"which Info Packages it is willing to receive, on a per-session basis"
>and
>"during the lifetime of the invite dialog usage of the session"
>What is "dialog usage of the session"?

I changed to "on a per-dialog basis" and removed "of the session".

-----------

>And so on. We should decide whether to talk about INFO being used in
the context of a session or of an invite dialog usage and use that
terminology consistently.

I agree. As you said, there may be places where session IS more
appropriate, but generally I think we should talk about dialogs.

-----------

>5. I think it has already been questioned why we use Recv-Info in a 
>REGISTER request. Forking decisions are based on RFC 3840 UA 
>capabilities, and if decisions need to be made based on Info Package 
>support, we should extend that mechanism. Also, the semantics of 
>Recv-Info are that it indicates packages it is willing to receive. The 
>presence of a package in Recv-Info in an INVITE request does NOT convey

>any meaning about wanting to select a UAS that can receive that same
package.

See separate thread.

-----------

>6. In the example in 3.6:
>"Since the UAS does not support Info Package P, the UAC decides to 
>indicate in the ACK request that it is only willing to receive Info 
>Package R, which the UAS also indicated support of."
>Whilst this is certainly legitimate behaviour (a UA can change its mind
about >what it wishes to receive at any time), isn't there a danger with
this example >of implying that a UA should limit what it is prepared to
receive to what the >peer UA has indicated it is willing to receive? I
don't think this aspect of the >example is particularly helpful.

I was thinking about the same thing when I re-wrote the document.

I removed the "limit stuff" from the ACK. 

In addition, I've moved the example to section 10, as you requested in
another comment.

-----------

>7. In 4.2: "If a UA receives an INFO
>request outside an existing dialog, the UA MUST response with a 481 
>Call Does Not Exist error response."
>What if INFO request is received within the context of a dialog but a 
>dialog for which there is no invite usage?
>But I see that is covered in 4.4. Shouldn't both conditions be covered 
>in 4.4, rather than one in 4.2 and the other in 4.4?

Yes. I moved the particular sentence from 4.2 to 4.4.

-----------

>8. In 4.3: "The application data associated with an Info Package SHOULD

>be carried as a payload in the message body of the INFO request, unless

>the information can be retrieved from a SIP header field."
>I don't remember discussing this exception. What sort of thing do we
have in >mind?

The idea is that if there is an existing header field which can be used
to carry information associated with an Info Package, that header field
can be used - it is not mandatory to send the same information in the
message body.

A simple example is when the application needs information on what time
the INFO request was sent. I believe that information can be carried in
a header filed, so the information does not need to be in the message
body.

-----------

>9. In 4.3 "In that case, if multipart MIME is used, the UA does not 
>need to insert an 'Info-Package' header value for the individual body
parts."
>Does this mean it doesn't need to have a Content-Disposition header 
>field associated with individual body parts?

The specifications for the individual body parts (some of which may of
course be defined as part of the particular Info-Package specification)
shall define how/if C-D is used for those body parts. The Info Package
mechanism as such does not change those rules.

-----------

>10. In 4.4 "If a UA receives an INFO request, that carries a message 
>body that the UA does not support, and support of the message body is 
>required in the Content-Disposition header field, the UA MUST send a 
>415 Unsupported Media Type response.  If support of the message body is

>optional, the UA MUST send a 200 OK response even if the UA does not 
>support the message body."
>I am confused. In 4.3 it says that Content-Disposition has the value
"Info->Package", so how can it indicate support required/not required?
>In addition, this paragraph should cover body parts, not just bodies.

You can also have a handling parameter in C-D, which indicates whether
support is required or not.

However, I think the paragraph is just copying normal SIP procedures, so
I think we can remove it.

-----------

>11. In 5.2, why is Recv-Info allowed in NOTIFY request/response and in
REFER >request? These doesn't related to invite dialog usages.

See separate thread.

-----------

>12. In 5.2.2 "This document adds Recv-Info to the definition of the 
>element "general-header" in the SIP [RFC3261] message grammar"
>I can't find "general-header" in RFC 3261.

It shall be message-header, as for the Info-Package header field.

-----------

>13. In section 6 "An INFO request associated with an Info Package MUST
>contain a Info-Package header field."
>Since section 6 deals with "Legacy INFO Usage", this is not the place
to make >a normative statement concerning Info Packages. Instead it
would be >acceptable to mention what is mandated elsewhere (section 4).

The reason for the sentence is to really point out the difference
between a legacy INFO request and a I-P INFO request. 

But, I can modify the text related to Info Package usage to become less
normative:

"As described in section 4, an INFO request associated with an Info
Package always contains an Info-Package header field. A legacy INFO
request MUST NOT contain an Info-Package header field."

-----------

>14. In section 7.7 "If Info Package restrictions are violated (i.e. if 
>overlapping INFO requests are not allowed for an Info Package, but a UA

>still receives overlapping requests), the UA MUST NOT reject such
requests. "
>This is in the section on Info Package Usage Restrictions. Such a 
>normative statement on UA behaviour should occur in section 4. It can 
>then be mentioned (informatively) in 7.7.

I re-wrote the paragraph in a less normative way:

"As the SIP stack may not be aware of Info Package specific
restrictions, it cannot be 
assumed that overlapping requests would be rejected. As defined in
section 4.4, in most cases 
a 200 OK response will be sent for the INFO request. The application
logic associated with the 
Info Package needs to handle situations which can occur due to
overlapping requests."

-----------

>15. "5.2.2.  Recv-Info header field"
>This occurs within section 5 "Formal INFO method definition", but has 
>nothing to do with the INFO method.
>Furthermore, I am not keen on the separation between the method and 
>header field descriptions in 5 and the ABNF for these in section 8. 
>Maybe 8 could be moved to directly after 5.

I moved section 8 after 5.

In addition, I changed section 5.2 into a new section 6, to separate the
method definition from the header field definitions.

-----------

>16. In 9.5: "Please add the following registration to the 
>Content-Disposition registry.  The description suitable for the IANA
registry is as follows.
>The payload of the message carrying this Content-Disposition header 
>field value is the payload of an Info Package"
>This text fails to state the value that is being registered.

I re-wrote the section:

"Please add the following new header field value to the
Content-Disposition registry.

Name: info-package
Description: the body contains information associated with an Info
Package
Reference: RFCXXXX"

-----------

>17. Section 10 gives examples of the INFO method, whereas section 3.6
gives an example of the Recv-Info header field.
>It would make sense either to have all examples in one place or to have
all examples in the sections to which they relate.

I moved all examples to Section 10.

-----------

18. "11.  Modifications to SIP Change Process"
This is a strange title. The contents look like they constitute a
Security Considerations section.

I think this is old text which was useful in the justification phase,
but is not needed anymore. 
I will take a second look at it, possible move something to the Security
Considerations section, 
and remove the rest of the section.

Maybe some text can also be put in the introduction of the document,
where we describe the advantage of using Info Packages.

-----------

>19. In B.2: "QSIG uses Content-Type to identify QSIG protocol elements
in an 
>INFO message.  See RFC4497 [RFC4497]."
>I am sure I made this comment before. RFC 4497 does NOT cover the 
>conveyance of QSIG in INFO (it covers interworking between SIP and
QSIG). 
>The conveyance of QSIG in INFO is covered by Standard ECMA-355 (the
IETF never adopted this work).

Ok, so I guess we'll need to replace the RFC reference with the ECMA
reference.

-----------

>20. In 4.1 "It also describes how an UA can indicate support of Info
Packages in OPTIONS requests and during registration."
>Wasn't this already described in section 3?

I removed the sentence from 4.1.

-----------

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 20 Oct 2009 12:50:54 +0200

Hi,

Just a small correction.

The "Modifications to SIP Change Process" section IS the "Security
Considerations" section, and will be renamed. Nothing will be thrown
away. I was looking at the wrong section...

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 20. lokakuuta 2009 12:57
> To: Elwell, John; SIPCORE
> Cc: Adam Roach; Gonzalo Camarillo; 
> [email-masked]
> Subject: Re: [sipcore] WGLC comments 
> (draft-ietf-sipcore-info-events-01) -John E's comments
> 
> 
>  
> Hi,
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 20 Oct 2009 14:56:58 +0200

Christer,

Thanks for addressing my tedious comments. Just a few further remarks below. I cut out the comments we agree on.

> associated with an Info Package". It would be more words, though..
[JRE] Yes, that would work, but I am open to suggestions to shorten it, as long as we don't resort to inaccurate formulations like we have at present.

> a header filed, so the information does not need to be in the message
[JRE] Sounds like a layer violation to me. Suppose a particular application needs date/time, but the info-package decides to omit it on the basis that the Date header field will convey this information. The application passes the info down to the SIP stack, and expects the SIP stack to know that for this particular info-package it must include the Date header field. Sounds like it would be safer to include in the info anyway. Similarly, at the UAS, the SIP stack would need to pass the contents of the received Date header field up to the application.

Also, what if the application data can be carried over transports other than SIP, and in particular needs to be passed on transparently when SIP interworks with some other transport (e.g., PSTN UUI)? Can it rely on that other protocol also having date/time (or whatever other information is conveyed in the SIP header), and can it rely on correct interworking at the gateway?

I would prefer to keep it simple and say all application information associated with a package be carried in a body part.

[JRE] Having re-read the paragraphs concerned, I withdraw my original comment. However, just for clarification, can you confirm or deny the following?
If I have multi-part, and all parts relate to info-package(s), I just need Content-Disposition: Info-Package at the SIP level and not in the individual body parts. Since an INFO request is allowed to contain only one info-package, this case would apply only when a single info-package requires 2 or more body parts. I suspect we probably discussed this at some point in the past, and if we agreed on this possibility, then fine - I don't want to open it up again. However, we should perhaps take a careful look at the wording of 7.6:
"The Info Package specification MUST define what type of message
   bodies, if any, are associated with the Info Package, and MUST refer
   to specifications where the syntax, semantics and MIME type of the
   message body is described."
It says "bodies" in the first part and "body" in the second part. Also it should allow for body parts.

> REFER >request? These doesn't related to invite dialog usages.
[JRE] I couldn't find any discussion of Recv-Info in REFER and NOTIFY. Can you point me at a particular message in that thread?

John

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Oct 2009 11:42:08 -0400

> It says "bodies" in the first part and "body" in the second part. Also it should allow for body parts.

My take on this is that an info-package must consist of a single body 
part in the INFO message, which itself may be a multipart. This can 
occur two ways:

1) it is the entire body of the INFO message. The C-D in the sip message 
is Info-Package.

2) the INFO message contains a multipart/mixed body which contains, as 
one of its immediately contained parts, a part with C-D Info-Package.

In either case, the type and other rules regarding the part with C-D 
Info-Package is subject to specification by the definition of the 
individual package type.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 20 Oct 2009 18:41:06 +0200

Paul,

Your explanation sounds reasonable. I think it requires some clarification in both 7.6 and 4.3:
- in 7.6 it should talk about a body part, which may be multipart;
- in 4.3 it should talk about labelling the Info-Package body part with Content-Disposition: Info-Package, this being at the SIP level if it is the sole body part (i.e., the entire body of the SIP message).

John

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 20 October 2009 16:42
> To: Elwell, John
> Cc: Christer Holmberg; SIPCORE; Adam Roach; Gonzalo 
> Camarillo; [email-masked]
> (draft-ietf-sipcore-info-events-01) - John E's comments
> 
> 
> 
> Elwell, John wrote:
> 
> > If I have multi-part, and all parts relate to 
> info-package(s), I just need Content-Disposition: 
> Info-Package at the SIP level and not in the individual body 
> parts. Since an INFO request is allowed to contain only one 
> info-package, this case would apply only when a single 
> info-package requires 2 or more body parts. I suspect we 
> probably discussed this at some point in the past, and if we 
> agreed on this possibility, then fine - I don't want to open 
> it up again. However, we should perhaps take a careful look 
> at the wording of 7.6:
> > It says "bodies" in the first part and "body" in the second 
> part. Also it should allow for body parts.
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 20 Oct 2009 20:53:20 +0200

Hi, 

>>>Shouldn't it really be worded along the lines of receiving
>>>information within the context of an Info Package? (c.f., RFC 3265,
>>>where we don't receive event packages in NOTIFY >requests, we receive
events).
>[JRE] Yes, that would work, but I am open to suggestions to shorten it,
as long as we don't resort to inaccurate formulations like we have at
present.

Or, we could somewhere in the beginning of the document clarify that
"receive Info Package" means to receive an INFO associated with an Info
Package, or something like that...

---------

>>>8. In 4.3: "The application data associated with an Info
>>>Package SHOULD be carried as a payload in the message body of the
INFO
>>>request, unless the information can be retrieved from a SIP header
field."
>>>have in mind?
>>The idea is that if there is an existing header field which can be 
>>used to carry information associated with an Info Package, that header

>>field can be used - it is not mandatory to send the same information 
>>in the message body.
>> 
>>A simple example is when the application needs information on what 
>>time the INFO request was sent. I believe that information can be 
>>carried in a header filed, so the information does not need to be in 
>>the message body.
>[JRE] Sounds like a layer violation to me. Suppose a particular
application needs date/time, but the info-package decides to omit it on
the basis that the Date header field will convey this information. 
>The application passes the info down to the SIP stack, and expects the
SIP stack to know that for this particular info-package it must include
the Date header field. Sounds like it would be safer to 
>include in the info anyway. Similarly, at the UAS, the SIP stack would
need to pass the contents of the received Date header field up to the
application.

Well, maybe should clarify, and say unless the APPLICATION is able to
convey the information in an existing header. But, I guess the problem
then is that all stacks/APIs may not give access to all headers, and the
Info Package should of course not be stack/API specific.

Of course, there are some MANDATORY SIP headers which the application
can assume will be present, but I doubt any of those headers would carry
very much information of interest for the application.

>Also, what if the application data can be carried over transports other
than SIP, and in particular needs to be passed on transparently when SIP
interworks with some other transport (e.g., PSTN UUI)? Can 
>it rely on that other protocol also having date/time (or whatever other
information is conveyed in the SIP header), and can it rely on correct
interworking at the gateway?
>
>I would prefer to keep it simple and say all application information
associated with a package be carried in a body part.

Personally I have no problem with that.

That of course means that the INFOs will always carry a message body. In
reality that would probably be the case anyway, but the intention was to
allow also body-free INFOs.
 
-----------

parts."

>[JRE] Having re-read the paragraphs concerned, I withdraw my original
comment. However, just for clarification, can you confirm or deny the
following?
>If I have multi-part, and all parts relate to info-package(s), I just
need Content-Disposition: Info-Package at the SIP level and not in the
individual body parts.
>
>
>Since an INFO request is allowed to contain only one info-package, this
case would apply only when a single info-package requires 2 or more body
parts. I suspect we probably discussed this at some point 
>in the past, and if we agreed on this possibility, then fine - I don't
want to open it up again. However, we should perhaps take a careful look
>It says "bodies" in the first part and "body" in the second part. Also
it should allow for body parts.

I'll address this in my reply to your reply to Paul's reply :)

--------

>>>REFER request? These doesn't related to invite dialog usages.
>> 
>>See separate thread.
>[JRE] I couldn't find any discussion of Recv-Info in REFER and NOTIFY.
Can you point me at a particular message in that thread?

Sorry, I didn't mean that there was a separate thread dedicated to that
particular issue. But, Robert had the same comment, and I addresses it
in my of my replies on his comments.

But, I HAVE removed Recv-Info from REF and NOT, because I can't remember
why they were put there.

ANYONE WHO REMEMBERS WHY THEY WERE PUT THERE, PLEASE SPEAK NOW OR
FOREVER SEND YOUR REFERS WITHOUT INFO PACKAGES! :)

-------

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 20 Oct 2009 21:06:53 +0200

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: 20 October 2009 19:53
> Cc: Gonzalo Camarillo; Adam Roach; 
> Subject: RE: WGLC comments 
[JRE] If this would make the document more readable (in terms of avoiding long formulations in many places in the document), it would at least be an improvement on what we have at present.

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 20 Oct 2009 21:45:52 +0200

Hi,

>- in 7.6 it should talk about a body part, which may be multipart;

7.6 shall definitely be changed. It should say "body parts".

"7.6.  INFO Message Body

The Info Package specification MUST define what type of message
body parts, are associated with the Info Package, and MUST refer
to specifications where the syntax, semantics and MIME type of each
message body part is described."

- The old text used to say "message bodies, if any", but I removed "if
any" due to the change that the Info Package shall not assume on
information being conveyed in SIP headers (see other e-mail).

-------------

>- in 4.3 it should talk about labelling the Info-Package body part with
Content-Disposition: Info-Package, this being at the SIP level if it is
the sole body part (i.e., the entire body of the SIP 
>message).

Yes. Basically the text shall say that each message body part associated
with the Info Package shall have a associated C-D header filed with an
'info-package' value. And, if there is only a single body part in a
message the SIP level C-D header field contains the 'info-package'
value.

Also, 4.3 talks about "message body payloads", but I will change to
"message body parts" there, to be consistent with 7.6.

NOTE: The new 4.3 text below may also contain changes I've already done
based on other comments:

"4.3.  INFO Request Message Body

   The purpose of the INFO request is to carry application level
   information between SIP UAs. The application data associated with an
   Info Package is carried as a payload in the message body of
   the INFO request. 

   An INFO request message body can contain a single body part, or
multiple 
   body parts (multipart/mixed).

   Info Package specifications MUST describe the application level
   information associated with the Info Package. Message body parts
   MUST have a MIME type value defined.

   If a UA indicates that it is willing to receive a specific Info
   Package, it means that the UA also supports any associated message
   body MIME type associated with the Info Package.  However, the UA
   MUST still indicate support of those MIME types also in the Accept
   header field, according to the procedures in [RFC3261].

   Some SIP extensions that are orthogonal to INFO MAY insert body parts
   unrelated to the Info Package. UAs MUST conform to [RFC3261] as
   updated by body-handling [I-D.ietf-sip-body-handling] to support
   multipart MIME handling.

   Each message body part associated with an Info Package MUST
   contain a Content-Disposition header field with an 'Info-Package'
   value, in order to in an easy way distinguish payloads associated
   with the Info Package from other payloads. 

   If the message body only contains a single body part, the SIP level
Content-Disposition header field
   contains an 'info-package' value.

   If the message body contains multiple body parts (multipart/mixed)
the SIP level Content-Disposition header field
   does not need to include an 'info-package' value, since each body
part associated with the Info Package will include
   a Content-Disposition header field for that specific body part.

   NOTE: To avoid corner cases with legacy INFO usage, the Info-Package
   header field is used to indicate the Info Package name, rather than
   to use a Content-Disposition header field parameter in order to
   indicate the name."

-------------

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Oct 2009 15:59:11 -0400

Christer,

It sounds like we may have different conceptions of how body parts might 
be strung together for this.

If I read your text below correctly, then it would be possible for the 
INFO message to have a multipart mixed body, where some body parts are 
not part of the info package (authentication stuff, geoloc stuff), but 
where one *or more* other parts are considered part of the info package.

It was my thinking that there will always be *one* body part that is the 
root of all stuff that is associated with the info package. In the 
simplest case this would be the whole body of the message, containing 
for example DTMF info. In a slightly more complicated case it might be 
that same DTMF body, but as one body part in a multipart/mixed, where 
the other body parts are for incidental purposes but not part of the 
info package.

In cases where the info package itself needs more than one body part, it 
would consist of a multipart containing all of its pieces. Then that 
multipart would be just as above - either the only thing in the message, 
or else it would be a multipart within a multipart, along with other 
incidental parts.

I think that is different from what you are saying.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 20 Oct 2009 22:15:58 +0200

Hi, 

>It sounds like we may have different conceptions of how body parts
might be strung together for this.
INFO message to have a multipart mixed body, where some body parts are
not part of the info package (authentication stuff, geoloc 
>stuff), but where one *or more* other parts are considered part of the
info package.

Section 4.3 talks about "SIP extensions that are orthogonal to INFO MAY
insert body parts unrelated to the Info Package". 

Personally, though, I doubt that someone would say "Hey, someone is
about the send an INFO, so I'll throw in my message body part there
too!". I think that any application who wants to send an INFO (no matter
whether it's legacy of I-P based, should trigger a dedicated INFO, and
not try to get a "free ride" by someone else...

>It was my thinking that there will always be *one* body part that is
the root of all stuff that is associated with the info package. In the
simplest case this would be the whole body of the message, 
>containing for example DTMF info. In a slightly more complicated case
it might be that same DTMF body, but as one body part in a
multipart/mixed, where the other body parts are for incidental purposes 
>but not part of the info package.

Personally I agree with you, but the text has been there for a while
already. If people want to remove it, though, I am happy to do it.

>In cases where the info package itself needs more than one body part,
it would consist of a multipart containing all of its pieces. Then that
multipart would be just as above - either the only thing in 
>the message, or else it would be a multipart within a multipart, along
with other incidental parts.

Just to make sure: even if we say that all body parts must be associated
with the Info Package, do you agree that they ALL still shall have a C-D
with 'info-package'? Otherwise parsers may assign whatever the default
C-D value is for them, and we don't want that to happen...

Regards,

Christer

Christer Holmberg wrote:
> The Info Package specification MUST define what type of message body 
> parts, are associated with the Info Package, and MUST refer to 
> specifications where the syntax, semantics and MIME type of each 

> Content-Disposition: Info-Package, this being at the SIP level if it 
> is the sole body part (i.e., the entire body of the SIP
>> message).
> 
> Yes. Basically the text shall say that each message body part 
> associated with the Info Package shall have a associated C-D header 
> filed with an 'info-package' value. And, if there is only a single 
> body part in a message the SIP level C-D header field contains the
'info-package'
> NOTE: The new 4.3 text below may also contain changes I've already 
> done based on other comments:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Oct 2009 16:50:04 -0400

> not try to get a "free ride" by someone else...

The way I envision this might happen would be because of some optional 
header inserted in the message that has a reference to a body part, via 
a cid: url. I guess INFO can't have Alert-Info, but if it could then 
that would be one example.

Another example might be an AIB body.

Most are pretty far fetched for INFO, but we should not exclude the 
possibility.

> already. If people want to remove it, though, I am happy to do it.

The way that C-D works means that technically you *could* have multiple 
parts with C-D of info-pkg. The question is whether there is any value 
in making it legal. If so then somebody has to define what it means. 
Since we have multipart which already has lots of ways to group parts, 
why do we need to introduce yet another grouping mechanism here?

> C-D value is for them, and we don't want that to happen...

NO, I don't agree.

These are nested structures. They may come from some other place and be 
formed and processed by non-sip code that knows nothing of info-pkg. 
Once you unwrap the first box, I think you should be allowed to have 
whatever you want inside.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Oct 2009 16:55:28 -0500

[individually]

On 10/20/09 15:50, Oct 20, Paul Kyzivat wrote:
> The way that C-D works means that technically you *could* have 
> multiple parts with C-D of info-pkg. The question is whether there is 
> any value in making it legal. If so then somebody has to define what 
> it means. Since we have multipart which already has lots of ways to 
> group parts, why do we need to introduce yet another grouping 
> mechanism here?

I agree with Paul -- the myriad MIME multipart types are pretty much 
infinitely flexible. I think the correct way to nail this down is to 
mandate that an INFO contains exactly one or zero parts with a C-D of 
info-pkg. While this does need to be flexible, I can't imagine any level 
of flexibility that MIME doesn't currently provide.

Above all, we really don't want to make how INFO uses MIME any more 
complicated than necessary.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Oct 2009 07:15:02 +0200

Hi, 

>>multiple parts with C-D of info-pkg. The question is 
>>whether there is any value in making it legal. If so then somebody has
to 
>>define what it means. Since we have multipart which already has lots
of ways to 
>I agree with Paul -- the myriad MIME multipart types are 
>pretty much infinitely flexible. I think the correct way to 
>nail this down is to mandate that an INFO contains exactly 
>one or zero parts with a C-D of info-pkg. While this does 
>need to be flexible, I can't imagine any level of flexibility 
>that MIME doesn't currently provide.
> 
>Above all, we really don't want to make how INFO uses MIME 
>any more complicated than necessary.

I don't see what the problem is in allowing multiple body parts with C-D
'info-package'. In most real-life cases I think there will be only one
'info-package' body part in any case.

1. Assume that we have a multipart/mime which contains only I-P parts,
and define C-D 'info-package' for that multipart/mime. Does that
automatically give C-D 'info-package' to all body parts within that
multipart/mime? Or, will they be assigned whatever default value?

2. Assume a UA sends an INFO with multipart/mime, which contains a
number of body parts. Then someone wants to insert a non-I-P body part.
How can we ensure that "someone" won't insert that non-I-P body part
within the same multipart/mime which contains the I-P stuff? How can we
ensure that "someone" will move the existing multipart/mime body, with
the I-P stuff, into a second level multipart/mime?

So, I think there is no problem in allowing multiple body parts with C-D
'info-package'. It causes no problem for the SIP stack, and the
application will deal with it.

Please also remember that we only allow an INFO request to be associated
with a single Info Package, so one will always know that all body parts
with C-D 'info-package' are associated with the package indicated in the
Info-Package header.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Oct 2009 07:16:30 +0200

Hi, 

>>Section 4.3 talks about "SIP extensions that are orthogonal to INFO 
>> MAY insert body parts unrelated to the Info Package".
>> 
>>too!". I think that any application who wants to send an INFO (no 
>>matter whether it's legacy of I-P based, should trigger a dedicated 
>>INFO, and not try to get a "free ride" by someone else...
> 
>The way I envision this might happen would be because of some 
>optional header inserted in the message that has a reference 
>to a body part, via a cid: url. I guess INFO can't have 
>Alert-Info, but if it could then that would be one example.
>
>Most are pretty far fetched for INFO, but we should not 
>exclude the possibility.

Good, so we keep the text.

I'll address the multipart/mime issue in my reply to Adam's reply to
your reply.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Oct 2009 08:37:43 +0200

Christer,

I tend to agree with Paul, and this is the text I would propose:

For 7.6:
"The Info Package specification MUST define what type of 
body part is associated with the Info Package, and MUST refer
to specifications where the syntax, semantics and MIME type of that 
body part (and, if multipart/mixed, any child body parts) are described." 

For 4.3:
"The purpose of the INFO request is to carry application level information between SIP UAs. The application data associated with an Info Package is carried as a body part in the message body of the INFO request. This body part is identified by a MIME type, which can be multipart/mixed, in which case the body part has child body parts. In accordance with section 7.6, the Info Package specification defines the type of body part.

An INFO request message body can contain just the body part associated with the Info Package, or this body part along with other body parts (not related to the Info Package but relating to other SIP extensions) in a message body of type multipart/mixed.

If a UA indicates that it is willing to receive a specific Info Package, it means that the UA also supports the associated body part MIME type associated with that Info Package.  However, the UA MUST still indicate support of that MIME type, and any child MIME types, in the Accept header field, according to the procedures in [RFC3261].

UAs MUST conform to [RFC3261], as updated by body-handling [I-D.ietf-sip-body-handling], to support multipart MIME handling.

The body part associated with the Info Package MUST contain a Content-Disposition header field with value 'Info-Package', in order easily to distinguish payloads associated with the Info Package from other payloads. If the message body only contains the single body part associated with the Info-Package, the SIP level Content-Disposition header field MUST contain value 'Info-Package'. If the message body is of type multipart/mixed, the child body part associated with the Info-Package MUST include a Content-Disposition header field with value 'Info-Package'. Child body parts of a multipart/mixed body part associated with the Info-Package do not require this Content-Disposition value.

NOTE: To avoid corner cases with legacy INFO usage, the Info-Package header field is used to indicate the Info Package name, rather than using a Content-Disposition header field parameter in order to indicate the name."

How does this sound?

John

> Sent: 20 October 2009 21:50
> To: Christer Holmberg
> Cc: Elwell, John; SIPCORE; Adam Roach; Gonzalo Camarillo; 
> (draft-ietf-sipcore-info-events-01) - John E's comments - 
> non-I-P body parts in INFO?
> 
> 
> 
> Christer Holmberg wrote:
> > Hi, 
> > 
> optional 
> >>> - in 4.3 it should talk about labelling the Info-Package 
> body part 
> >>> with
> >>    information between SIP UAs. The application data 
> associated with
> > an

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Oct 2009 09:52:18 +0200

Hi, 

>"The Info Package specification MUST define what type of body 
>part is associated with the Info Package, and MUST refer to 
>specifications where the syntax, semantics and MIME type of 
>that body part (and, if multipart/mixed, any child body 
>parts) are described." 

I don't understand the child body thing. A specific body part looks the
same no matter whether it is included in a multipart (as a child body
part) or not.

>For 4.3:
>"The purpose of the INFO request is to carry application 
>level information between SIP UAs. The application data 
>associated with an Info Package is carried as a body part in 
>the message body of the INFO request. This body part is 
>identified by a MIME type, which can be multipart/mixed, in 
>which case the body part has child body parts. In accordance 
>with section 7.6, the Info Package specification defines the 
>type of body part.
>
>An INFO request message body can contain just the body part 
>associated with the Info Package, or this body part along 
>with other body parts (not related to the Info Package but 
>relating to other SIP extensions) in a message body of type 
>multipart/mixed.
>
> 
>If a UA indicates that it is willing to receive a specific 
>Info Package, it means that the UA also supports the 
>associated body part MIME type associated with that Info 
>Package.
>
>However, the UA MUST still indicate support of that 
>MIME type, and any child MIME types, in the Accept header 
>field, according to the procedures in [RFC3261].
> 
>UAs MUST conform to [RFC3261], as updated by body-handling 
>[I-D.ietf-sip-body-handling], to support multipart MIME handling.
> 
>The body part associated with the Info Package MUST contain a 
>Content-Disposition header field with value 'Info-Package', 
>in order easily to distinguish payloads associated with the 
>Info Package from other payloads. If the message body only 
>contains the single body part associated with the 
>Info-Package, the SIP level Content-Disposition header field 
>MUST contain value 'Info-Package'. If the message body is of 
>type multipart/mixed, the child body part associated with the 
>Info-Package MUST include a Content-Disposition header field 
>with value 'Info-Package'. Child body parts of a 
>multipart/mixed body part associated with the Info-Package do 
>not require this Content-Disposition value.

The beginning of the last paragraph says that the C-D header is used to
distinguish the body parts associated with the Info Package. So, I am
still wondering why we, if there are non-I-P body parts, in addition
would need to encapsulate the body parts (if many) associated with the
Info Package into a multipart/mixed.

BUT, assuming we would go that way, I would still like to get some
clarification on the questions I had related to that:

-----------

1. If we only indicate C-D 'info-package' for the multipart/mixed body
part, but not for the child body parts, what C-D value will the child
body parts get? Do they automatically get the same 'info-package' value
as the "parent" (the multipart/mixed body part)? My understanding of RFC
5621 is that they do NOT automatically get the same value - they will
get the default value, which for SIP is "render" (excluding app/sdp).

Section 8.2 of RFC 5621 says:

"The way the body parts within the 'multipart/mixed' are handled depends
on the disposition types of
the individual body parts.  The actual disposition type of the whole
'multipart/mixed' is irrelevant."

So, we would anyway need to indicate C-D 'info-package' for each body
part associated with the Info Package...

-----------

2. How can we prevent someone who inserts a non-I-P body part from
inserting it into the same multipart/mixed body part which contains the
I-P children?

-----------

Also, I think we would be able to make the last paragraph more simple,
but let's focus on the technical stuff first.

Regards,

Christer

> NOTE: To avoid corner cases with legacy INFO usage, the 
> Info-Package header field is used to indicate the Info 
> Package name, rather than using a Content-Disposition header 
> field parameter in order to indicate the name."
> 
> How does this sound?
> 
> John
> 
> 
> > header inserted in the message that has a reference to a body part, 
> > via a cid: url. I guess INFO can't have Alert-Info, but if it could 
> > then that would be one example.
> > 
> whether there is 
> > it means.
> > These are nested structures. They may come from some other 
> place and 
> > be formed and processed by non-sip code that knows nothing of 
> > info-pkg.
> > >>    Some SIP extensions that are orthogonal to INFO MAY 
> insert body
> > > parts

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Oct 2009 13:35:42 +0200

Hi John,
 
>Sounds ok. Need to think where to put the text.

I rewrote the paragraph:

"This document defines a mechanism, using Info Packages. 
An Info Package defines the content and semantics of an INFO usage.
The Info Package mechanism also provides a way for UAs to indicate for 
which INFO usages they are willing to receive INFO requests. This
document defines the usage of the SIP INFO method, new SIP header fields
for the
Info Package mechanism, and how to transport payload information
associated 
with an Info Package in INFO requests.
   
The mechanism is allows existing legacy INFO usages as defined in RFC
2976."

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Oct 2009 13:42:15 +0200

Hi,
 
>>>2. In several places in the document (e.g., Abstract, 
>>>section 1), it talks about receiving Info Packages, but I think that
is 
>>>incorrect. Shouldn't it really be worded along the lines of receiving
>>>where we don't receive event packages in NOTIFY >requests, 
>>>we receive events).
>>> 
>>>[JRE] Yes, that would work, but I am open to suggestions to 
>>>shorten it, as long as we don't resort to inaccurate formulations
like 
>>>we have at present.
>>"receive Info Package" means to receive an INFO associated 
>>with an Info Package, or something like that...
>[JRE] If this would make the document more readable (in terms 
>of avoiding long formulations in many places in the 
>document), it would at least be an improvement on what we 
>have at present.

What about if we talked about "indicating for which Info Packages a UA
is willing to receive INFO requests"?

Then it is more clear that the user does not receive an Info Package,
bur rather an INFO request associated with an Info Package.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Oct 2009 14:47:42 +0200

> Sent: 21 October 2009 12:36
> Subject: RE: [sipcore] WGLC comments 
> (draft-ietf-sipcore-info-events-01) -John E's comments - Introduction
> 
>  
> Hi John,
>  
[JRE] We have two different usages of the word "usage" in this paragraph. "An INFO usage" near the start, which I think is intended to be a usage defined by an Info Package, and "usage of the SIP INFO message" later, which is what is defined in this document. We should at least avoid that. However, I have a bigger concern about the style of section 1, which I will raise in a new thread.

John

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Oct 2009 14:51:54 +0200

Yes 

> Sent: 21 October 2009 12:42
> receive Info-Package wording
> 
>  
> Hi,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Oct 2009 10:19:50 -0400

> 'info-package' body part in any case.

Mechanically there is no problem. The problem is defining what it means 
and how it should be processed.

Mechanically there is no problem with putting two body parts in an 
INVITE, both with C-D of "session" and C-T of application/sdp. But if 
you did that it would cause no end of grief.

> multipart/mime? Or, will they be assigned whatever default value?

No. Why does it matter?

What does it mean if I send a letter, addressed to you, and it 
*contains* other letters addressed to Adam and John? If I include no 
instructions saying what I expect you to do with them, then you will 
have to guess. Or I could include instructions saying "in the event of 
my death, send these". Or I could include instructions saying "read 
these letters that I was thinking of sending, and let me know what you 
think. Then destroy them." Or ...

I might have an Info Pkg that contains copies of old sip messages, which 
in turn might contain bodies with arbitrary C-D values.

> the I-P stuff, into a second level multipart/mime?

We should assume that they will do something reasonable, consistent with 
normal use of multipart in sip.

If the existing multipart has a C-D of info-pkg, then they should not be 
inserting something arbitrary into it. (Imagine what would happen if the 
existing body was a multipart/alternative and someone decided to stick 
their unrelated stuff into it.)

So in the case you describe they will have to:
- create a multipart/mixed
- insert the existing multipart into it as one part
- insert their new part into it.

If you are worried about this, then include text indicating that 
unrelated parts should not be inserted into a multipart with C-D of 
info-pkg. This out to be obvious, since the content of the info-pkg 
ought to be defined for the particular pkg type, and presumably won't 
include permitting these unrelated parts. But apparently it isn't 
obvious so documenting it would be a good thing.

> with C-D 'info-package' are associated with the package indicated in the

*If* this is allowed, then the specification for a particular info-pkg 
must specify if this is permitted and if so how it should be processed. 
That should be called out somewhere.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Oct 2009 10:44:25 -0400

> I tend to agree with Paul, and this is the text I would propose:

Good text, with a couple of tweaks below. My main concern is that the 
I-P body part may be any kind of multipart, not just multipart/mixed.

> "The purpose of the INFO request is to carry application level information between SIP UAs. The application data associated with an Info Package is carried as a body part in the message body of the…

In above, replace "multipart/mixed" with simple "multipart". Any kind of 
multipart could be applicable here.

> UAs MUST conform to [RFC3261], as updated by body-handling [I-D.ietf-sip-body-handling], to support multipart MIME handling.

Body-handling is now RFC 5621.

> The body part associated with the Info Package MUST contain a Content-Disposition header field with value 'Info-Package', in order easily to distinguish payloads associated with the Info Package fr…

Some slight rewording suggestions:

   ...
   If the message body is of type multipart/mixed,
* and the Content-Disposition is "render" or unspecified,
   the child body part associated with the Info-Package MUST include a
   Content-Disposition header field with value 'Info-Package'. Child body
* parts of a multipart body part associated with the Info-Package do not
*            ^^^^^^^^^^
   require this Content-Disposition value.

In the above I added "and the Content-Disposition is "render" or 
unspecified". I wish we had specified a specific C-D for the top level 
multipart that contains unrelated body parts in a sip message. Somehow 
that got missed in body-handling, though it would have been an issue for 
backward compatibility.

	Thanks,
	Paul

>> place and be 
>>> Info-Package

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Oct 2009 20:32:28 +0200

Hi, 

>>>>>multiple parts with C-D of info-pkg. The question is whether there 
>>>>>is any value in making it legal. If so then somebody has
>>>>>to define what it means. Since we have multipart which already has
lots
>>>>>of ways to group parts, why do we need to introduce yet another
grouping 

>>>info-pkg. While this does need to be flexible, I can't imagine any 
>>>level of flexibility that MIME doesn't currently provide.
>>>
>>I don't see what the problem is in allowing multiple body parts with 
>>C-D 'info-package'. In most real-life cases I think there will be only

>>one 'info-package' body part in any case.
>

The Info Package specification defines what each body part means, and
how it should be processes. That will have to be done even in the cases
where all I-P body parts are inside a multipart.

Not if you specified how to handle such cases, which is what an I-P
specification is supposed to do. 

And, you would end up with the same grief if you would put both the
"session" application/sdp body parts inside a multipart.

In addition, I think it is said somewhere that a message body must not
contain mutliple C-T application/sdp, so it could be considered a
protocol error.

-------------

>>multipart/mime? Or, will they be assigned whatever default value?

It does matter. The spec says that all I-P body parts shall have C-D
'info-package', so the parser shall not assign some other C-D value to
the I-P body parts. If they don't contain a C-D value, the parser may
assign "render", which is the default, which could confuse the
application...

my death, send these". Or I could include instructions saying "read
these letters that I was thinking of sending, and let me know 
>what you think. Then destroy them." Or ...

I am not sure I understand... Again, we say that I-P body parts shall
have C-D 'info-package', so I don't think we should say it is ok for the
parser to assign other C-D values to them...

-------------

>I might have an Info Pkg that contains copies of old sip messages,
which in turn might contain bodies with arbitrary C-D values.

Sure, but then those C-D values are part of the payload data of that
body - the C-D value of the body itself shall still be 'info-package'.

-------------

>>within the same multipart/mime which contains the I-P stuff? How can 
>>we ensure that "someone" will move the existing multipart/mime body, 
>>with the I-P stuff, into a second level multipart/mime?
>
>We should assume that they will do something reasonable, consistent
with normal use of multipart in sip.

What is reasonable, and where is it specified?

-------------

>If the existing multipart has a C-D of info-pkg, then they should not
be inserting something arbitrary into it. (Imagine what would happen if
the existing body was a multipart/alternative and someone 
>decided to stick their unrelated stuff into it.)

I can agree in the case of multipart/alternative, and personally I
think/agree it should be the same for all multiparts. But, unless it is
specified for multipart/mixed I am not sure we can assume that everyone
would have the same understanding.

-------------

We can put whatever text in the document, and I agree we could say
something about this. BUT, that is not the problem. The extra parts may
be inserted by existing entities/applications which do not support the
I-P mechanism.

-------------

>>So, I think there is no problem in allowing multiple body parts with 
>>C-D 'info-package'. It causes no problem for the SIP stack, and the 
>>Please also remember that we only allow an INFO request to be 
>>associated with a single Info Package, so one will always know that 
>>all body parts with C-D 'info-package' are associated with the package

>>indicated in the Info-Package header.
>
>That should be called out somewhere.

There is a chapter talking about body parts for a specific I-P. Maybe
some extra text could be added there. 

-------------

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Oct 2009 20:43:20 +0200

Hi, 

>
>For 7.6:
>"The Info Package specification MUST define what type of body part is 
>associated with the Info Package, and MUST refer to specifications 
>where the syntax, semantics and MIME type of that body part (and, if 
>multipart/mixed, any child body parts) are described."
> 
>For 4.3:
>"The purpose of the INFO request is to carry application level
information between SIP UAs. The application data associated with an
Info Package is carried as a body part in the message body of the INFO 
>request. This body part is identified by a MIME type, which can be
multipart/mixed, in which case the body part has child body parts. In
accordance with section 7.6, the Info Package specification 
>defines the type of body part.
>
>In above, replace "multipart/mixed" with simple "multipart". Any kind
of multipart could be applicable here.
>
>An INFO request message body can contain just the body part associated
with the Info Package, or this body part along with other body parts
(not related to the Info Package but relating to other SIP 
>extensions) in a message body of type multipart/mixed.
> 
Package, it means that the UA also supports the associated body part
MIME type associated with that Info Package.  However, the UA MUST still
indicate support of that MIME type, and any child MIME types, in the
Accept header field, according to the procedures in [RFC3261].
>Body-handling is now RFC 5621.

I'll fix the reference.

----------------

> The body part associated with the Info Package MUST contain a
Content-Disposition header field with value 'Info-Package', in order
easily to distinguish payloads associated with the Info Package from 
>other payloads. If the message body only contains the single body part
associated with the Info-Package, the SIP level Content-Disposition
header field MUST contain value 'Info-Package'. If the message 
>body is of type multipart/mixed, the child body part associated with
the Info-Package MUST include a Content-Disposition header field with
value 'Info-Package'. Child body parts of a multipart/mixed body >part
associated with the Info-Package do not require this Content-Disposition
value.
>"   If the message body is of type multipart/mixed,
>  require this Content-Disposition value."

I don't agree with that text. As I said earlier, RFC 5621 says that the
C-D value of the "parent body part" (C-T multipart) is IRRELEVANT to the
"child body parts" - they must explicitly be assigned individual C-T
values, or they will be assigned a default value. 

To use OOP language: a child body part does NOT inherit the C-D value of
its parent :)

So, therefor I don't think it really matters what the C-D value of the
parent body part is, because it does not affect the child body parts.

Regards,

Christer

	Thanks,
	Paul

header field is used to indicate the Info Package name, rather than
using a Content-Disposition header field parameter in order to indicate
the name."
>> (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P 
>> body parts in INFO?
>>
>>
>>
>> Christer Holmberg wrote:
>>> Hi,
>>>
>> optional header inserted in the message that has a reference to a 
>> body part, via a cid: url. I guess INFO can't have Alert-Info, but if

>> it could then that would be one example.
>>

>> Since we have multipart which already has lots of ways to group 
>> parts, why do we need to introduce yet another grouping mechanism 
>> here?
>>
>> These are nested structures. They may come from some other place and

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Oct 2009 20:45:42 +0200

Hi, 

>>>>1. I think the document would benefit from having a definition of 
>>>>Info Package at some point early on. In section 1 we have "This 
>>>>document defines a mechanism, using Info Packages, which provides 
>>>>the possibility for UAs to indicate what INFO usages they support, 
>>>>and to define content syntax and semantics for the data transported 
>>>>in the INFO messages.", but that describes the mechanism, rather 
>>>>than defining Info package. As a starter, how about something like:

>>document defines the usage of the SIP INFO method, new SIP header 
>>fields for the Info Package mechanism, and how to transport payload 
>>information associated with an Info Package in INFO requests.
>>    
2976."
>[JRE] We have two different usages of the word "usage" in this
paragraph. "An INFO usage" near the start, which I think is intended to
be a usage defined by an Info Package, and "usage of the SIP INFO 
>message" later, which is what is defined in this document. We should at
least avoid that. However, I have a bigger concern about the style of
section 1, which I will raise in a new thread.

I guess we could say "defines the cont and semnt of using the INFO
method", and only use "usage" in the context of legacy.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Oct 2009 21:32:15 +0200

> Sent: 21 October 2009 15:44
> To: Elwell, John
[JRE] I wasn't sure. I am happy to make that change.

> Package.  However, the UA MUST still indicate support of that 
> > The body part associated with the Info Package MUST contain 
> a Content-Disposition header field with value 'Info-Package', 
> unspecified". 
[JRE] But wouldn't that then conflict with the first of my proposed sentences? The first sentence says "The body part associated with the Info Package MUST contain a Content-Disposition header field with value 'Info-Package'". Your modified second sentence then seems to contradict it by saying only in certain circumstances does it need to do this.

John

> I wish we had specified a specific C-D for the 
> top level 
> exclude the

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Oct 2009 15:41:01 -0400

Inline, down aways.

> values, or they will be assigned a default value. 

Of course the child body parts don't *inherit" the C-D value.
But it doesn't matter. In this case it is the multipart itself that is 
the "payload" for the INFO message. Once it has been identified, and 
turned over to the application to process, *we don't care* what the C-D 
of the contained parts is.

What C-D values are relevant within there must be documented as part of 
the specific info-pkg documentation.

> parent body part is, because it does not affect the child body parts.

*If* you have a top level multipart/mixed that isn't C-D info-pkg (and 
is in fact without a C-D or has one of "render") then that will contain 
incidental parts of varying relevance to the message. In that case, if 
more than one of those is of C-D info-pkg, and if we determine that is 
valid, then fine - those are each passed to the application.

But if the whole body is of type C-D info-pkg, then it doesn't matter 
what C-T it is, or whether than is a multipart or not, it all goes to 
the application as the info package payload.

Lets imagine for the moment that we are designing a new info package, 
and it happens to need two distinct clumps of data - e.g. a piece of 
simple text and an xml file. How should the info package spec specify 
that data be encapsulated within the message? There seem to be a few 
ways to do this:

1) there should be a multipart/mixed, with C-D of info-pkg,
    that consolidates all the data.
    Within that are two parts:
    - one with C-T text/plain
    - one with C-T text/xml (or whatever)
    Each may have C-D that is appropriate to its intended use
    by the application, or let it default to "render".
    (What render means to an info package is a good question.)

2) same as (1) except the outer wrapper is multipart/related,
    and as a result the C-D of the subordinate parts is likely
    less important.

3) the body of the message is of C-T multipart/mixed, and the
    C-D is "render" or unspecified.
    Within that are two or more parts.
    One of those has C-T text/plain and C-D info-pkg.
    Another of those has C-T text/xml (or whatever) and
    C-D of info-pkg.
    None of the other direct children parts of the top level
    multipart have C-D of info-pkg.

I think that 1 and/or 2 are enough, and that there is no need to permit 
(3). I agree that (3) can work, but I just think that is unnecessarily 
confusing things.

It does seem that there is a fundamental difference of opinion here that 
needs to be sorted out. Can some other people chime in here?

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Oct 2009 21:54:35 +0200

> Sent: 21 October 2009 20:41
> To: Christer Holmberg
> body part is
> >> * parts of a multipart body part associated with the
> Info-Package do
> > not
> >> *            ^^^^^^^^^^
[JRE] I agree that (3) is an unnecessary complication. It is hard to imagine a situation that can't be accomplished by (1) or (2) (or a single part body, of course). In the interests of interoperability, limit the options where reasonable.

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Oct 2009 22:14:25 +0200

Hi, 

>>>other payloads. If the message body only contains the single body 
>>>part associated with the Info-Package, the SIP level
Content-Disposition 

>>>value 'Info-Package'. Child body parts of a multipart/mixed body
>part 
>>>associated with the Info-Package do not require this
Content-Disposition value.
>>I don't agree with that text. As I said earlier, RFC 5621 says that 
>>the C-D value of the "parent body part" (C-T multipart) is IRRELEVANT 
>>to the "child body parts" - they must explicitly be assigned 
>>individual C-T values, or they will be assigned a default value.
>
the "payload" for the INFO message. Once it has been identified, and
turned over to the application to process, *we don't care* what 
>the C-D of the contained parts is.

I don't agree. Eventhough I do hear what you are saying, in my opinion
"We don't care" goes against what we tried to fix with RFC 5621, and
could potentially cause problems. An Info-Package body part shall have
C-D 'info-package', and I don't like that fact that we should allow "any
value" to be assigned to a body part just because it is transported
within a multipart.

There is really no harm, and very little message overhead, in adding C-D
'info-package' for each body part. I think it is a "hack" by not doing
it - even if it would work well.

Body parts associated with Info Packages must have C-D 'info-package' -
nothing else.

-----------

>>To use OOP language: a child body part does NOT inherit the C-D value
of its parent :)

is in fact without a C-D or has one of "render") then that will contain
incidental parts of varying relevance to the message. In 
>that case, if more than one of those is of C-D info-pkg, and if we
determine that is valid, then fine - those are each passed to the
application.

Agree.

-----------

That may be true, but I still think it is wrong to send the wrong C-D
values to the application - no matter if it cares about them or not. It
is not specified in RFC 5621, and I have never heard about another usage
which act like that.

-----------

and it happens to need two distinct clumps of data - e.g. a piece of
simple text and an xml file. How should the info package spec 
>specify that data be encapsulated within the message? There seem to be
>    (What render means to an info package is a good question.)

If they are associated with the Info-Package, each body part should have
C-D 'info-pkg'. The I-P specification then says whether the application
use them for some rendering, or whatever. As far as the SIP protocol is
concerned, the body parts simply contain something beloning to the I-P.

-----------

I think the less confusing thing is to assign each body part a proper
C-D value :)

(I am not even sure what C-D for a multipart really means, since the
children will override it anyway (either explicitly or implicitly) but I
guess I will have to look it up.)

Regards,

Christer

>It does seem that there is a fundamental difference of opinion here
that needs to be sorted out. Can some other people chime in here?

> that got missed in body-handling, though it would have been an issue 
> for backward compatibility.
> 
> 	Thanks,
> 	Paul
> 
> using a Content-Disposition header field parameter in order to 
> indicate the name."
>> How does this sound?
>>
>> John
>>
>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Oct 2009 22:42:34 +0200

Hi, 

>> I think that 1 and/or 2 are enough, and that there is no need to 
>> permit (3). I agree that (3) can work, but I just think that is 
>> unnecessarily confusing things.
>[JRE] I agree that (3) is an unnecessary complication. It is hard to
imagine a situation that can't be accomplished by (1) or (2) (or a
single part body, of course). In the interests of interoperability, 
>limit the options where reasonable.

Maybe I don't get it, but I really think you are making things
complicated, for no reason, and will require extra if-then-else kind of
text. The Info-Package mechanism was supposed to be simple. I'm afraid
this would just make people continue to use legacy INFO...

In my opinon is is much easier to, in the base spec, simply say that
each body part (no matter where they are located, and no matter what C-D
value their parent may have) associated with an I-P must have C-D
'info-package'. Why does that not work??? 

THEN, IF a specific Info Package requries body parts to be "collected"
inside multiparts etc, that specific Info Package specification should
say so. For example, if an Info Package can be used to send
alternative-whatever-data, the specification for that I-P should say
that the body parts must be children of a multipart/alternative parent.
Etc etc etc.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Oct 2009 19:31:51 -0400

>> -----Original Message-----
[snip]
>> Info-Package do not

I think we are probably just not envisioning the same use case.
This is entangled with the debate I am having with Christer elsewhere.
I'll try a picture:

==== INFO message headers ======
| INFO ...
| C-D: info-pkg
| C-T: multipart/whatever
| (other headers)
|
==== INFO body start ===========
| ==== Part 1 headers ==========
| | C-T: text/plain
| | C-D: foo
| |
| ==== Part 1 body start =======
| | some text
| ==== Part 1 end ==============
| ==== Part 2 headers ==========
| | C-T: application/bar
| | C-D: baz
| |
| ==== Part 2 body start =======
| | (application/baz stuff)
| ==== Part 2 end ==============
==== INFO end ==================

This is what my text was trying to describe. And I don't think it is in 
conflict with your text in the beginning of the paragraph.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Oct 2009 19:40:44 -0400

> value" to be assigned to a body part just because it is transported

IMO its not about overhead, its about layering.
Consider multiparts used in email, such as for attachments. The 
attachments are often understood by pieces of software independent of 
the email system.

Similarly here. There will be something that receives the info package 
body - that knows that is what it is. But if it has chosen to use 
multipart to consolidate a number of things into it, those might come 
from, and be consumed by independent software. (Considering that INFO 
has been used for tunneling stuff for other protocols, its really easy 
to imagine that.)

The subordinate C-D values may be needed to interpret that stuff.

I think we don't have enough people in this discussion. The two of us 
are just not going to agree. I'd like to hear from Adam who has had a 
lot of insight into multipart in the past, and from Gonzallo, who wrote 
the body handling draft.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Oct 2009 20:00:30 -0400

> 'info-package'. Why does that not work??? 

Lets consider an extreme case:

                |---B1
                |
                |      |---C1
              A-|---B2-|
                |      |---C2
                |
                |      |---D1
                |---B3-|
                       |---D2

In the above,
- A is the body of an INFO message. Its multipart/mixed.
- B1 is one part of A, it is not multipart
- B2 and B3 are also parts of A. They are multipart/mixed.
- C1 and C2 are parts of B2.
- D1 and D2 are parts of B3.

What you seem to say above is that it would make sense to have C2, B3, 
D1, and D2 be C-D info-package, while the others are something else. In 
that case it is very hard to imagine how C1 could have any role at all.

The only way what you say seems workable is if it is a rule once you 
have a part with C-D of info-package then *all* subordinate parts of 
that must also have C-D of info-package. But why would you do that?

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 22 Oct 2009 06:49:43 +0200

Hi, 

>>[JRE] But wouldn't that then conflict with the first of my 
>>proposed sentences? The first sentence says "The body part 
>>associated with the Info Package MUST contain a 
>>Content-Disposition header field with value 'Info-Package'". 
>>Your modified second sentence then seems to contradict it by 
>>saying only in certain circumstances does it need to do this.
> 
>This is what my text was trying to describe. And I don't 
>think it is in conflict with your text in the beginning of the
paragraph.

You are using different C-D values for the body parts associated with
the Info Package.

But, again, a body part associated with an Info Package shall have value
'info-package'.

And, in your example above, assuming that Part 2 would NOT be part of
the Info Package, HOW do you indicate that Part 1 (C-D: foo) is
associated with the Info Package? 

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 22 Oct 2009 06:58:37 +0200

Hi, 

>Consider multiparts used in email, such as for attachments. 
>The attachments are often understood by pieces of software 
>independent of the email system.

Yes, but where is it said that it doesn't matter what C-D value they
have, since they were part of the e-mail?

And, in an e-mail you don't include body parts which are not associated
with the e-mail, which can happen with INFO.

>Similarly here. There will be something that receives the 
>info package body - that knows that is what it is. But if it 
>has chosen to use multipart to consolidate a number of things 
>into it, those might come from, and be consumed by 
>independent software. (Considering that INFO has been used 
>for tunneling stuff for other protocols, its really easy to 
>imagine that.)

An INFO can only contain body parts associated with ONE SINGLE
Info-Package. If different parts are to end up in different software
that is the task of the application associated with Info-Package. The
whole idea is that the information is transparent to the SIP stack. The
SIP stack only needs to know to which application to forward the body
parts with C-D: info-package.
 
>The subordinate C-D values may be needed to interpret that stuff.

Not by the SIP stack. If the body part is associated with the
Info-Package, the application will handle it.

>I think we don't have enough people in this discussion. The 
>two of us are just not going to agree. I'd like to hear from 
>Adam who has had a lot of insight into multipart in the past, 
>and from Gonzallo, who wrote the body handling draft.

Gonzalo is the one who pointed out the text in the body-handling RFC to
me, but I guess he could give his opinion on the list also.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 22 Oct 2009 08:42:21 +0200

Paul,

Yes, we were talking at cross purposes, and I realise now there was some ambiguity in my original text proposal. Anyway, let's get the big issue between you and Christer resolved before we go back to word smithing.

John 

> Sent: 22 October 2009 00:32
> To: Elwell, John
> think it is in

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Oct 2009 09:30:52 -0400

> But, again, a body part associated with an Info Package shall have value

You keep repeated the last sentence above as a mantra, as if it was cast 
in stone. But we are discussing what is supposed to be written on the stone.

And in any case, in the above it is the body part with C-D of 
info-package that is associated with the info package.

> associated with the Info Package? 

Wrong assumption. *My* assumption is that once a body/body part is 
associated with the info package, then *all the bits it contains* 
including any nested body parts, are transitively also associated with 
the info package.

Its a tree. If I own a branch, then I own all the descendents of that 
branch. If I saw it off and take it somewhere, I take the whole thing. I 
don't just take away my immediate branch and leave some of its children 
behind floating in the air around the tree.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Oct 2009 09:45:42 -0400

> Yes, we were talking at cross purposes, and I realise now there was some ambiguity in my original text proposal. Anyway, let's get the big issue between you and Christer resolved before we go back…

Then if we now have a common basis for discussion, what is your thinking 
on the debate Christer and I are having? I think it is actually quite 
fundamental in how one approaches implementing this, or implementing 
multipart support in general.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 22 Oct 2009 15:46:56 +0200

Hi, 
 
>>>>[JRE] But wouldn't that then conflict with the first of my proposed 
>>>>sentences? The first sentence says "The body part associated with 
>>>>the Info Package MUST contain a Content-Disposition header field 
>>>>with value 'Info-Package'".
>>>>Your modified second sentence then seems to contradict it by saying 
>>>>only in certain circumstances does it need to do this.
>>>This is what my text was trying to describe. And I don't think it is 
>>>in conflict with your text in the beginning of the paragraph.
>> 
>>But, again, a body part associated with an Info Package shall have
value 'info-package'.
> 
>You keep repeated the last sentence above as a mantra, as if it was
cast in stone. But we are discussing what is supposed 
>to be written on the stone.

Well, my understanding is that we decided that a long time ago, so I
wouldn't like to change it unless it doesn't work. But I may of course
be wrong.

In my opinion, since the SIP stack doesn't need to know whether the
content of the I-P body part shall be rendered, or whatever, we can
always use 'info-package'. The I-P specification then defines what the
application shall do with it.

Yes, but as you know, my opinion is that the individual body parts also
shall have the correct C-D value, so foo and baz should be
'info-package' :)

>Wrong assumption. *My* assumption is that once a body/body 
>part is associated with the info package, then *all the bits 
>it contains* including any nested body parts, are 
>transitively also associated with the info package.
> 
>Its a tree. If I own a branch, then I own all the descendents 
>of that branch. If I saw it off and take it somewhere, I take 
>the whole thing. I don't just take away my immediate branch 
>and leave some of its children behind floating in the air 
>around the tree.

But, again, how would the message look like if Part 1 is an I-P body
part and Part 2 isn't? That IS a possible use-case, since we have agreed
that someone may add extra body parts to the INFO.

Would you add a second multipart (C-D 'info-package'), inside the first
multipart, which would only contain Part 1?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Oct 2009 10:33:22 -0400

> application shall do with it.

That is fine, at the branch of the tree where the thing is determined to 
be I-P content. Below that point is another story.

> shall have the correct C-D value, so foo and baz should be

Which is the heart of the discussion.

> that someone may add extra body parts to the INFO.

OK, lets draw a few more cases.

1) My case from the earlier message with some names changed to make 
things clearer:

=== INFO message headers ===========
| INFO ...
| C-D: info-pkg
| C-T: multipart/whatever
| (other headers)
|
=== INFO body start ================
| === Info-pkg txt part headers ====
| | C-T: text/plain
| | C-D: foo
| |
| === Info-pkg txt part body start =
| | some text
| === Info-pkg txt part end ========
| === Info-pkg xml part headers ====
| | C-T: application/bar
| | C-D: baz
| |
| === Info-pkg xml part body start =
| | (application/bar stuff)
| === Info-pkg xml part end ========
=== INFO end =======================

2) Your case, where the info package only requires a single text part, 
but an extension header also requires a part that is unrelated to the 
info package.

=== INFO message headers ===========
| INFO ...
| C-D: info-pkg
| C-T: multipart/mixed
| Extension-Header: <cid:some-label>
| (other headers)
|
=== INFO body start ================
| === Info-pkg txt part headers ====
| | C-T: text/plain
| | C-D: info-package
| |
| === Info-pkg txt part body start =
| | some text
| === Info-pkg txt part end ========
| === Ext-hdr part headers =========
| | C-T: application/extension-header
| | C-D: by-reference
| | Content-ID: some-label
| |
| === Ext-hdr part body start ======
| | (application/extension-header stuff)
| === Ext-hdr part end =============
=== INFO end =======================

3) A combination of the two cases. The stuff "associated with the info 
package" is again a multipart, just as in the first case, but now it 
shares the INFO body with a body part for the extension header of the 
second case. This requires introducing a multipart/mixed just as the 2nd 
case did

=== INFO message headers =============
| INFO ...
| C-D: info-pkg
| C-T: multipart/mixed
| Extension-Header: <cid:some-label>
| (other headers)
|
=== INFO body start ==================
| === Info-pkg multipart headers =====
| | C-D: info-pkg
| | C-T: multipart/whatever
| |
| === Info-pkg multipart body start ==
| | === Info-pkg txt part headers ====
| | | C-T: text/plain
| | | C-D: foo
| | |
| | === Info-pkg txt part body start =
| | | some text
| | === Info-pkg txt part end ========
| | === Info-pkg xml part headers ====
| | | C-T: application/bar
| | | C-D: baz
| | |
| | === Info-pkg xml part body start =
| | | (application/bar stuff)
| | === Info-pkg xml part end ========
| === Info-pkg multipart end =========
| === Ext-hdr part headers ===========
| | C-T: application/extension-header
| | C-D: by-reference
| | Content-ID: some-label
| |
| === Ext-hdr part body start ========
| | (application/extension-header stuff)
| === Ext-hdr part end ===============
=== INFO end =========================

Is that clear?

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 22 Oct 2009 18:48:36 +0200

Hi, 

>>>> This is what my text was trying to describe. And I don't think it 
>>>> is in conflict with your text in the beginning of the paragraph.
>>> You are using different C-D values for the body parts associated 
>>> with the Info Package.
>>>

>That is fine, at the branch of the tree where the thing is determined
to be I-P content. Below that point is another story.

(Christer) I think we need to separate 3 issues.

FIRST, can an Info Package specification in general specify another C-D
value than 'info-package' to a body part associated with the I-P
(without considering where in the body part the body part will be
located).

SECOND, if a multipart contains C-D "info-package", does it matter what
C-D values the children have?

THIRD, do we require all body parts (if many) associated with the I-P to
be part of the same multipart of the message (no matter whether the
children will get C-D 'info-package' or not).

Regarding the FIRST issue, when looking at your examples below, I THINK
that we agree that an I-P specification should never assign another C-D
value than 'info-package' to a body part associated with the I-P.
Correct?

Regarding the SECOND issue, I think that is we have different views. You
say that as long as the parent has C-D 'info-package' it doesn't matter
what values a parser may assign to the children, while I think that the
children should also explicitly be assigned 'info-package'.

Regarding the THIRD issue, I don't think we should mandate it. I think
that a I-P specification should indicate whether some body parts need to
be collected within a multipart, what multipart type (mixed, alternative
etc) shall be used etc.

-------------------

>=== INFO end =======================

So, just to be clear: it does not matter what foo and baz are, since the
parent C-D is info-pkg. In other words, the I-P specification does not
specifiy that the foo and baz values shall be used for these body parts.

-------------------

>=== INFO end =======================

This is the example on which I assume your opinion on the first issue:
if an I-P body part does not have a parent with C-D 'info-package', it
shall always have C-D 'info-package'. The I-P specification does not
mention "foo" - "foo" in the previous example was just whatever value
which the receiving parser may have assigned, right?

Also, would it be allowed to have multiple I-P body partss inside this
multipart? That could happen if the original INVITE contains a multipart
with two I-P body parts, but someone else inserts a third body into the
multipart. Or, would whoever inserts the third body part be mandated to
create a second level multipart for the I-P body parts (as in example
3)?

-------------------

package" is again a multipart, just as in the first case, but now it
shares the INFO body with a body part for the extension header >of the
second case. This requires introducing a multipart/mixed just as the 2nd
case did
>=== INFO end =========================

On this example I of course have the same issue as the first one,
regaring the C-D values withint the I-P mulipart.

But, this example also raises the third issue: do we mandate that all
I-P body parts belong to the same multipart?

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Oct 2009 12:41:46 -0500

On 10/21/09 18:40, Oct 21, Paul Kyzivat wrote:
> lot of insight into multipart in the past, and from Gonzallo, who 
> wrote the body handling draft.

I'm with Paul on this one. By requiring subparts within an INFO 
multipart document to be *all* labeled with a C-D of "info-package", 
you're removing a lot of flexibility. Suddenly, INFO packages are 
disallowed from using C-D on their own multipart subparts to impact 
processing.

Consider a hypothetical INFO package that, for some reason or another, 
needed to carry an email message in its body. In this particular case, 
consider that the email message contains two attachments: one image 
(say, a company logo), and a document. The image is inline in the 
sender's signature. The document shouldn't be inlined, but is expected 
to be rendered simply as a separate attachment. If we take the approach 
Paul & I are advocating, you can properly mark the attachments with 
"Content-Disposition: inline" and "Content-Disposition: attachment."

With your approach, the package would be forced to mark them both with 
"Content-Disposition: info-package." It seems like a horrific waste 
forcing the redundant "info-package" string down into places where it 
(a) adds no additional information and (b) precludes the ability to 
*add* useful information.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 22 Oct 2009 19:58:01 +0200

Hi, 

>>> I don't agree. Eventhough I do hear what you are saying, in my 
>>> opinion "We don't care" goes against what we tried to fix with RFC 
>>> 5621, and could potentially cause problems. An Info-Package body
part 
>>> shall have C-D 'info-package', and I don't like that fact that we 
>>> should allow "any value" to be assigned to a body part just because 
>>> it is transported within a multipart.
>>

processing.

There are cases (see Paul's examples) where I believe you MUST use C-D
'info-package' for the I-P body part, so we could not assume that one
would always be able to use something else (inline, attachment etc) for
the body part.

In addition, based on Paul's previous reply, I am not sure whether being
able to specify other C-D values for I-P body parts is really what he is
asking for.

He is saying (I guess he should confirm it :) that if you have a
multipart with C-D 'info-package', then it does not matter what C-D
values the parser may assign the body parts within the multipart, since
one knows that they all belong to the I-P. That is NOT the same as
saying that a body non-'info-package' should be defined for a specific
I-P body part.

needed to carry an email message in its body. In this particular case,
consider that the email message contains two attachments: one 
>image (say, a company logo), and a document. The image is inline in the
sender's signature. The document shouldn't be inlined, but is expected
to be rendered simply as a separate attachment. If we take 
>the approach Paul & I are advocating, you can properly mark the
attachments with "Content-Disposition: inline" and "Content-Disposition:
attachment."

So, if you have a single multipart, with one I-P body part with
C-D:inline, and one non-I-P body part (may have been inserted by someone
else), how do you indicate which body part belongs to the I-P?

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Oct 2009 13:54:23 -0500

On 10/22/09 12:58, Oct 22, Christer Holmberg wrote:
> C-D:inline, and one non-I-P body part (may have been inserted by 
> someone else), how do you indicate which body part belongs to the I-P?

I think you've missed something important about my example. Keep in mind 
that multipart bodies are trees, not flat lists. You would never have 
the "inline" body part I described on the same level as something 
outside the info-package.

Perhaps diagrams would help.

In the case I described, the hypothetical INFO package I propose would 
be structured like this:

C-T: multipart/related
C-D: info-package
   |
   +- C-T: text/html
   |
   +- C-T: image/jpeg
   |  C-D: inline
   |
   +- C-T: application/pdf
      C-D: attachment

Now, throw in Paul's example of something like an AIB. According to the 
way MIME works, the resulting document would look like this:

C-T: multipart/parallel
   |
   +- C-T: multipart/related
   |  C-D: info-package
   |   |
   |   +- C-T: text/html
   |   |
   |   +- C-T: image/jpeg
   |   |  C-D: inline
   |   |
   |   +- C-T: application/pdf
   |      C-D: attachment
   |
   +- C-T: message/sipfrag
C-D: aib

It's pretty clear, on a casual inspection, that the text/html, 
image/jpeg, and application/pdf are all part of the information related 
to the info-package, because they all have an ancestor marked with a C-D 
of "info-package". Similarly, the message/sipfrag clearly is not part of 
the info-package, because it does *not* have an ancestor marked as 
"info-package".

If I read it correctly, your proposal would require the image/jpeg and 
application/pdf to both be marked with a C-D of "info-package", even 
though doing so is *USELESS*, *REDUNDANT*, and *HARMFUL*. In doing so, 
you wipe out the ability to indicate applicable C-Ds like "inline".

/a

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 22 Oct 2009 21:36:47 +0200

> Sent: 22 October 2009 14:46
> To: Elwell, John
> > Yes, we were talking at cross purposes, and I realise now 
> there was some ambiguity in my original text proposal. 
> Anyway, let's get the big issue between you and Christer 
> resolved before we go back to word smithing.
> 
[JRE] I tend to share your point of view, but my understanding of what has been discussed before on SIP bodies (both in this context and in the body-handling RFC context) is somewhat weak, so I am reluctant to speak out too strongly on this one.

John

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Oct 2009 15:57:13 -0500

I think some MIME confusion has slipped into Paul's examples. Comments 
below.

> === INFO end =======================

This looks right to me.

> === INFO end =======================

This doesn't look right. I don't think the SIP headers should include 
C-D: info-pkg. That should appear only on the text/plain subpart.

> second case. This requires introducing a multipart/mixed just as the 
> 2nd case did
>

Again, I think you erroneously included a C-D of "info-package" in the 
SIP header fields. It should appear only on the "multipart/whatever" 
subpart.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Oct 2009 17:15:53 -0400

> I think some MIME confusion has slipped into Paul's examples. Comments 

Yes, it wasn't what I intended to say. I did this part of example 2 
right once, and then did it over to change the names to be clearer while 
adding (3), and botched it. :-(

To facilitate further discussion, here is a revised version of all the 
examples:

| C-D: render (or none)

| C-D: render (or none)

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 22 Oct 2009 14:22:17 -0700

I think that in this particular example it would be more natural to 
carry the email as message/rfc822. That's not a multipart type so it 
amounts to carrying the multipart email as a blob inside some other 
multipart structure although of course the message/rfc822 body can still 
be parsed as a multipart body itself...

[I've mostly given up on this thread and I don't have an opinion either 
way so apologies if this is completely off the mark...]

Anders

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 22 Oct 2009 23:28:49 +0200

Hi, 

>I think you've missed something important about my example. Keep in
mind that multipart bodies are trees, not flat lists. You would never
have the "inline" body part I described on the same level as 
>something outside the info-package.
>
>   |   +- C-T: application/pdf

Yes, but what about if there is only I-P ONE body part (e.g.
image/jpeg), plus the aib body part. Will you use the multipart/related
body part with that single I-P body part only?

C-T: multipart/parallel
   |

If so, I don't think that is what Paul proposed. He proposed:

C-T: multipart/parallel
   |
   +- C-T: image/jpeg
   |  C-D: info-package
   |   
   +- C-T: message/sipfrag
C-D: aib

Note that the C-D value has now changed from 'inline' to 'info-package'
in order to distinguish the I-P body part from the rest. That is bad, in
my opinion.

(Maybe I missunderstood Paul, and in that case I appologize, but that is
how he showed it in one of his pictures.)

image/jpeg, and application/pdf are all part of the information related
to the info-package, because they all have an ancestor marked with a 
>C-D of "info-package". Similarly, the message/sipfrag clearly is not
part of the info-package, because it does *not* have an ancestor marked
as "info-package".
application/pdf to both be marked with a C-D of "info-package", even
though doing so is *USELESS*, *REDUNDANT*, and *HARMFUL*. In 
>doing so, you wipe out the ability to indicate applicable C-Ds like
"inline".

My assumption has been that the body part payload contains information
what the application is supposed to do with it. But, the important thing
is to agree on something that works.

But, I hope that it wouldn't mean that one is not allowed to use C-D
'info-package' for a non-multipart body part, in case the payload
contains information on how the application is supposed to process it.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 22 Oct 2009 23:40:15 +0200

Hi Paul,

Sometimes in your example you use C-D 'foo' for the text/plain body
part, and sometime you use C-D 'info-package' for text/plan.

My understanding of what Adam is saying that an I-P body part
(non-multipart) should be allowed to have any C-D value, and in that
case I don't think we can change the value depending on where the body
part is located.

For example, the I-P specification may say that text/plain can have
either C-D 'foo' and 'baz', and it is important that the remote
application gets that information. Then you can't change it to
'info-package'.

Now, if would assume that all I-P body parts have C-D 'info-package' it
would not be a problem - but that is not what Adam says.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 23. lokakuuta 2009 0:16
To: Adam Roach
Cc: Christer Holmberg; Elwell, John; SIPCORE; Gonzalo Camarillo;
[email-masked]
Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01)
- John E's comments - non-I-P body parts in INFO?

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Oct 2009 17:46:14 -0400

> in order to distinguish the I-P body part from the rest. That is bad, in

I think you can use either of the above, depending on your needs.
(But the choice will be in the specification of the particular info 
package, not by the developer.)

You would use the first if the C-D:inline is important to preserve,
and the second if it is not.

> how he showed it in one of his pictures.)

In this case you did understand me.

> contains information on how the application is supposed to process it.

That should be perfectly fine, and I think will be the common case.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Oct 2009 17:51:52 -0400

> part, and sometime you use C-D 'info-package' for text/plan.

I used 'foo' (or some other random string) when my point was that it 
didn't matter. I used info-package when it needed to be that.

> case I don't think we can change the value depending on where the body

See my comment to your other message about that.

> application gets that information. Then you can't change it to

The info package specification will have to start with the understanding 
that the top of the body part tree that belongs to it *always* starts 
with C-D of info-package.

If that tree is just a trunk with no branches, then that is all there 
is. If the particular info package permits that body to be a multipart, 
then it will also have to specify what kind of multipart and what the 
C-Ds of the branches may be.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 23 Oct 2009 00:05:05 +0200

Hi, 

>>>Now, throw in Paul's example of something like an AIB. According to 
>>>the way MIME works, the resulting document would look like this:
>>>C-T: multipart/parallel
>>>   |
>>image/jpeg), plus the aib body part. Will you use the 
>>multipart/related body part with that single I-P body part only?
>> 
>>C-T: multipart/parallel
>>    |
>>in order to distinguish the I-P body part from the rest. That is bad, 
>>in my opinion.
>
>
>You would use the first if the C-D:inline is important to preserve, and
the second if it is not.

IF we, as suggested by Adam, allow different C-D values for I-P body
parts, I REALLY think we shall ASSUME and REQUIRE that they SHALL be
preserved. I am pretty sure that is how other applications work also...
Otherwise we are really begging for interop problems, in my opinion.

And, if the C-D value really doesn't matter to the remote application
then one should use 'info-package'. I don't want specification text
saying "Use whatver C-D value you want - noone cares anyway" :)

>>image/jpeg, and application/pdf are all part of the information 
>>related to the info-package, because they all have an ancestor marked 
>>with a C-D of "info-package". Similarly, the message/sipfrag clearly
is not
>>part of the info-package, because it does *not* have an ancestor 
>>marked as "info-package".
>>If I read it correctly, your proposal would require the image/jpeg 
>>and application/pdf to both be marked with a C-D of "info-package",
even 

>>what the application is supposed to do with it. But, the important 
>>thing is to agree on something that works.
>> 

My proposal would then be to say that, by default, C-D 'info-package' is
assigned to all I-P body parts, but that I-P specifications are allowed
to define the usage values to be used also, as suggested by Adam (unless
I missunderstood him also :)

Regards,

Christer

---

From: Brett Tate <[email-masked]>
Date: Fri, 23 Oct 2009 05:05:58 -0700

> FOREVER SEND YOUR REFERS WITHOUT INFO PACKAGES! :)

They were likely added as a result of my "draft-ietf-sip-info-events-03: comments and questions" thread from last February/March.  Back then it was unclear where the header was required to avoid accidentally indicating that you no longer support the draft/packages communicated by Recv-Info earlier within the dialog.

http://www.ietf.org/mail-archive/web/sip/current/msg26846.html

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 23 Oct 2009 14:12:07 +0200

Hi Brett,

The draft currently says that you use 'Recv-Info: nil' to indicate that
you no longer want to receive INFO requests associated with an Info
Package.

Regards,

Christer

> From: Brett Tate [mailto:[email-masked]] 
> Sent: 23. lokakuuta 2009 15:06
> To: Christer Holmberg
> Cc: [email-masked]; SIPCORE
> > >>>11. In 5.2, why is Recv-Info allowed in NOTIFY 
> request/response and
> > in
> > Sorry, I didn't mean that there was a separate thread dedicated to 
> > that particular issue. But, Robert had the same comment, and I 
> > addresses it in my of my replies on his comments.
> > 
> > But, I HAVE removed Recv-Info from REF and NOT, because I can't 
> > remember why they were put there.
> > 
> They were likely added as a result of my 
> "draft-ietf-sip-info-events-03: comments and questions" 
> thread from last February/March.  Back then it was unclear 
> where the header was required to avoid accidentally 
> indicating that you no longer support the draft/packages 
> communicated by Recv-Info earlier within the dialog.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Oct 2009 18:08:45 -0400

Thanks Adam. We are on the same page here.
And I knew you would elaborate on the proper use of various multipart types.

I think we can go further here. In an INFO message, *the* body part 
associated with the info package named in message will *always* be found 
in one of the following places:

- it is the entire body of the message, with C-D:info-package
   among the sip headers.

- the body body of the info message is C-T multipart/mixed
   (or some other variant of multipart, adam?) and C-D is "render"
   or the C-D is missing. And then one, and only one, of the
   immediate child parts of that multipart will have C-D:info-package
   and be the one.

AFAIK there are no other possibilities that make any sense here.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Sat, 24 Oct 2009 00:14:31 -0500

On 10/23/2009 05:08 PM, Paul Kyzivat wrote:
> associated with the info package named in message will *always* be 
> found in one of the following places:
>

I think that is precisely the way we want to specify this behavior, and 
it's a far clearer formulation than my "exactly zero or one" proposal.

Regarding your "...or some other variant..." question: by specification, 
the order of body parts in multipart/mixed is significant. If you have a 
set of parts in which order does not matter, then *technically*, the 
correct type to use is multipart/parallel. In *practice*, I think 
multipart/mixed ends up being used a lot where multipart/parallel would 
be more correct. In INFO, it would also make sense to have 
multipart/digest and multipart/signed documents. Finally, it is possible 
to register new types under "multipart" [1] -- so we should probably 
just call out "multipart" in the spec instead of narrowing it down to 
"multipart/mixed".

> AFAIK there are no other possibilities that make any sense here.

I agree 100%.

/a

[1] http://www.iana.org/assignments/media-types/multipart/

---

From: Dean Willis <[email-masked]>
Date: Sat, 24 Oct 2009 02:57:05 -0500

Elwell, John wrote:
> For 7.6: "The Info Package specification MUST define what type of 
> body part is associated with the Info Package, and MUST refer to
> specifications where the syntax, semantics and MIME type of that body
> part (and, if multipart/mixed, any child body parts) are described."

An Info package should be able to use multiple types of body parts, else
we're back to the type=usage encoding.

for example, a call-associated image might be tiff, jpeg, gif, etc.

Also, what is the semantic of an image? There is no inherent semantic at
the MIME level. MIME tells us what an object is, not what we should do
with it. Rather, the Info Package specification must define the semantic
of the info-package payload, rather than relying on the MIME
specification to do do.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 24 Oct 2009 18:02:29 +0200

Hi, 

>I think that is precisely the way we want to specify this behavior, and
it's a far clearer formulation than my "exactly 
>zero or one" proposal.
>
>Regarding your "...or some other variant..." question: by
specification, the order of body parts in multipart/mixed is 
>significant. If you have a set of parts in which order does not matter,
then *technically*, the correct type to use is 
>multipart/parallel. In *practice*, I think multipart/mixed ends up
being used a lot where multipart/parallel would be 
>more correct. In INFO, it would also make sense to have
multipart/digest and multipart/signed documents. Finally, it is 
>possible to register new types under "multipart" [1] -- so we should
probably just call out "multipart" in the spec 
>instead of narrowing it down to "multipart/mixed".

One alternative would be to define a default type in the base spec, and
if, for a specific I-P another value shall be used the I-P specification
shall indicate that.

I would still like to have an answer on the following: what is the
multipart value if the multipart only contains a SINGLE child part? I
guess one could use almost whatever value, but I would still like to
know whether there are any rules.

>>AFAIK there are no other possibilities that make any sense here.

I just hope that other entities that insert body parts into the INFO
message will do the right thing...

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 24 Oct 2009 18:06:33 +0200

Hi Dean, 

>> For 7.6: "The Info Package specification MUST define what type of
body 

>An Info package should be able to use multiple types of body parts,
else we're back to the type=usage encoding.
>Also, what is the semantic of an image? There is no inherent semantic
at the MIME level. MIME tells us what an object is, 
>not what we should do with it. Rather, the Info Package specification
must define the semantic of the info-package 
>payload, rather than relying on the MIME specification to do do.

Just to clarify, I have not said anything about the Content-Type of a
body part. I agree it could be whatever.

One question has been whether a body part associated with the Info
Package could have a Content-Disposition value other than
"info-package".

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Sat, 24 Oct 2009 13:49:45 -0500

On 10/24/09 11:06, Oct 24, Christer Holmberg wrote:
> Package could have a Content-Disposition value other than "info-package".

For the top-level INFO-related part, I think the answer is "no."

For any parts under [1] that top-level INFO-related part, I think the 
answer is "yes, and in fact, it MUST NOT have a C-D of 'info-package'."

/a

[1] I mean "under" in the sense of being descendants in the MIME tree 
structure.

---

From: Adam Roach <[email-masked]>
Date: Sat, 24 Oct 2009 14:04:51 -0500

> if, for a specific I-P another value shall be used the I-P specification

The whole point here is that body part handling for non-INFO body parts 
is going to be outside the INFO package specifications -- it's going to 
be defined by other documents. See, for example:

    * The final paragraph on page 4 of RFC 3893
    * Section 3.4.3.2 of RFC 2633

It would be the height of folly to nail down specific handling in both 
the base INFO spec and its packages, as they woule

> multipart value if the multipart only contains a SINGLE child part?

multipart/justkidding? multipart/notreally? 
multipart/i-dont-understand-how-mime-works?

Why would someone *DO* that?

> message will do the right thing...

Unless the procedures that they are implementing are designed by people 
who don't have a basic understanding of MIME, they will all Do The Right 
Thing, under the rules that Paul and I are advocating.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 24 Oct 2009 22:44:26 +0200

Hi,
 
>>One question has been whether a body part associated with the Info Package could have a Content-Disposition value other than "info-package".
>
 
So, assume Info Package X uses a body part 'application/foo'.
 
Now, if I understand you correctly, if this body part happens to be on the top-level (for example, it is the only body part in the message body of the request) it would have C-D 'info-package', but if it happens to be within a multipart with C-D 'info-package' it could have C-D 'foo'?
 
In my opinion the I-P specification for X shall say: "For this package, when you use C-T 'application/foo', you use C-D 'baz'". That should be independent on where in the message body structure application/foo is located.
 
The I-P specification should NOT say: "If application/foo is on this level you use C-D 'baz', and if it is on that level you use C-D 'info-package'." 
 
That would be really messy...
 
Regards,
 
Chriser

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 24 Oct 2009 22:52:18 +0200

Hi,
 
The encoding of the e-mail got a little messed up, so I may have missed something.
 
I agree that the draft is not describing body handling for non-INFO body parts. I was only talking about multiparts with C-D 'info-package', ie multiparts which contain body parts associated with the I-P.
 
Assume that the Info Package Y specification defines the usage of body parts 'application/aaa' and 'application/bbb'. The specification says that both body parts can be sent in a single INFO request, inside a multipart. My proposal was that the I-P specification would say what type is used for THAT multipart - because who else will know what type to use? 
 
Whatever other multiparts types are used in the message body is outside the scope...
 
Regards,
 
Christer

________________________________

From: Adam Roach [mailto:[email-masked]]
Sent: Sat 24/10/2009 21:04
To: Christer Holmberg
Cc: Paul Kyzivat; Elwell, John; SIPCORE; Gonzalo Camarillo; [email-masked]
Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO?

The whole point here is that body part handling for non-INFO body parts is going to be outside the INFO package specifications -- it's going to be defined by other documents. See, for example:

It would be the height of folly to nail down specific handling in both the base INFO spec and its packages, as they woule

multipart/justkidding? multipart/notreally? multipart/i-dont-understand-how-mime-works?

	  

		I agree 100%.

Unless the procedures that they are implementing are designed by people who don't have a basic understanding of MIME, they will all Do The Right Thing, under the rules that Paul and I are advocating.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Oct 2009 09:07:46 -0400

> For the top-level INFO-related part, I think the answer is "no."

Agree. This is a "duh" since this is *the* way the part associated with 
the info package is identified.

> answer is "yes, and in fact, it MUST NOT have a C-D of 'info-package'."

Lets not get carried away here and ban things just because we can't 
currently conceive of a use. I can think of cases where descendents 
might want to reuse the C-D:info-package. (E.g. where the info package 
contains a copy of a full SIP message, including possibly an INFO 
message, or a sipfrag of one.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Oct 2009 09:09:53 -0400

> Assume that the Info Package Y specification defines the usage of body parts 'application/aaa' and 'application/bbb'. The specification says that both body parts can be sent in a single INFO reques…

It first must specify *the* top level part. In your case it will 
presumably have decided that it needs some sort of multipart for that, 
and will indeed specify which variety/varieties of multipart make sense 
for it.

> Whatever other multiparts types are used in the message body is outside the scope...

Good.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 26 Oct 2009 14:25:22 +0100

Hi,
 
>>I agree that the draft is not describing body handling for non-INFO body parts. I was only talking about multiparts with C-
>>D 'info-package', ie multiparts which contain body parts associated with the I-P.
>> 
>>Assume that the Info Package Y specification defines the usage of body parts 'application/aaa' and 'application/bbb'. The 
>>specification says that both body parts can be sent in a single INFO request, inside a multipart. My proposal was that the 
>>I-P specification would say what type is used for THAT multipart - because who else will know what type to use?
>

Then, take the following example:

An INFO request contains only a SINGLE body part (application/aaa), associated with the I-P.

The I-P specification says that C-D 'foo' is used for 'application/aaa'. And, since there is only one single body part, the SIP header C-T will indicate 'application/aaa' and the SIP header C-D will indicate 'foo'.

Now, WHERE are you going to put the "top level" part, which indicates 'info-package'?

Are you going to create a multipart for that single body part, so that you can put C-D 'info-packag' in the SIP header, and C-D 'foo' inside the multipart?

Regards,

Christer

 

Good.

        Thanks,
        Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 26 Oct 2009 14:30:21 +0100

Hi,
 
I think C-D 'info-package' shall be allowed for any part associated with the I-P, if the remote terminating knows how to process the information.
 
Regards,
 
Christer

From: Paul Kyzivat [mailto:[email-masked]]
Sent: Mon 26/10/2009 14:07
To: Adam Roach
Cc: Christer Holmberg; Dean Willis; Elwell, John; [email-masked]; SIPCORE; [email-masked]; Gonzalo Camarillo
Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO?

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Oct 2009 11:02:45 -0400

> Are you going to create a multipart for that single body part, so that you can put C-D 'info-packag' in the SIP header, and C-D 'foo' inside the multipart?

We have said that the body part associated with an I-P is determined by 
the C-D of info-package. So that is a given when writing the 
specification for the I-P.

*If* the I-P wants to receive a single body part, and it wants that to 
have C-D of foo, then it is out of luck. It can then, if it wishes, 
specify that it should receive a multipart (with C-D of info-package) 
containing a single body part of C-T application/aaa and C-D of foo.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 26 Oct 2009 16:41:34 +0100

Hi,

>specification for the I-P.

Yes. 

>containing a single body part of C-T application/aaa and C-D of foo.

Which is kinda overkill - especially since I think a single body part is going to be the most common INFO use-case.

Now, the easiest solution is of course to specify that C-D 'info-package' shall be used for this body part. BUT, then C-D 'info-package' shall be used also if the body part would be placed inside a multipart with C-D 'multi-part'.

Again, my point is that a single body part (non-multipart) should have the same C-D value no matter where it is located in the INFO request.

So, I think that we should allow non-'info-package' C-D values for I-P body parts ONLY if they will ALWAYS be located inside a multipart with C-D 'multi-part'.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Mon, 26 Oct 2009 10:57:45 -0500

>> specification for the I-P.

We appear to all be in agreement on this point.

> Which is kinda overkill - especially since I think a single body part is going to be the most common INFO use-case.

I agree with Christer on this point.

> Now, the easiest solution is of course to specify that C-D 'info-package' shall be used for this body part. BUT, then C-D 'info-package' shall be used also if the body part would be placed inside a…

Right. But that won't really happen inside the confines of an INFO 
package -- it can really only happen as the result of multipart 
processing due to some other technique (such as S/MIME or AIB 
processing). Which means that we can't really say anything useful about 
it in either of the INFO base spec or any of the INFO packages. The 
relevant procedures are defined by the thing that causes the multipart 
usage to arise.

> Again, my point is that a single body part (non-multipart) should have the same C-D value no matter where it is located in the INFO request.

I agree with this.

> So, I think that we should allow non-'info-package' C-D values for I-P body parts ONLY if they will ALWAYS be located inside a multipart with C-D 'multi-part'.

I think we're converging on agreement here.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Oct 2009 12:41:26 -0400

> Which is kinda overkill - especially since I think a single body part is going to be the most common INFO use-case.

Its only overkill if somebody actually does it.
Its a theoretical possibility, but not one I would expect to be used.
I can only imagine it being used if there were a case where the 
disposition can vary, and with a single body part I find that unlikely.

> Now, the easiest solution is of course to specify that C-D 'info-package' shall be used for this body part. BUT, then C-D 'info-package' shall be used also if the body part would be placed inside a…

So, you are proposing a case where sometimes the I-P consists of a 
single, non-multipart, part, and other times it needs that part, and 
also needs another part, and so then requires a multipart to contain 
them both. Right?

> Again, my point is that a single body part (non-multipart) should have the same C-D value no matter where it is located in the INFO request.

In such a case, I have no fundamental objection to using C-D of 
info-package in both cases, though that might not be the way I would 
prefer to define it.

> So, I think that we should allow non-'info-package' C-D values for I-P body parts ONLY if they will ALWAYS be located inside a multipart

I thought I was agreeing with you as I read all the above,

> with C-D 'multi-part'.

until I got to this part. Did you mean C-T of multipart???

But actually I think I don't agree anyway. I think we should just stop 
talking about "I-P body part*s*" entirely. It is confusing the 
discussion immensely.

I-P always has *one* body part, which can be of any C-T.
I proposed some words for where that body part may reside within the 
INFO message.

Of course that one body part may be a multipart, but we really don't 
need to say anything about that.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 26 Oct 2009 18:52:12 +0100

Hi,
 
>>>> The I-P specification says that C-D 'foo' is used for 'application/aaa'. And, since there is only one single body part, the SIP header C-T will indicate 'application/aaa' and the SIP header C-D will indicate >>>>'foo'.
>>>>

An I-P COULD define different disposition alternatives for a body part. But, it is probably not a good idea - unless the body part will always be inside a multipart with C-D 'info-package'.

>>Now, the easiest solution is of course to specify that C-D 'info-package' shall be used for this body part. BUT, then C-D 'info-package' shall be used also if the body part would be placed inside a multipart >>with C-D 'multi-part'.
>

Yes.

Assume that the I-P specification allows the usage of two different body parts (app/aaa and app/bbb). But, that may not mean that the body parts will always be used together. So, if only one of them it used (and there is no other body part in the INFO) there would be no need for multipart. But, if both are used in the same INFO there would be a need for multipart.

But, in all cases the C-D value for app/aaa and app/bee should be the same. And, in this case the C-D value would have to be 'info-package', since they can be used as the only body part of the message.

>In such a case, I have no fundamental objection to using C-D of info-package in both cases, though that might not be the way I would
>prefer to define it.

I think the easiest thing is to say that any body part, no matter whether it's inside of a multipart or not, can have C-D 'info-package'. And, if anohter C-D value is used, the body part MUST be inside a multipart with C-D 'info-package'. But, the body inside that multipart could also have C-D 'info-package' - especially if the body part could also be used without a multipart.

>until I got to this part. Did you mean C-T of multipart???

Yes :)

Yes.

Or, to be clear: I-P always has one "top level" body part. Inside an I-P multipart there may of course be multiple body parts associated with the I-P.

>I proposed some words for where that body part may reside within the INFO message.
>
>Of course that one body part may be a multipart, but we really don't need to say anything about that.

We do need to say that if an I-P uses non-'info-package' C-D values for body parts they MUST always be located inside a multipart with C-D 'info-package'.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Oct 2009 16:19:47 -0400

Christer Holmberg wrote:

Trimming out some of the older stuff...

> But, in all cases the C-D value for app/aaa and app/bee should be the same. And, in this case the C-D value would have to be 'info-package', since they can be used as the only body part of the mess…

In that scenario I would be inclined to specify use of the multipart all 
the time. But that is a judgment call. Ultimately the I-P can define it 
either way.

> I think the easiest thing is to say that any body part, no matter whether it's inside of a multipart or not, can have C-D 'info-package'. And, if anohter C-D value is used, the body part MUST be in…

I think that is true, but its confusing to say.
This document need only say how the C-D of info-package is used to 
select the part associated with the I-P of the INFO message. What C-D 
info-package means in any other context can be left unspecified.

> We do need to say that if an I-P uses non-'info-package' C-D values for body parts they MUST always be located inside a multipart with C-D 'info-package'.

I don't think we need to say that.
IMO it is clearer to *not* say it.

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 26 Oct 2009 22:52:21 +0100

Hi,
 
>>Assume that the I-P specification allows the usage of two different body parts (app/aaa and app/bbb). But, that may not mean that the body parts will always be used together. So, if only one of them it used (and there is no other body part in the INFO) there would be no 
>>need for multipart. But, if both are used in the same INFO there would be a need for multipart.
>>
>In that scenario I would be inclined to specify use of the multipart all the time. But that is a judgment call. Ultimately the I-P can define it either way.

Sure. But, keep in mind that the sender may not know whether someone else will insert a non-I-P body into the message, so the original body part may end up in a multipart, and that is one of the reasons why I think that body parts associated with the I-P must have the same C-D value no matter where they are "located" in the message body structure.

>>>In such a case, I have no fundamental objection to using C-D of info-package in both cases, though that might not be the way I would refer to define it.
>>
>>I think the easiest thing is to say that any body part, no matter whether it's inside of a multipart or not, can have C-D 'info-package'. And, if anohter C-D value is used, the body part MUST be inside a multipart with C-D 'info-package'. But, the body inside that multipart >>could also have C-D 'info-package' - especially if the body part could also be used without a multipart.
>

In my opinion C-D 'info-package' ALWAYS means "this body part is associated with the Info Package".

>I don't think we need to say that. IMO it is clearer to *not* say it.

We DO need to prevent users from putting those on the "top level".

What about?

"In the message body of the INFO request, the main body part associated with the I-P MUST use a C-D 'info-package' value, in order to distinguish the body part associated with the I-P from possible other body parts in the request. If there is a need to include multiple body parts associated with the I-P, or to include a body part for which the I-P specification defines a non-'info-package' C-D value, such body parts MUST be collected inside a multipart body part with a C-D 'info-package' value. The I-P specification MUST describe what type multipart is to be used in such cases.

An I-P specification SHOULD always specifiy a C-D 'info-package' value to be used for each individual body part associated with that I-P, unless another value is required in order for the remote application to be able to process the body part information correctly."

We could probably add some examples also.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Oct 2009 19:24:22 -0400

> Sure. But, keep in mind that the sender may not know whether someone else will insert a non-I-P body into the message, so the original body part may end up in a multipart, and that is one of the re…

All you need to know is the rule for finding the *while* I-P body part.
That has nothing to do with whether the I-P is multipart or not, or is 
always the same type or not.

Once you have found it, *then* you need to consult the specs for your 
I-P to figure out what to do next. You need no more *generic* 
instructions on this part.

> In my opinion C-D 'info-package' ALWAYS means "this body part is associated with the Info Package".

What if it isn't in an INFO message?

All the C-D values have some contextual definition. For instance 
"render" clearly means something different in a sip message than it does 
in an email message. (For rather stupid reasons we are using "render" 
for the C-D of the multipart that holds otherwise unrelated parts of a 
sip message.)

For example, I might sometime decide to put part/all of an INFO message 
into a sipfrag, and make that a body part on some other message, perhaps 
MESSAGE or another INFO. The sipfrag may or may not have the message 
header that denotes it as an INFO message. The key is that it really 
doesn't matter. When processing the MESSAGE, the C-D in the sipfrag is 
not in a context where it is relevant to processing of the MESSAGE. If 
the body were reconstituted into a full INFO message, and then that 
message were decoded, then the C-D would be significant.

Once it has been removed from the context where we have defined what it 
means, its meaning has to be taken from context.

> We DO need to prevent users from putting those on the "top level".

We need to do our part here to define what C-D of info-package means at 
the top level and within a top level multipart of C-D "render".
Anything else falls outside the specification of INFO, and might be 
valid based on references from headers and/or specific other C-D values. 
This doc doesn't need to specify everything else.

For instance, some body part may be referenced from some other extension 
header that is not understood by the recipient. Whether the message 
containing that is valid or not will be determined by the body_handling 
spec, not the INFO spec.

> What about?
> 
> "In the message body of the INFO request, the main body part associated with the I-P MUST use a C-D 'info-package' value, in order to distinguish the body part associated with the I-P from possible other body parts in the request.

I'm ok with the above.

> If there is a need to include multiple body parts associated with the I-P, or to include a body part for which the I-P specification defines a non-'info-package' C-D value, such body parts MUST be collected inside a multipart body part with a C-D 'info-package' value. The I-P specification MUST describe what type multipart is to be used in such cases.

None of the above sentence needs to be normative. The prior statement is 
sufficiently normative. This statement could be reworded in to something 
non-normative. For example:

"NOTE: If an I-P specification has need to allow inclusion of multiple 
body parts, and/or body part(s) containing a C-D other than 
info-package, it can specify that the body part associated with I-P can 
be a multipart type."

> An I-P specification SHOULD always specifiy a C-D 'info-package' value to be used for each individual body part associated with that I-P, unless another value is required in order for the remote ap…

I don't find the above sentence to be at all helpful.

> We could probably add some examples also.

Yes. It seems people program to the examples, so best to give them good 
ones.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 26 Oct 2009 19:41:13 -0500

On Oct 26, 2009, at 8:25 AM, Christer Holmberg wrote:

>>> I agree that the draft is not describing body handling for non- 
>>> INFO body parts. I was only talking about multiparts with C-
>>> Assume that the Info Package Y specification defines the usage of  
>>> body parts 'application/aaa' and 'application/bbb'. The
>>> specification says that both body parts can be sent in a single  
>>> INFO request, inside a multipart. My proposal was that the
>>> I-P specification would say what type is used for THAT multipart -  
>>> because who else will know what type to use?
>>

We're with you so far.

>
> The I-P specification says that C-D 'foo' is used for 'application/ 
> aaa'.

Then the I-P specification is broken and we should spank the author,  
the reviewers, and everybody else who let it slip past. Since it is a  
singular body part, it is also the top-level body part, and MUST have  
a C-D of "info-package". Otherwise, we have no way of knowing of the  
body part is intended as the package payload, or is instead a  
parasitic payload.

> And, since there is only one single body part, the SIP header C-T  
> will indicate 'application/aaa' and the SIP header C-D will indicate  
> 'foo'.
>

Not "foo". It will be "info-package".

> indicates 'info-package'?

Suitably lubricated, into an appropriate orifice. Or maybe skip the  
lube.

>
> Are you going to create a multipart for that single body part, so  
> that you can put C-D 'info-packag' in the SIP header, and C-D 'foo'  
> inside the multipart?

Somehow I think we're totally failing to communicate here.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 26 Oct 2009 19:53:18 -0500

On Oct 26, 2009, at 10:41 AM, Christer Holmberg wrote:
>
>
> Again, my point is that a single body part (non-multipart) should  
> have the same C-D value no matter where it is located in the INFO  
> request.
>

What if you have an INFO package that needs to convey two image/jpegs  
one for display to the user's left eye and one for the other's right  
eye? Or any other use case that requires two different components that  
need to be differentiated between within the package specification?

If there is only one body part in the I-P specification , this  
question does not arise; hence the suitability of marking the singular  
body part C-D as info-package. But when the I-P specification uses a  
multipart, we need a way to distinguish the parts. If two or more  
parts have the same MIM type, we can't differentiate based on type. My  
current thinking is to use a combination of content type and content  
disposition. Perhaps this is inadequate, and we need a more explicit  
mechanism?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Oct 2009 21:01:47 -0400

Dean Willis wrote:

> eye? 

I love it!!! Great example.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 27 Oct 2009 06:55:01 +0100

>I love it!!! Great example.

That is what I tried to cover with the following text that I suggested
in another reply:

"An I-P specification SHOULD always specifiy a C-D 'info-package' value
to be used for each individual body part associated with that I-P,
unless another value is required in order for the remote application to
be able to process the body part information correctly."

So, in this case the two image/jpeg body parts could have different C-D
'right-eye'/'left-eye' values. And, they would need to be inside a
multipart with C-D 'info-package'.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 27 Oct 2009 07:02:07 +0100

Hi, 

>>The I-P specification says that C-D 'foo' is used for
'application/aaa'.
> 
>Then the I-P specification is broken and we should spank the 
>author, the reviewers, and everybody else who let it slip 
>past. Since it is a singular body part, it is also the 
>top-level body part, and MUST have a C-D of "info-package". 
>Otherwise, we have no way of knowing of the body part is 
>intended as the package payload, or is instead a parasitic payload.

I totally agree with you.

But, my point is that 'application/aaa' would have C-D 'info-package'
also if it was placed inside a multipart with C-D 'info-package'.

So, that is why I think we need to say that ANY I-P body part that may
be inserted on the "top level" of the request message MUST be assigned
C-D 'info-package'. If other C-D values are defined for an I-P body part
(e.g. the right vs left eye example) they must be placed inside an
'info-package' multipart.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Oct 2009 01:25:18 -0500

> be able to process the body part information correctly."

The preceding does not parse for me in the way that you seem to be  
suggesting it should.

Either the specification requires a C-D of "info-package" or it  
requires a different C-D to be used.

Does the following mean the same thing to you?

------
Each Info-Package specification MUST specify the Content-Disposition  
value for each MIME body part in the payload defined by that Info- 
Package specification. Info-Package specifications using a singular  
(not multipart) payload body MUST use a Content-Disposition of "info- 
package" (as this allows the Info-Package payload to be differentiated  
from other payloads carried as body parts on the INFO message). Info- 
Package specifications that use multipart bodies in their payload  
SHOULD use a Content-Disposition value of  "info-package" for each  
part (as this preserves the context of extracted body-parts as being  
part of an Info-Package payload). However, where the application  
requires differentiating parts of a multipart body payload using  
Content-Disposition, an Info-Package specification  MAY use other  
Content-Disposition values for those payload body parts. These Content- 
Disposition values MUST be appropriate to the payload body part and  
application in question, and when considered in the context of the  
Content-Type applicable to that payload body part, MUST enable the  
application to differentiate between payload body parts so as to  
appropriately use those parts.
-------

If that's what you meant, then I disagree. I hold that a C-D of "info- 
package" should only be used at the container level, and that if the  
container is multipart, that the default should be to have meaningful  
C-D values for each part. Once a payload part has been separated from  
its multipart container it isn't all that important for us to be able  
to tell by inspection that it was part of an Info-Package payload, but  
it might be very useful for us to know that the payload is supposed to  
be rendered to the user.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 27 Oct 2009 07:28:59 +0100

Hi, 
  
>What if it isn't in an INFO message?

Protocol error, outside the scope, undefined...

>All the C-D values have some contextual definition. For 
>instance "render" clearly means something different in a sip 
>message than it does in an email message. (For rather stupid 
>reasons we are using "render" for the C-D of the multipart that holds
otherwise unrelated 
>parts of a sip message.)
>
>For example, I might sometime decide to put part/all of an 
>INFO message into a sipfrag, and make that a body part on 
>some other message, perhaps MESSAGE or another INFO.

In that case the INFO message inside the sipfrag is part of the sipfrag
body part payload. The draft doesn't specify what payloads contain - the
individual I-P specifications will do that.

And, in the case of MESSAGE you are not even using the I-P mechanism
when sending the MESSAGE request (eventhough the included sipfrag
payload of course LATER may be used for an INFO request).

>The sipfrag may or may not have the message header that denotes 
>it as an INFO message. The key is that it really doesn't 
>matter. When processing the MESSAGE, the C-D in the sipfrag 
>is not in a context where it is relevant to processing of the 
>MESSAGE. If the body were reconstituted into a full INFO 
>message, and then that message were decoded, then the C-D 
>would be significant.

I totally agree. 

Payload is payload, and whatever is inside the payload is outside the
scope of the info package base specification.

Whoever uses it needs to take care of that, but I don't think it has
anything to do with the I-P mechanism as such.
 
>>>>We do need to say that if an I-P uses non-'info-package' C-D values
for body parts they MUST always be located inside 
>>>>a multipart with C-D 'info-package'. I don't think we need to say
that. IMO it is clearer to 
>>>>*not* say it.
the top level and within a top level 
>multipart of C-D "render".

I don't agree to the C-D "render" part. The top level C-D is always
'info-package'.

Again, it is totally ok to send another SIP message, which contains a
sipfrag with an INFO message and C-D 'render'. But, that SIP message has
nothing to do with the I-P mechanism as such.

>>"In the message body of the INFO request, the main body part
associated with the I-P MUST use a C-D 'info-package' 
>>value, in order to distinguish the body part associated with the I-P
from possible other body parts in the request."
> 
>I'm ok with the above.
> 
>>If there is a need to include multiple body parts associated with the
I-P, or to include a body part for which 
>>the I-P specification defines a non-'info-package' C-D value, such
body parts MUST be collected inside a multipart body 
>>part with a C-D 'info-package' value. The I-P specification MUST
describe what type multipart is to be used in such cases.
> 
>None of the above sentence needs to be normative. The prior statement
is sufficiently normative. This statement could be 
>reworded in to something non-normative. For example:
> 
body parts, and/or body part(s) containing a C-D 
>other than info-package, it can specify that the body part associated
with I-P can be a multipart type."

I can probably live with that.
 
>>An I-P specification SHOULD always specifiy a C-D 'info-package' value
to be used for each individual body part 
>>associated with that I-P, unless another value is required in order
for the remote application to be able to process the 
>>body part information correctly."
> 

I think that it is VERY useful :) I really think that 'info-package'
should be the default C-D value, unless there is a need to use something
else (right eye vs left eye etc).

Maybe it's clear to those of use being part of this discussion, but it
needs to be clear to other readers also.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 27 Oct 2009 08:29:41 +0100

> Sent: 27 October 2009 06:29
> To: Paul Kyzivat
> Cc: Adam Roach; Elwell, John; SIPCORE; Gonzalo Camarillo; 
> Subject: RE: VS: VS: [sipcore] WGLC comments 
[JRE] I think Christer and Paul are talking about different things for "top level". The very top level can be C-D render, and at a lower level, there can be a top level info-package body part with C-D Info-Package.

> needs to be clear to other readers also.
[JRE] I agree with Paul that the sentence is not helpful. I think less is more in this case.

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 27 Oct 2009 09:26:27 +0100

Hi, 

>>unless another value is required in order for the remote application 
>>to be able to process the body part information correctly."
> 
suggesting it should.

That is exactly what I am trying to say.

>Each Info-Package specification MUST specify the 
>Content-Disposition value for each MIME body part in the 
>payload defined by that Info- Package specification. 
>Info-Package specifications using a singular (not multipart) 
>payload body MUST use a Content-Disposition of "info- 
>package" (as this allows the Info-Package payload to be 
>differentiated from other payloads carried as body parts on 
>the INFO message). Info- Package specifications that use 
>multipart bodies in their payload SHOULD use a 
>Content-Disposition value of  "info-package" for each part 
>(as this preserves the context of extracted body-parts as 
>being part of an Info-Package payload). However, where the 
>application requires differentiating parts of a multipart 
>body payload using Content-Disposition, an Info-Package 
>specification  MAY use other Content-Disposition values for 
>those payload body parts. These Content- Disposition values 
>MUST be appropriate to the payload body part and application 
>in question, and when considered in the context of the 
>Content-Type applicable to that payload body part, MUST 
>enable the application to differentiate between payload body 
>parts so as to appropriately use those parts.
>-------

If that text is from the draft, please note that when I submitted the
latest version I indicated that that part is still under discussion.

So, we have not been discussing that specific text. We have been
discussing how things should work, and then I will update the text based
on the outcome.

>If that's what you meant, then I disagree. I hold that a C-D 
>of "info- package" should only be used at the container 
>level, and that if the container is multipart, that the 
>default should be to have meaningful C-D values for each 
>part.

There may be cases where a part is sometimes inside a container (e.g. if
the INFO request also contains other parts), and sometimes the part is
outside a container (e.g. If it is the only body part in the INFO
request), but the part should have the same C-D value in either case.
And, in cases where the part can be outside a container that value must
be 'info-package'.

>Once a payload part has been separated from its multipart container it
isn't all that important for us to be 
>able to tell by inspection that it was part of an Info-Package payload,
but it might be very useful for us to 
>know that the payload is supposed to be rendered to the user.

The whole idea of INFO is to transport application data, so the
application is the only one who needs to know what to do with the data.
If that requires some other C-D value, then fine, but the SIP protocol
does not need to know what will happen with the information.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 27 Oct 2009 09:29:37 +0100

Hi,
 
>>>>An I-P specification SHOULD always specifiy a C-D
>>>>'info-package' value to be used for each individual body part
>>should be the default C-D value, unless there is a need to use 
>>something else (right eye vs left eye etc).
>> 

>[JRE] I agree with Paul that the sentence is not helpful. I think less
is more in this case.

Let's decide upon that once we have the whole text, ok?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Oct 2009 08:30:55 -0400

> multipart with C-D 'info-package'.

I think you are getting unnecessarily fixated on specifying *how* an 
individual I-P specification should employ multipart to achieve its 
objectives. Whatever you say will be redundant to other standards, and 
runs the risk of being inconsistent with them.

IMO this document should only levy requirements on the *one* body part 
associated with the I-P. Going beyond that is simply preaching to the 
designer of the I-P.

In Dean's example there are undoubted many ways to achieve the desired 
end. E.g., I'm sure there is some form of multipart where the recipient 
can associate a role with the *position* of the parts within the 
multipart. (Adam can fill in the details.)

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 27 Oct 2009 13:49:26 +0100

Hi, 

>>>>What if you have an INFO package that needs to convey two 
>>>>image/jpegs one for display to the user's left eye and one for the 
>>>>other's right eye?
>>That is what I tried to cover with the following text that 
>>I suggested in another reply:
>> 
>>"An I-P specification SHOULD always specifiy a C-D 'info-package' 
>>value to be used for each individual body part associated with that 
>>I-P, unless another value is required in order for the remote 
>>application to be able to process the body part information 
>>correctly."
>> 
>>So, in this case the two image/jpeg body parts could have different 
>>C-D 'right-eye'/'left-eye' values. And, they would need to 
>>be inside a multipart with C-D 'info-package'.
> 
>I think you are getting unnecessarily fixated on specifying 
>*how* an individual I-P specification should employ multipart 
>to achieve its objectives. Whatever you say will be redundant 
>to other standards, and runs the risk of being inconsistent with them.

I only say that the body parts must be inside a multipart, which I
thought we had agreed upon.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Oct 2009 10:04:42 -0400

> thought we had agreed upon.

The thing is, there is nothing normative about that. There is no need 
for this draft to talk about multiple parts within the I-P at all.
The attempt to talk about it is resulting in confusion. The confusion 
can be resolved with *more* words or *less* words. I'm suggesting that 
*less* words would be better here.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Oct 2009 09:30:37 -0500

> does not need to know what will happen with the information.

By this logic, the SIP protocol should therefore not say anything  
about the C-D value except when it needs to. And in this case, we have  
shown that SIP needs to say something only about the C-D value of the  
"container", either a singular body part or a multipart whose sub- 
parts are the payload package of the INFO request.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 27 Oct 2009 18:10:13 +0100

Hi, 

>By this logic, the SIP protocol should therefore not say anything about
the C-D value except when it needs to. And in this case, we have shown
that SIP needs to say something only about the C-D value of 
>the "container", either a singular body part or a multipart whose sub-

Yes.

But, I still think it is good to point out that if a body part can be
used as a singular body part, the C-D must be 'info-package'. If a body
part is ALWAYS inside a mulipart container the C-D value can be
whatever.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 27 Oct 2009 18:19:30 +0100

Hi, 

>>>> That is what I tried to cover with the following text that I 
>>>> suggested in another reply:
>>>>

>>>> C-D 'right-eye'/'left-eye' values. And, they would need to be
inside 
>>>> a multipart with C-D 'info-package'.
>>> *how* an individual I-P specification should employ multipart to 
>>> achieve its objectives. Whatever you say will be redundant to other 
>>> standards, and runs the risk of being inconsistent with them.
>> 

That means that users can put body parts associated with the I-P
wherever they want in the message body structure. If we want to allow
that, fine.

>*less* words would be better here.

I agree that less is often better than more. But, I am not sure that the
wording is the main issue at the moment, because it is still unclear to
me whether we
agree on the the general concept.

But, could You suggest some wording, which covers everything that needs
to be covered?

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 28 Oct 2009 01:37:22 +0100

Is it just me, or are we making this all way more complicated that it should be.

Let us start from two principles.

1)	If we find ourselves trying to describe body handling issues in the info-event draft, then either the body handling RFC is broken, or we are going beyond the scope of something that should be generic.

2)	If an info-package has need of multiple data streams that are somehow sent in the same INFO message, then that should be done at the application level and not multiplexed at the SIP level. In my view the multiple MIME bodies are more at the SIP level than at the application level. There will always be some relationship description between the two data streams that multipart MIME cannot describe because it is application specific.

So I would suggest we stick to the rules of:

One body per INFO message. 

One Info-package per INFO message. 

The one body in potential multipart must be clearly labelled as belonging to the Info-package. Other bodies in multipart bodies belong to other dialog usages. I can envisage an entity that works under the rule - everytime you send a message include a Geolocation and associated body.

I would allow the stand MIME multipart/alt etc because to me that is something that come down below the application level, e.g. two alternative transfer syntaxs or something like that.

regards

Keith

> Sent: Wednesday, October 21, 2009 12:42 PM
> section 1), it 
> >>>talks about receiving Info Packages, but I think that
> is 
> we receive 
> >>>[JRE] Yes, that would work, but I am open to suggestions 
> to shorten 
> >>>it, as long as we don't resort to inaccurate formulations
> like 
> >>>we have at present.
> >> 
> >>"receive Info Package" means to receive an INFO associated with an 
> >>Info Package, or something like that...
> >[JRE] If this would make the document more readable (in terms of 
> >avoiding long formulations in many places in the document), 
> it would at 
> >least be an improvement on what we have at present.
> 
> What about if we talked about "indicating for which Info 
> Packages a UA is willing to receive INFO requests"?
> 
> Then it is more clear that the user does not receive an Info 
> Package, bur rather an INFO request associated with an Info Package.
> 
> Regards,
> 
> Christer
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Oct 2009 19:41:52 -0500

> part is ALWAYS inside a mulipart container the C-D value can be

How about:

The top-level container of the INFO Payload body MUST have a content- 
distribution of info-package. Lower-level parts in a multi-part SHOULD  
use content-distribution values appropriate to the application, and  
their values SHOULD be specified by the info-package specification.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Oct 2009 19:47:03 -0500

On Oct 27, 2009, at 7:37 PM, DRAGE, Keith (Keith) wrote:

> 1)	If we find ourselves trying to describe body handling issues in  
> the info-event draft, then either the body handling RFC is broken,  
> or we are going beyond the scope of something that should be generic.
>
> 2)	If an info-package has need of multiple data streams that are  
> somehow sent in the same INFO message, then that should be done at  
> the application level and not multiplexed at the SIP level. In my  
> view the multiple MIME bodies are more at the SIP level than at the  
> application level. There will always be some relationship  
> description between the two data streams that multipart MIME cannot  
> describe because it is application specific.
>

We have described use cases where a multipart body per INFO is  
required, because the INFO payload itself has multiple parts defined  
by the package. For example, a location body(or link) and an image  
body(or link) for geotagged imagery.

> One Info-package per INFO message.

We agree there.

> The one body in potential multipart must be clearly labelled as  
> belonging to the Info-package. Other bodies in multipart bodies  
> belong to other dialog usages. I can envisage an entity that works  
> under the rule - everytime you send a message include a Geolocation  
> and associated body.

I mostly agree, but instead believe that there must be a singular  
object that is marked as info-package, and that it may have sub- 
components with other markings that are marked for other dispositions  
but are still part of the package specification's payload. This  
container might be related, alternative, or any other multiplicative  
MIME structure.

In other words, it's a tree, and everything below the C-D "info- 
package" node on the tree is party of the info-package payload.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 28 Oct 2009 06:52:49 +0100

Hi, 

>>used as a singular body part, the C-D must be 'info-package'. If a 
>>body part is ALWAYS inside a mulipart container the C-D 
>>value can be whatever.
> 
> 
>How about:
> 
>distribution of info-package. Lower-level parts in a 
>multi-part SHOULD use content-distribution values appropriate to the
application, and  
>their values SHOULD be specified by the info-package specification.

Looks good.

I am also ok using SHOULD, but we should add that otherwise the default
value for SIP will be assumed.

Also, will everyone understand what "top-level container" means? Is that
terminology defined somewhere? Is it clear by definition that a
"container" can also be a single body (ie not multipart)?

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 28 Oct 2009 08:16:22 +0100

Yes, I think Dean, Paul and myself are all arguing to keep it simple. One Info-Package per INFO message (that was agreed a long time ago), one body part per Info-Package with C-D Info-Package. What type of body part is left to the Info Package definition and could be multipart, in which case the child body parts would also be defined as part of the Info Package, not in this spec. The less we say about what happens within the Info Package body part, the better. Finally, the single Info-Package body part can be carried with other body parts within a multi-part body part.

John

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 28 October 2009 00:47
> To: DRAGE, Keith (Keith)
> Cc: Christer Holmberg; Elwell, John; SIPCORE; Adam Roach; 
> Gonzalo Camarillo; [email-masked]

---

From: Adam Roach <[email-masked]>
Date: Wed, 28 Oct 2009 08:07:30 -0500

[as an individual]

> Yes, I think Dean, Paul and myself are all arguing to keep it simple. One Info-Package per INFO message (that was agreed a long time ago), one body part per Info-Package with C-D Info-Package. What…

Excellent summary, and I agree with all aspects of it.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 28 Oct 2009 14:31:28 +0100

I'll try to put together some text.

Regards,

Christer

> Sent: 28. lokakuuta 2009 15:08
> To: Elwell, John
> Cc: Dean Willis; DRAGE, Keith (Keith); Christer Holmberg; 
> SIPCORE; Gonzalo Camarillo; 
> > Yes, I think Dean, Paul and myself are all arguing to keep 
> it simple. One Info-Package per INFO message (that was agreed 
> a long time ago), one body part per Info-Package with C-D 
> Info-Package. What type of body part is left to the Info 
> Package definition and could be multipart, in which case the 
> child body parts would also be defined as part of the Info 
> Package, not in this spec. The less we say about what happens 
> within the Info Package body part, the better. Finally, the 
> single Info-Package body part can be carried with other body 
> parts within a multi-part body part.
> >    
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Oct 2009 09:35:45 -0400

YES!

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 28 Oct 2009 14:37:46 +0100

The opera ain't over until we've got an RFC number :) 

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 28. lokakuuta 2009 15:36
> To: Elwell, John
> Cc: Adam Roach; 
> [email-masked]; SIPCORE; 
> Gonzalo Camarillo
> >> Cc: Christer Holmberg; Elwell, John; SIPCORE; Adam Roach; Gonzalo 
> >> (draft-ietf-sipcore-info-events-01) - John E's comments - receive 
> >> Info-Package wording
> >>
> >>
> >>> Is it just me, or are we making this all way more 
> complicated that 
> >>> it should be.
> >>>

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Oct 2009 17:54:52 -0500

Elwell, John wrote:
> Yes, I think Dean, Paul and myself are all arguing to keep it simple.
> One Info-Package per INFO message (that was agreed a long time ago),
> one body part per Info-Package with C-D Info-Package. What type of
> body part is left to the Info Package definition and could be
> multipart, in which case the child body parts would also be defined
> as part of the Info Package, not in this spec. The less we say about
> what happens within the Info Package body part, the better. Finally,
> the single Info-Package body part can be carried with other body

Yes.

--
Dean