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

[Eric Burger]

Multiple packages breaks the easy, 95% case: what if I have only a single body part, and it is the Info Package payload? You only get Content-ID when you have MIME. We would have to mandate MIME for every new Info Package implementation.

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

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. 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!

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.

spec?

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

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

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
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