Hi,
Yes, it's in the document. The point was that one may have to define
>>>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.
this new MIME type. But, maybe that is not a big problem (I haven't
defined mime types, so I can't tell).
We do need to have a section on what needs to be part of an info package
>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.
definition. The mime type is one thing, for sure.
I guess we should also look at what/if we can re-use from SIP events.
We also need to decide whether info packages should have a version
number system. From experience I think that would be very useful.
Info-Package: foo-package;version=1
...or something like that.
Exactly.
>>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.
Yes.
>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.
Good :)
>So I agree, we need a new value.
Regards,
Christer
_______________________________________________
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
_______________________________________________ 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