Re: [Sip] INFO Framework - one pakage per INFO

[Paul Kyzivat]

Eric,

I don't know if I understand what you are saying. Comments inline.
        Paul

Eric Burger wrote:
Multiple packages breaks the easy, 95% case: what if I have only a 
single body part, and it is the Info Package payload?

If there is a single body part, how do you know it is the Info Package 
payload? If it is a *type* that would be valid as the info package 
payload, that may be circumstantial evidence, but is not a guarantee. 
Certainly the Content-Disposition might have an impact on it, but since 
you haven't defined the use of C-D for info packages, I don't know 
exactly how to treat that.

IMO, if you are going to use a CID reference, then you should *always* 
use a CID reference to define the part, even if it is the only part. If 
you don't want to do that, then I suggest we instead use C-D to define 
the info-package body part, which will then be easy as long as we only 
permit a single info-package.

 You only get
Content-ID when you have MIME. We would have to mandate MIME for every 
new Info Package implementation.

Are you saying we can't have a Content-ID in the sip message itself, 
applying to the whole body? We allow other Content-* headers in sip 
messages. Its always been my interpretation that a SIP message is a 
special case of a mime message, and hence can have any mime headers.

Not a pain in theory, but for speed of adoption, I am willing to bet 
most folks with quasi-proprietary INFO usages, like MSCML and MSML, 
would much rather add a single header (Recv-Info) and use all of the 
rest of the SIP machinery they have in place rather than having to hack 
the application.

If you want to do it that way, then I suggest we use C-D (with a new 
disposition type) to define the info-package, and make that new 
disposition type be the default CD for INFO messages.

As far as handling one good and one bad Info Package: that is actually a 
total non-issue (sorry Hadriel).  The SIP stack understands the Info 
Packages by virtue of indicating Recv-Info, there being an Info-Package 
header, and the body being of the correct type. If there is a single 
Info-Package that was not advertised in a Recv-Info, tough: the whole 
SIP transaction fails (the INFO request). If all of the Info-Packages 
are supported, but the contents of one of them is bad, tough: the SIP 
transaction succeeded (200 OK). It is up to the application to handle 
the particular bad package payload. That is 100% identical to what the 
UAS does if it receives a single well-formed, but bad, INFO request. 
Send the 200 OK and let the application sort out the body.  SIP has done 
its job - don't be a layer violator and conflate an application error 
with a transport error!

I don't think I agree with this, but it could stand some further 
discussion. Are you asserting this behavior is special for INFO? Or that 
it is true for all messages?

In the case of INVITE and UPDATE with SDP session bodies, we certainly 
fail the message because of bad SDP syntax or even semantics when the 
type is right. (488/606 responses for example.)

I don't find anything in 2976 that calls for a success response when the 
content of the body is incorrect.

        Thanks,
        Paul

On Nov 28, 2008, at 2:38 PM, Christer Holmberg wrote:


Hi,

But, my question is still: what makes support of multiple packages
un-simple? Based on the discussions we had on the list before the IETF
meeting, I thought there were no problems.

From a protocol perspective: you'd have to define that more than one
package name can be indicated in an INFO,

Sure. You allow a list of values in the Info-Package header.

that they have to use cid or some means to identify which body part is
which package's,

Based on the e-mail discussions with Paul, I thought each package was
going to have a unique Content-Disposition value. Has that changed?

But, how is package identified in the case there is only one package,
but still multipart (which you DO say must be supported)?

and you'd have to handle the case when the receiver can process
one/some package body parts but not another.  It's not truly "free" to
add this.
It adds time and complexity to the draft.

Isn't the generic handling of body parts described in the body-handling
spec?

For example, what if you received an INFO with two packages of the same
package name?  Is that ok?  Which gets processed first?

That's up to the application using the package to decide.

From a developer's perspective: you'd have to read a bigger RFC and
grok more; and handle more execution paths or at least more logging
events/cases and possibly more configuration than your current INFO
code.

From a product perspective: you'd have to test more scenarios in QA,
train your support staff on more conditions, and document more logging
event cases.

Current INFO use doesn't support this capability, so why do we need to
add it?

AFAIK there is nothing which prevents you to from using multipart with
INFO today, is it?

Trust me, I want all this to be simple, but I also want to be able to
answer when someone asks be why it is not allowed :)

Regards,

Christer


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

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