Subject: [Sip] comments on draft-ietf-sip-info-events-01

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 Nov 2008 00:35:21 -0500

General comments:

* I really dislike how the meaning of UAC/UAS has been changed from
RFC3261. This is really confusing and I think complicates presentation
of the material

* I think the negotiation of supported types is not sufficiently well
defined. We're going to run into many of the hard cases we ran into for
offer/answer - so lets address them now. What happens if, in an early
dialog, there is a reverse UPDATE that changes the send/recv packages,
and then a 2xx to the INVITE arrives with a different set? Which takes
priority? What about mid-dialog exchanges that are rejected, do we
revert back to the previous set? Indeed I don't think we should model 
this on O/A at all.

* The draft allows for multiple packages to be in a single INFO. Egads,
that just complicates life. Multipart support is already a mess in SIP.
Do we REALLY need this? Cant you just send two INFO requests? If a
single INFO has a single package, we also don't need the cid mechanism.
Less is more (I know this had some discussion already on the list...)

* I don't like the behavior whereby, if a UA receives an INFO with an
unknownn package, we terminate the dialog. Why so extreme?

* I know we've discussed this one, but I disagree that the event
packages HAVE to be specification required. I think we should allow for
vendor prorpietary usage. My suggestion is to define a vendor tree for
info event packages.

* Section 7.1 includes some of the considerations in the info-litmus 
draft, but only some. We should either fold it all in or else split it 
all out. In either way, its really important to separately consider the 
question on whether the exchange should take place in the signaling vs. 
media path, and then if signaling, whether to use INFO, event pakcage, 
or new method, etc.

Specific comments:

> The purpose of
>    the INFO message [RFC2976], on the other hand, is to carry
>    application level information along the SIP signaling path.

There is no clear definition here of 'application'. I think that merits
some discussion.

>  Info Package negotiation is an offer/offer mechanism.  The UAC may
>    offer a set of Send-Info and Recv-Info packages in the initial
>    INVITE, the UAS offers its set of Send-Info and Recv-Info pacakges in

I think its a bad idea to use the term 'offer/offer' since it sounds
like this is related to the SDP offer/answer mechanism. Suggest the word
'propose' instead of offer.

> In this section, "UAC" is the User Agent Client from the perspective
>    of the INVITE method.  That is, it is the User Agent (UA) that sends
>    the initial INVITE method request.  This may be somewhat confusing if
>    the User Agent Server (UAS) from the perspective of the INVITE method
>    sends an INFO method request.

This contradicts the definition in rfc3261; the role of UAC and UAS are
on a per-transaction basis, not fixed for the duration of the call based
on the initiate INVITE that established the session!

> The
>    general rule is before a UA may begin sending INFO methods with a
>    given Info Package, the sending UA must first indicate it wants to
>    send the Info Package by listing it in a Send-Info header in the most
>    recent dialog negotiation and the receiving UAS must positively
>    indicate it is willing to receive the Info Package by listing it in a
>    Recv-Info header in the most recent dialog negotiation.

what if the previous exchange omitted Send-Info or Recv-Info, but an
exchange prior had contained it?

> A UA MAY list multiple packages by enumerating the package name(s),
>    separated by commas, as values for the Send-Info and Recv-Info
>    headers in the session establishment.

not just at establishment, but at any time.

> Such Info Package capability negotiation MUST occur within the
>    context of a single session negotiation exchange.  

this is very vague in terms of what it means.

> Similar rules apply for late Send-Info / Recv-Info negotiation, such
>    as an empty INVITE, followed by an offer in the 200 OK and the
>    response in the ACK.

In which case, this should be defined more generically rather than
writing it in terms of INVITE and just say, 'oh, it works in other use
cases too'

> The INFO message MUST NOT change the state of the SIP dialog.  The
>    only exception to this rule is for specific failure responses as
>    documented in RFC 5057 [RFC5057], which may cause the INVITE dialog
>    to terminate.

We should clearly enumerate what this is. Can we update Contacts? Is
INFO a target refresh request? What about P-A-ID? Or From/To URI?

> OPTIONS Processing
> 
>    A UAC, the sender of the OPTIONS request, MAY include Send-Info and
>    Recv-Info headers, populated appropriately for the packages the UAC
> 
> 
> 
> Burger, et al.             Expires May 7, 2009                 [Page 14]
> 
> Internet-Draft               INFO Framework                November 2008
> 
> 
>    supports.  The UAS MAY include its set of Send-Info and Recv-Info
>    packages. 

I think you should make this a SHOULD (inclusion of Send/Recv Info).

> Because there are numerous situations where a SIP method request can
>    carry a payload, any INFO method may contain body parts in addition
>    to the payload associated with the Info Package. 

hmm, why? This complicates things. KISS.

> 9.5.  Creation of the Info Packages Registry

You should show an example of what the actual table in the IANA registry 
looks like and include the 'nil' there.
> There are no specific security issues for this mechanism, beyond
>    those already applicable to SIP-based session signaling.  In
>    particular, if one does not protect the SIP signaling from
>    eavesdropping or authentication and repudiation attacks, for example
>    by using TLS transport,

I disagree with this statement. There are new considerations here - 
we're now exchanging APPLICATION data in SIP, and this increases 
sensitivity of the data depending on the application. For example 
considering using INFO to send typical form-data, like a credit card 
number....

Minor:

> [RFC2976] to include explicit negotiation of supported Info Packages
>    in the INVITE transaction and indication of the Info Package to use
>    by using a new header field in the INFO request.
> 
>       [RFC EDITOR NOTE: Please replace "This draft proposes replacing"
>       with "This draft replaces" in the final edition.]

there is no need to make rfc-ed do this work. Write the document to
reflect what it is meant to look like as an RFC.

> The signaling path for the INFO method is the signaling path
>    established as a result of the call setup.

dialog setup

> a signaling
>    path involving SIP proxy servers that were involved in the call setup
>    and added themselves to the Record-Route header on the initial INVITE
>    message.

or b2bua's.

> The UAS MUST send a 481 Call Leg/Transaction Does Not Exist message
>    if the INFO request does not match any existing dialog.

this repeats already-defined behavior in rfc3261. Remove.

> By definition, such uses
>    have relied on either static local configuration or implicit context
>    determination based on the body Content-Type or Content-Disposition
>    value, or some proprietary mechanism. 

'have relied on..." you don't say what they've relied on these FOR.

> 7.2.7.  Rate of notifications

I think this should be rate of INFOs

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

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

---

From: Dean Willis <[email-masked]>
Date: Mon, 17 Nov 2008 00:07:26 -0600

> vendor prorpietary usage. My suggestion is to define a vendor tree for

I'd be okay with this.

> hmm, why? This complicates things. KISS.

Because an SIP request can carry AIB or e2m (or other such extension,  
like SAML assertions)) body parts, there is the possibility that an  
INFO might also get such attachments. We can't stop this without  
deprecating the behavior of those specifications. We must therefore be  
prepared to determine which body part(s) is(are) associated with the  
INFO package, and which are something else.

Can we do this based only on the MIME body type?  Yes, in the cases we  
know about so far. Do we have a way to assure this given the  
probability of future specs

> You should show an example of what the actual table in the IANA  
> registry looks like and include the 'nil' there.

And I assure you, the IESG will notice this weakness. We do need to  
beef this discussion up.

--
Dean

---

From: Eric Burger <[email-masked]>
Date: Mon, 17 Nov 2008 06:38:40 -0600

Thanks for the review!

Responses inline.

> RFC3261. This is really confusing and I think complicates presentation

The sense of UAC/UAS has not been changed at all, which is why it is  
complicated.  The document talks about a situation where (for example)  
a phone (UAC) calls a B2BUA (UAS) and then that selfsame B2BUA (UAC)  
sends an INFO to the phone (UAS).  Adam suggested a better way to  
describe the scenarios that will eliminate this confusion.  Namely,  
since this document focuses on INFO, when we talk about a phone  
calling a B2BUA, we will talk about the calling UA and the called UA.

> revert back to the previous set? Indeed I don't think we should  
> model this on O/A at all.

Lots of people noticed this, and I will fix it.

> Less is more (I know this had some discussion already on the list...)

I was 80% finished the text of why we had only one package per INFO  
when I realized an implementation would need 99% of the parsing  
machinery to deal with multiple packages per INFO 100% of the time.

The only cogent argument I have heard for why it would be nice to have  
one package per INFO is to be able to hand off the entire body to a  
subprocess dedicated to processing the info package type. However,  
that process would need to parse out its relevant body part, which  
makes this identical to handing the entire body to multiple  
subprocesses, which means one instantly gets processing multiple  
packages per INFO free.  Another way of implementing this is to have  
the SIP stack parse the multiple body parts to find the relevant INFO  
body part, but again one finds that you again get multiple packages  
per INFO free.

I will admit to a subversive reason for allowing multiple packages per  
INFO: it is a way of ensuring no one confuses a SIP transaction with  
an application transaction. Check out MSCML.  There is a lot of  
application logic to handle the fact an INFO transaction can succeed  
while the application transaction fails.  In this case, one had better  
return a 200 OK for the INFO request, and then some other indication  
(most likely an INFO in the reverse direction) of the problem with the  
payload.  Otherwise, I can envision people writing packages with  
language, "If you don't like the body for this transaction, send a 498  
SIP response code."

> unknownn package, we terminate the dialog. Why so extreme?

Because it represented a protocol failure.  However, note the tense of  
the last sentence.  A race condition was identified which hints that  
we really should just ignore unknown packages.  However, we want to  
make sure we have the strongest language that a UAC MUST NOT send an  
INFO the UAS has not indicated it will receive.

> vendor prorpietary usage. My suggestion is to define a vendor tree for

Theoretical world: give folks a vendor tree because there are truly  
proprietary usages that no one will care about; the only thing we care  
about is not colliding with the proprietary info package name.

Real world: this is where we get (just looking at THIS e-mail) X- 
Original-To, X-Virus-Scanned, X-Spam-Flag, X-Spam-Score, X-Spam-Level,  
X-Spam-Status, X-Mailer, X-Beenthere, X-Mailman-Version, of which 3  
are really used by the Internet infrastructure.  That is, they are  
beyond common usage and should be specified somewhere.

Also real world: no matter what we say, people will do proprietary  
usages.  I would offer specification required encourages some  
documentation - the bar is VERY low to publish an Individual  
Informational Proprietary document or, better yet, a link to the  
documentation on your corporate web site.

Obviously, this is not an issue for me personally to decide.  What  
does the work group want to do?

> draft, but only some. We should either fold it all in or else split  
> it all out. In either way, its really important to separately  
> consider the question on whether the exchange should take place in  
> the signaling vs. media path, and then if signaling, whether to use  
> INFO, event pakcage, or new method, etc.

Yup - as said two weeks ago, I forgot your document.  Definitely  
should be folded in.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 17 Nov 2008 13:39:41 +0100

To comment on the multipart body question below, my understanding of the
requirement from the previous discussion is that it does not come from
the need to send two info packages at the same time.

Rather it comes from the need to send an info package plus some other
associated but yet to be described message body that happens to be
needed to be sent at the same time (e.g. info package containing a
Geolocation header pointing to a geolocation body in the same message).
If we could eliminate this, we could get rid of it, but I suspect we
cannot.

Given this, the support of multiple packages comes for free, so why
eliminate it.

However, whatever the result of this discussion, that does not mean that
we should in any sense make draft-ietf-sip-body-handling optional for
any method - it has to remain a mandatory part of RFC 3261. 

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jonathan Rosenberg
> Sent: Monday, November 17, 2008 5:35 AM
> To: IETF SIP List
> Subject: [Sip] comments on draft-ietf-sip-info-events-01
> 
> General comments:
> 
> * I really dislike how the meaning of UAC/UAS has been 
> changed from RFC3261. This is really confusing and I think 
> complicates presentation of the material
> 
> * I think the negotiation of supported types is not 
> sufficiently well defined. We're going to run into many of 
> the hard cases we ran into for offer/answer - so lets address 
> them now. What happens if, in an early dialog, there is a 
> reverse UPDATE that changes the send/recv packages, and then 
> a 2xx to the INVITE arrives with a different set? Which takes 
> priority? What about mid-dialog exchanges that are rejected, 
> do we revert back to the previous set? Indeed I don't think 
> we should model this on O/A at all.
> 
> * The draft allows for multiple packages to be in a single 
> INFO. Egads, that just complicates life. Multipart support is 
> already a mess in SIP.
> Do we REALLY need this? Cant you just send two INFO requests? 
> If a single INFO has a single package, we also don't need the 
> cid mechanism.
> * I don't like the behavior whereby, if a UA receives an INFO 
> with an unknownn package, we terminate the dialog. Why so extreme?
> 
> 
> * I know we've discussed this one, but I disagree that the 
> event packages HAVE to be specification required. I think we 
> should allow for vendor prorpietary usage. My suggestion is 
> to define a vendor tree for info event packages.
> 
> 
> * Section 7.1 includes some of the considerations in the 
> info-litmus draft, but only some. We should either fold it 
> all in or else split it all out. In either way, its really 
> important to separately consider the question on whether the 
> exchange should take place in the signaling vs. 
> media path, and then if signaling, whether to use INFO, event 
> pakcage, or new method, etc.
> 
> 
> Specific comments:
> 
> 
> 
> > The purpose of
> There is no clear definition here of 'application'. I think 
> that merits some discussion.
> 
> >    INVITE, the UAS offers its set of Send-Info and 
> Recv-Info pacakges 
> > in
> 
> I think its a bad idea to use the term 'offer/offer' since it 
> sounds like this is related to the SDP offer/answer 
> mechanism. Suggest the word 'propose' instead of offer.
> 
> This contradicts the definition in rfc3261; the role of UAC 
> and UAS are on a per-transaction basis, not fixed for the 
> duration of the call based on the initiate INVITE that 
> established the session!
> 
> 
> > The
> what if the previous exchange omitted Send-Info or Recv-Info, 
> but an exchange prior had contained it?
> 
> In which case, this should be defined more generically rather 
> than writing it in terms of INVITE and just say, 'oh, it 
> works in other use cases too'
> 
> We should clearly enumerate what this is. Can we update 
> Contacts? Is INFO a target refresh request? What about 
> P-A-ID? Or From/To URI?
> 
> > OPTIONS Processing
> > 
> > > 
> You should show an example of what the actual table in the 
> IANA registry looks like and include the 'nil' there.
> I disagree with this statement. There are new considerations 
> here - we're now exchanging APPLICATION data in SIP, and this 
> increases sensitivity of the data depending on the 
> application. For example considering using INFO to send 
> typical form-data, like a credit card number....
> 
> 
> Minor:
> 
> there is no need to make rfc-ed do this work. Write the 
> document to reflect what it is meant to look like as an RFC.
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 Nov 2008 10:34:32 -0500

> Given this, the support of multiple packages comes for free, so why

Free? Certainly not.

If, as an implementor, all I care about is INFO, and I don't have any 
other use case for multipart (which, as of now, are mostly niche uses 
and are not common), I'll now NEED to implement multipart for INFO.

So, I don't have a problem saying that INFO can contain multiple bodies 
as any message can, but I do have a problem with the idea that the INFO 
framework ITSELF allows multiple packages per INFO.

-Jonathan R.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 17 Nov 2008 16:47:24 +0100

Is this a concern just for legacy usage or is there a wider concern.

draft-ietf-sip-body handling updates RFC 3261:

------------------------------------------------------------------------
SIP Working Group                                           G. Camarillo
Internet-Draft                                                  Ericsson
Updates: 3261, 3204, 3459                               October 29, 2008
(if approved)
Intended status: Standards Track
Expires: May 2, 2009

     Message Body Handling in the Session Initiation Protocol (SIP)
                  draft-ietf-sip-body-handling-04.txt
------------------------------------------------------------------------

4.2.  Mandatory Support for 'multipart' Message Bodies

   For all MIME-based extensions to work, the recipient needs to be able
   to decode the multipart bodies.  Therefore, SIP UAs MUST support
   parsing 'multipart' MIME bodies, including nested body parts.  In
   particular, UAs MUST support the 'multipart/mixed' and 'multipart/
   alternative' MIME types.
-------------------------------------------------------------------------

As this draft is hopefully going to get published before or at the same time as info-events, I would expect all new info package implementations to support - afterall, it is mandatory.

regards

Keith

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Monday, November 17, 2008 3:35 PM
> To: DRAGE, Keith (Keith)
> Cc: IETF SIP List
> Subject: Re: [Sip] comments on draft-ietf-sip-info-events-01
> 
> 
> 
> > To comment on the multipart body question below, my 
> understanding of 
> > the requirement from the previous discussion is that it 
> does not come 
> > from the need to send two info packages at the same time.
> > 
> If, as an implementor, all I care about is INFO, and I don't 
> have any other use case for multipart (which, as of now, are 
> mostly niche uses and are not common), I'll now NEED to 
> implement multipart for INFO.
> 
> So, I don't have a problem saying that INFO can contain 
> multiple bodies as any message can, but I do have a problem 
> with the idea that the INFO framework ITSELF allows multiple 
> packages per INFO.
> 
> -Jonathan R.
> 
> 
> --

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Nov 2008 11:50:30 -0500

I'm with Jonathan - the latest INFO draft is 41 pages long.  RFC 3428 for MESSAGE method was 18 pages long.  The entire Subscribe/Notify RFC 3265 was only 38 pages long.
Something ain't right.

Of course a SIP message can have multiple bodies.  That doesn't mean we have to define the whole thing or make it explicit in this doc.  If Sub/not didn't specify it, why does INFO have to?

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> DRAGE, Keith (Keith)
> Sent: Monday, November 17, 2008 10:47 AM
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> As this draft is hopefully going to get published before or at the same
> time as info-events, I would expect all new info package implementations
> to support - afterall, it is mandatory.
>
> regards
>
> Keith
>
>

---

From: Eric Burger <[email-masked]>
Date: Mon, 17 Nov 2008 11:03:30 -0600

SUBSCRIBE/NOTIFY didn't specify it because (1) the Event: header as  
specifies ensures only a single payload and (2) implementations may  
find themselves hopelessly broken when a legal, RFC 3261, multipart  
payload shows up.

INFO has to specify it so we do not barf.

The "what" the INFO document is doing that SUBSCRIBE/NOTIFY did not  
have to do is explain why we have INFO at all.

On Nov 17, 2008, at 10:50 AM, Hadriel Kaplan wrote:

>
> I'm with Jonathan - the latest INFO draft is 41 pages long.  RFC  
> 3428 for MESSAGE method was 18 pages long.  The entire Subscribe/ 
> Notify RFC 3265 was only 38 pages long.
> Something ain't right.
>
> Of course a SIP message can have multiple bodies.  That doesn't mean  
> we have to define the whole thing or make it explicit in this doc.   
> If Sub/not didn't specify it, why does INFO have to?
>
> -hadriel
>
>
>> Internet-Draft                                                   
>> Ericsson

---

From: Bob Penfield <[email-masked]>
Date: Mon, 17 Nov 2008 11:59:27 -0500

I agree with Hadriel and Jonathan. I don't think we need to send INFO with multiple packages.

If you have an application that needs to send multiple body parts, then define an Info-Package that contains multiple body parts and describe what each of those are. Then multiple part would only be required for UAs that need to support that package.

cheers,
(-:bob

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hadriel Kaplan [[email-masked]]
Sent: Monday, November 17, 2008 11:50 AM
To: DRAGE, Keith (Keith); Jonathan Rosenberg
Cc: IETF SIP List
Subject: Re: [Sip] comments on draft-ietf-sip-info-events-01

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Nov 2008 12:00:56 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
>

Right now INFO works, and no such problem exists.  What does Subscribe/Notify do to cover this problem?

> probability of future specs

Future specs can fix themselves by specifying what to do, if they support mime content types which could be that ambiguous.  The base INFO spec doesn't need to fix it for all, if it's only a problem for some possible future use no one actually has.

-hadriel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 Nov 2008 12:14:13 -0500

Eric Burger wrote:
> specifies ensures only a single payload and (2) implementations may find 
> themselves hopelessly broken when a legal, RFC 3261, multipart payload 
> shows up.
> 

This is bogus.

We do not *NEED* to define what happens when INFO has multiple info 
packages in it. If the syntax allows just one, and the spec allows just 
one, there can only be one.

And I will reiterate that, this is a separate question from whether an 
INFO can contain multipart, where one body is an INFO package object and 
the other is for a different reason (AIB). We are debating whether the 
INFO framework itself allows for multiple packages per INFO.

Less is more. We don't need more features just because they are 'free' 
from a hypothetical standards perspective. This argument is also bogus.

-Jonathan R.

---

From: Eric Burger <[email-masked]>
Date: Mon, 17 Nov 2008 13:42:54 -0600

If you have an application that sends multiple body parts, it already  
MUST package it into a single body part (multipart/mixed, most  
likely). That's not the issue.

On Nov 17, 2008, at 10:59 AM, Bob Penfield wrote:

> If you have an application that needs to send multiple body parts,  
> then define an Info-Package that contains multiple body parts and  
> describe what each of those are. Then multiple part would only be  
> required for UAs that need to support that package.
>
> cheers,
> (-:bob
>

---

From: Eric Burger <[email-masked]>
Date: Mon, 17 Nov 2008 13:45:53 -0600

It is not a theory. Once you have to explicitly identify the body part  
for an Info Package, you can identify the body part for ANY Info  
Package.

Can you propose a simpler way to unambiguously identify the body part  
with a mechanism other than Content-ID?  That will help me see a way  
how one would have to add work to handle multiple body parts, as  
demanded by RFC 3261.

On Nov 17, 2008, at 11:14 AM, Jonathan Rosenberg wrote:

> packages in it. If the syntax allows just one, and the spec allows  
> just one, there can only be one.
>
> And I will reiterate that, this is a separate question from whether  
> an INFO can contain multipart, where one body is an INFO package  
> object and the other is for a different reason (AIB). We are  
> debating whether the INFO framework itself allows for multiple  
> packages per INFO.
>
> Less is more. We don't need more features just because they are  
> 'free' from a hypothetical standards perspective. This argument is  
> also bogus.
>
> -Jonathan R.
>
>
> --

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 Nov 2008 14:58:16 -0500

If there is a single body, then the body part of the INFO is for the one 
and only package. If there are multiple bodies, one would be for the 
INFO package, and the rest for something else. I am fine with a cid in 
this case. But there is STILL just one info package per INFO message, 
and the only reason for multipart would be reasons having nothing to do 
with INFO framework.

-Jonathan R.

Eric Burger wrote:
> for an Info Package, you can identify the body part for ANY Info Package.
> 
> with a mechanism other than Content-ID?  That will help me see a way how 
> one would have to add work to handle multiple body parts, as demanded by 
> RFC 3261.
> 
>> INFO can contain multipart, where one body is an INFO package object 
>> and the other is for a different reason (AIB). We are debating whether 
>> the INFO framework itself allows for multiple packages per INFO.
>>

---

From: Dean Willis <[email-masked]>
Date: Mon, 17 Nov 2008 13:59:32 -0600

> debating whether the INFO framework itself allows for multiple  

But if there are multiple body parts (only one of which is an INFO  
body) , INFO requires a mechanism for finding the right body part.

We can't delimit this based on the MIME type for the same reason we  
can't just do a one-to-one map between INFO and MIME -- sometimes a  
single MIME type is used in different ways for different applications.

So far, the only reasonable way proposed to identify the MIME body  
associated with an INFO package is a MIME CID identifier that points  
from the INFO package header to the body. According to this model,  
INFO compliant UAs must understand multipart MIME (as the body  
handling draft requires), and they must understand Content-ID.

If we have this mechanism, it works just as effectively and  
automatically for multiple INFO bodies per message as it does for a  
singular body per message.

We could probably say nothing about singular or multiple INFO package  
bodies per INFO message in the draft, and nothing would change in the  
mechanism at all:

1) Parse header
2) If current header is an Info package identifier, parse out the CID
3) Search through the bodies until you find the right CID
4) If there are more headers, go to step 1

One could probably complicate this by adding a state about "But if  
you've already found one Info package header, ignore all subsequent  
ones and their associated body parts", but that actually makes the  
logic MORE complicated, not less.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Nov 2008 17:10:52 -0500

> body) , INFO requires a mechanism for finding the right body part.

Isn't there some rule somewhere about the order of the body parts making a difference if multiples of the same type/disp are received?  Or am I having a memory corruption?
Like since the INFO package is the generator of the message, can't we just say the first/top-most one is the package's?  Maybe I'm dreaming.

> single MIME type is used in different ways for different applications.

*Only* devices supporting that specific INFO package would need to care.  Since we'll have an indication/negotiation of support for specific INFO packages, only devices which implement support for such packages would need to discern such an ambiguity.  We don't have this problem right now, because we don't have such a package in mind.  Ergo we don't need to solve it.  Let the specific package definitions do it if they need it - make them pay the price for their issue.

-hadriel
p.s. and I'm only arguing to reduce this thing because the main carrot for this draft was to not make it much more work for developers from current INFO usage.  It doesn't have to be perfect - just good enough.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 17 Nov 2008 23:07:13 +0000

What about two or more instances of the SAME Info package? Do we need to
say anything about that, and if so what? If we limit it to one Info
package, this issue doesn't arise.

John 

> Behalf Of Dean Willis
> Sent: 17 November 2008 20:00
> To: Jonathan Rosenberg
> Cc: IETF SIP List