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:[EMAIL PROTECTED]
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
[EMAIL PROTECTED] for questions on current sip Use
[EMAIL PROTECTED] for new developments on the application of sip
