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

[Eric Burger]

Again, this is why I said, "technically easy."



On Nov 28, 2008, at 4:43 PM, Christer Holmberg wrote:

However, it mean more package work, which the *work group* (not me) said, "hard - please punt."

Hi,

Multiple packages breaks the easy, 95% case: what if I have only a

single body part, and it is the Info Package payload?

We DO say that one must support multipart, don't we? So, even in the
one-package-only case one needs a way to find that Info Package.

How is that done, and why doesn't that work also for multiple info
packages? That's all I need to know :)

Regards,

Christer



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

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