Christer,
I just think using a single C-T for all packages is a bad idea.
Its quite likely that some packages will support multiple content types.
Its also quite likely that some/many/most packages will want to use
*existing* content-types. We already have a mechanism for negotiating
support for content-types. We should exploit that, not discard it here.
We already have several other ways to skin this cat:
- use cid references and the by-reference c-d for the package body
- define "render" as the c-d for the package body in an INFO
- define a new c-d (e.g. "info-package") for the package body
IMO *all* of those are preferable to bastardizing the C-T for the purpose.
Thanks,
Paul
Christer Holmberg wrote:
Hi,
Most of the multipart cases I've seen have worked fine, because the
Content-Type normally tells everything the receiver needs to know
(e.g.
SDP, ISUP, XML-whatever, etc).
I guess the potential problem is when you send things like image/jpeg
etc.
The scary part is that demuxing based on C-T *does* work in a lot of
simple cases, so it may be used widely. But it doesn't work in general.
To work generally, it will be necessary to first demux based on C-D.
If we have a lot of implementations basing things on C-T, then they may
not be inserting, or doing the necessary processing for C-D. That means
they are likely to break in more complex cases going
forward.
We can still use C-D.
For info packages, I still don't understand why we can't specify a
common content-type value. The body part contains an info package, so
the content-typ is info something.
If you chose a standard C-T for all info-packages, that constrains the
syntax that it may contain. Yet each package is going to want to choose
the syntax(es) that it uses. And some of them will want to
be standard ones, such as image/jpeg. To deal with that your "standard"
info C-T would have to be a container for an arbitrary mime type. So you
have simply pushed the problem down a level.
The syntax can be very simple - for example package name plus a binary
string which can contain whatever (the package defines the exact syntax
within that binary string). It works a little like the SDP fmtp
attribute.
That way we would solve the how-to-find-info-body-parts problem, and
whatever common stuff then needs to be done for SIP can be done
outside the work of info.
IMO its a really bad way to go.
It's simple, and it does not require support of new parameter,
content-ids etc.
Regards,
Christer
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Hadriel Kaplan
Sent: 3. joulukuuta 2008 0:42
To: Dean Willis
Cc: SIP List
Subject: Re: [Sip] Multiple body-parts in one INFO
-----Original Message-----
From: Dean Willis [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 02, 2008 4:07 PM
Seriously - you expect us to put in a Require header
option-tag when
multi-part mime is used, so it can fail against every SIP device
that is deployed on the planet??
If understanding how to decode the multipart MIME is
critical to the
success of the request, then I expect the request to fail
if the UAS
cannot decode it. Further, I want it to fail predictably in
a way that
the request originator can understand, not in some cryptic
application/version dependent way.
What you are suggesting is that to use multi-part MIME in current SIP
methods, we cannot rely on currently deployed system behavior. So
you're basically proposing we either:
1) Never do multi-part MIME.
2) Do a new SIP version.
I'm ok with doing #1, but I don't think things are *that* bad anyway.
I think we can rely on systems to behave sanely enough to do a
backwards-compatible multi-part that should work in most cases - for
the cases it doesn't, I think it will fail explicitly (with a failure
response), and *then* one can argue if you can re-send it without the
other body parts, or if you just fail the call hard. But at least by
then you've actually hit an error, and it's not ALL deployed systems
that will have the problem.
Although I do wonder about how much of a Red Herring this topic is -
what exact use-cases do you guys have for multi-part bodies in
SUBSCRIBE, NOTIFY, PUBLISH, and INFO that is not actually defined in
a package for them? Or are we in some theoretical La-La land? [no
offense meant - I like La-La land]
-hadriel
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
