Re: draft-ietf-sip-info-events-00: Content-Type vs Info-Package [was RE: draft-ietf-sip-info-events-00: multiple packages per INFO]

Pruning out a lot...

Christer Holmberg wrote:

>> I'd rather not have to be searching all the body parts to that extent
>> to figure it out. The advantage of C-D is that its already necessary to
>> look at that to figure out the role of each body part.
> 
> You will have to look through "all" (not sure there will be too many...)
> body parts anyway.

If implementing for the general case, it will at least be a loop over 
parts of a multipart/mixed, if present, and possibly recursion.

> Even if the info package happens to be in the "first"
> body part you look at, you still need to look through the rest if there
> are body parts with handling=required etc. That is normal multipart
> handling.

See Dale's document with a process oriented take on the C-D stuff.
In general, every UA is going to have to implement that general 
framework for processing body parts, independent of method.

What we are talking about here is potentially another search *in 
addition* to that. Admittedly its not a huge deal, but it starts to mess 
up modularity of implementation.

>> My preference would be for a new value, say "package", "info", or
> "info-package". I think we *might* be able to define that "render" 
>> serves this purpose *for INFO messages*, but I would rather not do that
> because it is indeed asking from trouble and confusion.
> 
> IF we define a new C-D value, which is unique for info packages, I have
> no problem with a C-D based solution. 

OK. That is progress!!!

> But, it would still be more work to define info packages, because you
> would need to specify which C-T value to use.

The document already calls for this:

    7.2.4.  INFO Bodies

    Each Info Package MUST define what type or types of bodies are
    expected in INFO requests.  Such packages MUST specify or cite
    detailed specifications for the syntax and semantics associated with
    such a body.

    Info Packages also MUST define a default MIME type if the "Accept"
    header fails to define any MIME types in the INVITE request.

The wording could be better. There are no explicit IANA considerations 
about registering an INFO package. Its just implied here. Its a little 
confusing here what is intended to be part of the *definition* of a new 
package vs. what is intended to be in the content of a particular 
package instance in an INFO message.

> Maybe not a big issue if
> you can use an existing value, but it's more work if you have to define
> a new value.

If you need to do that, then so be it.

> For example, is there a standardized value which could be
> used for DTMF? Has Cisco registerd the value they use in C-T when
> sending DTMFs? :)

I don't know, but I doubt it.

> My issue is if we want to re-use an existing value, because I don't
> think we for sure can say that couldn't be a case where more than one
> body part has a "render" value (or whatever existing value we would
> choose for info packages).

This is all hypothetical, because we don't have any usages with the new 
info package stuff.

What I guess you are getting at is if there are any existing uses of 
body parts with "render" that might have to coexist with the info 
package in the message. I agree that is a potential problem, since for 
instance people rarely put C-D for a multipart itself, thus defaulting 
to "render".

So I agree, we need a new value.

	Thanks,
	Paul
_______________________________________________
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