[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip