Jeroen van Bemmel wrote:
Christer,
Like I wrote before: adding the INFO package as a parameter to
Content-Type solves all this. I don't think C-D is the right header,
because the "disposition" would depend on the semantics of the event
package. We simply need an additional qualifier to disambiguate the
interpretation of the body
If you mentioned this before I missed it.
Its an interesting idea. But I don't think it is technicallyh feasible.
AFAIK the parameters to a C-T must be defined as part of the definition
of the C-T. That wold mean that only yet-to-be-defined C-Ts could be
used for info packages.
Whether C-D is suitable to identifhy the info package depends on whether
it makes any sense to use C-D as an independent control over processing
of the package, in addition to the definition of the package itself. I
certainly haven't seen it that way. I would need a good use case to
convince me that it is a useful thing to do.
Thanks,
Paul
Regards,
Jeroen
Christer Holmberg wrote:
Hi,
So, just to make sure I understand: you are talking about a case
where the INFO does contain a multipart message body, but only one
of the mimes contains an actual info-package (the other mime(s)
contains something else)?
pretty much. And to distinguish those, you need more than C-T.
But I think as we have been discussing, if we only allow one info
package per INFO, then the Info-Package header belongs in the message,
not in the body part.
I don't think that defining Info-Package as a mime header would even
be within the scope of the SIP WG, would it?
My assumption has been that the I-P header is in the SIP message part,
and that causes the problem: in the case of multipart, how to
associate the correct mime with the I-P header? I still think making
assumptions on C-D is very dangerous, considering the very little
experience we have of the C-D header in the first place.
I'll revise your example a bit:
INFO sip:[EMAIL PROTECTED]
To:...
From:...
Some-Header: CID:abcdefg
Info-Package: foo
Content-Type:multipart/mixed
Content-Length:...
--boundary
Content-Type: application/foo-data
Content-Disposition: package;handling=required
foo data
--boundary
Content-ID: abcdefg
Content-Type: application/some-header-data
Content-Disposition: by-reference;handling=optional
some other (non-info package) data
--boundary--
In the above I have used C-D of "package" to identify the part that
contains the info package. That is yet to be determined, but I think it
needs to be well defined, even if it is "render".
Again, I don't think using C-D for the "association" is a good idea.
A more straightforward case would be:
INFO sip:[EMAIL PROTECTED]
To:...
From:...
Info-Package: foo
Content-Type: application/foo-data
Content-Disposition: package;handling=required
Content-Length:10
foo data
...assuming that we don't allow multipart in INFOs, yes.
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
_______________________________________________
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
