Christer Holmberg wrote:
Hi,
- "Render" as the c-d is probably not 100% waterproof, since other
body types may also use it.
Nope, they actually can't. Not in the INFO context. Nor for that
matter in the SUBSCRIBE, NOTIFY, or PUBLISH contexts. If you add a body
with the "render" C-D to one of those message method types,
you're actually telling the far-end to give that body-part to its
"user", which is the package application. INFO is not the same context
as MESSAGE.
So, there is no risk that someone would insert a legacy INFO body part
with "render"?
No matter what we do, legacy info usage will have body parts with "render".
I guess maybe you mean they might *combine* the use of a single INFO for
one legacy INFO usage *and* one info-package??? They can only do that if
we define that they may, which I expect we will not, if we are not
allowing multiple packages. If we define that they can't, its just a
matter of what the error is: either its
- erroneous attempt to use INFO for both legacy and info-package
- or its: too many package bodies for info package
And note that you can screw up with cid references too, by including the
same Content-ID in two different body parts.
People will always find a way to screw up. They will just have to deal
with it until they get smarter.
- I DO still strongly support a new c-d for the package body, but it
seems that others have issues with that.
In my mind, content-disposition is for a value that is basically a
verb. If each package-body needs a new verb to describe giving it to
the package, or even if we create a common verb for all packages
to give that body part to the package, then all we're doing is
re-inventing the wheel. The wheel is the INFO method name and
Info-Package header value, which create the necessary and sufficient
context
with which to extract bodies of disposition "render" (or any specific
disposition defined by the package). The wheel is already capable of
turning, since it appears to be turning fine in legacy INFO
use. We don't need to add hubcaps to make it more expensive. :)
So, you are basically saying: we don't need to do anything as far as
find-the-body-part-with-the-info-package is concerned? We simple specify
that one inserts a Info-Package header with the package name, and that's
it? Whatever C-D/C-T value is used is then defined by the package
itself.
I don't know what he is saying. But IMO we can't have just any old
combination of C-D/C-T be the package.
No matter what, each body part does have a C-D - either explicitly or
implicitly. And each brings its own "verb" with it. If a new one is not
defined and used, and none is specified, then that verb will be "render".
But I don't agree that the C-D is a verb. "render" is a verb. But
"inline", "attachment", "session", "early-session", "icon",
"by-reference" are not verbs. And "alert" and "signal" (from 3204) might
be nouns or verbs.
Thanks,
Paul
Well, since I assume most INFOs will be sent with a single body part
anyway, I guess it would work for those cases...
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
