Dean Willis wrote:
Hadriel Kaplan wrote:
-----Original Message----- From: Christer Holmberg
[mailto:[EMAIL PROTECTED] Sent: Sunday, November 30,
2008 4:58 PM
Sounds ok. But, doesn't the Info-Package header syntax still have
to allow the piggy-backer to: 1) List multiple info packages 2) For
each listed info package, provide the cid
Nope. We've already said we're going to not bother doing multiple
packages. (or at least I think people have agreed with that, I hope)
So the next question was on multiple body-parts. Since INVITE,
UPDATE, PRACK, SUBSCRIBE/NOTIFY, MESSAGE, and legacy INFO, can all
carry bodies and not one of them defined a CID mechanism for the body
part that was specific to their message method context, we shouldn't
need to for INFO either.
No, I think this means we messed up every one of those methods when we
didn't address the multiple-body problem earlier. The reason it isn't
exploding yet is that the specifications are ahead of the
implementations; when the implementations catch up with the broken
specs, we'll have failures of biblical proportion.
Sometimes we can demux on body-type. This is obviously not a universal
solution. We really need a generic solution that works for all methods,
not just INFO.
Exactly.
Regardless of whether Eric thinks it was appropriate or not,
Content-Disposition was recruited for this purpose in 3261 via its use
for "session", "alert", and "icon". And it has been used in a few other
RFCs in a similar fashion.
For lack of anything better, to remain backward compatible, we probably
need to consider C-D of "render" as identifying the principal body part
used by MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH, and presumably *legacy*
INFO. That works in the case where there is no multipart.
When you introduce multipart to any of those, unless you are careful to
put some other C-D on the multipart itself, it becomes ambiguous whether
the multipart as a whole is the principle body for the method, or if it
should be opened and a part within it sought, because the default
disposition for the multipart will be "render". We could probably fix
this by having a special rule for multipart/mixed with "render".
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
