[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] draft-ietf-sip-info-events-00: Content-Type vs Info-Package [was RE: draft-ietf-sip-info-events-00: multiple packages per INFO]
Hi Paul,
Now I understand what you mean - I mixed up things a little.
The question is: shall we really use the Info-Package header. And, if
so, shall we use it in the way as currently described by the draft?
Shouldn't we use Content-Type to indicate what is in the message body?
After all, we may need Content-Length etc.
So, there would be two options:
1. Use Content-Type to indicate info-package, and within the package
itself then indicate the exact package type
Example: Content-Type: application/info-package
2. Use Content-Type to indicate info-package AND exact package type
Example: Content-Type: application/info-package.foo
...or something like that.
Then, if you have multiple packages, you would use Content-Type:
multipart/mixed on the SIP level, and Content-Type
application/info-package within the mimes (normal multipart handling).
Regards,
Christer
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Sent: 22. lokakuuta 2008 16:36
To: Christer Holmberg
Cc: SIP IETF; Eric Burger
Subject: Re: [Sip] draft-ietf-sip-info-events-00: multiple packages per
INFO
Christer Holmberg wrote:
> Hi,
>
> Doesn't the body handling draft say that one MUST be able to parse
> multipart message bodies?
>
> So, I don't think we should forbid the usage of multiple packages.
> There MAY be use-cases where it is useful, so...
>
> I also think that the negotiation of multipart support is more
> generic, so such mechanism should not be bound to INFO packages.
My thinking was:
If multipart is used to convey multiple info packages, then each part
that contains an info package should contain an Info-Package header
stating which package it is. That was an alternative to Eric's proposal
that all the packages be listed at the outer level.
Then the question remained: in this case should there be an Info-Package
header at the outer level, and if so, what should it contain?
Answering that question is what led to my proposing the "multipart"
package.
I guess an alternative would be for the Info-Package header at the outer
level to list all the packages contained, in no particular order, and
then for the individual parts to contain an Info-Package describing that
part.
I do think it is necessary for there to be an Info-Package header at the
outer level, to distinguish this from a legacy use of Info.
Thanks,
Paul
> Regards,
>
> Christer
>
>
>
>
>
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
> Paul Kyzivat
> Sent: 21. lokakuuta 2008 17:45
> To: SIP IETF; Eric Burger
> Subject: [Sip] draft-ietf-sip-info-events-00: multiple packages per
> INFO
>
> Re the question about multiple packages per INFO:
>
> There MUST be exactly one Info Package type listed per
Info-Package
> header. Multiple Info-Packages per INFO message are disallowed.
>
> [EDITOR NOTE: Really? Why not multiple Info-Packages, in a
> multipart/mime? Well, I thought of one: it is hard to
disambiguate.
> For example, take an INFO message with an Info-Package: key_image,
> caller_picture. I then have a multipart/mime with, you guessed
it,
> an image/jpeg and an image/jpeg. I would offer we do allow this
and
> require the MIME parse order of the body match the order of the
> Info-
> Package enumerations; if you have too many packages or body parts
or
> they do not align, you barf. However, I timed out on this and
thus
> we will have to wait for the next version for me to flesh this
out.
> If we do do this, then we'll reference RFC 3261 as updated by
> draft-ietf-sip-body-handling to require multipart MIME handling.]
>
> How about defining an initial package type of "multipart". It allows
> only content-type multipart/mixed. Then each contained type must have
> its own Info-Package header. If you want to allow multiple packages
> per INFO then you need to negotiate support for "multipart". Or maybe
> we require support of multipart if you support any other package type.
>
> Thanks,
> Paul
> _______________________________________________
> 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