Hi, >Its not a matter of Info-Package *vs* Content-Type - Its Info-Package >*plus* Content-Type. Previously there was an assumption that C-T would uniquely distinguish the "package". Read what Eric wrote about why that is a bad assumption.
Fine. But, what will the Content-Type value be, then? We need a value, and the draft doesn't specify one. OR, shall each info package define the Content-Type value, in addition to the package name itself??? Regards, Christer Christer Holmberg wrote: > 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
