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
_______________________________________________
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
