Re: INFO Framework - one pakage per INFO

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