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