Hi, >Wrong because there is no explicit linking of a body part to what that body part belongs to. > >Content-Disposition is absolutely the wrong thing. The original Content-Disposition is about whether you wait for the whole message to arrive before rendering, and if you render the part where you find >it or as an attachment. SIP has bent this totally out of shape beyond recognition, almost to the point where it really is Message-Context. > >Perhaps that is the answer? Do-as-I-say (Message-Context), not Do-as- I-mean (Content-Disposition)?
So, maybe we should use Content-Type, then? Regards, Christer > Wrong where/what/how? > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of >> Eric Burger >> Sent: 1. joulukuuta 2008 16:13 >> To: Hadriel Kaplan >> Cc: SIP List >> Subject: Re: [Sip] Multiple body-parts in one INFO >> >> Just because everyone else got it wrong does not mean we have to be >> wrong, too... >> >> On Dec 1, 2008, at 6:14 AM, Christer Holmberg wrote: >> >>> >>> Hi, >>> >>>>> Sounds ok. >>>>> But, doesn't the Info-Package header syntax still have to >> allow the >>>>> piggy-backer to: >>>>> 1) List multiple info packages >>>>> 2) For each listed info package, provide the cid >>>> >>>> Nope. We've already said we're going to not bother doing multiple >>>> packages. (or at least I think people have agreed with >> that, I hope) >>>> >>>> So the next question was on multiple body-parts. >>> >>> I still want to see why we, if we are going to allow multiple body >>> parts, can't allow multiple info packages, but let's leave >> that for a >>> moment... >>> >>>> Since INVITE, UPDATE, PRACK, SUBSCRIBE/NOTIFY, MESSAGE, and legacy >>> INFO, can all carry bodies and not one of >>>> them defined a CID mechanism for the body part that was specific to >>> their message method context, we shouldn't need >>>> to for INFO either. >>> >>> Yes. And, if we are going to use CID, it means yet another RFC to >>> support. >>> >>> What's wrong with using Content-Disposition? >>> >>>> A "piggy-backer" is an extension to SIP that piggy-backs >> bodies onto >>>> any message method types. Geolocation is an example of >> one. Since >>>> it's the responsibility of the piggy-backer to handle >> identifying its >>>> specific body-part and dis-ambiguating it from the >> method's, we don't >>>> have to do anything. In other words, Geolocation would >> already have >>>> to deal with current INFO message and body syntax. >>>> >>>> For example, let's suppose someone creates an INFO package for >>>> sending virtual location information in a game, using a >> content-type >>>> of application/pidf+xml. (whether they should have done it in SIP >>>> vs. the media layer is orthogonal) And let's suppose for whatever >>>> reason the SIP stack always adds Geolocation information >> of the UA's >>>> physical location. >>>> Here is what it would look like: >>> >>> But, what if the information the piggy-backer wants to send >> also uses >>> info packages? >>> >>> Regards, >>> >>> Christer >>> _______________________________________________ >>> 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
