Hi, >I would like to agree with this. My only reservation is that >if the generic solution requires that each document that >defines usage of a body part in SIP needs to specify >something additional (e.g., CID in a header field), then we >would need to come back and update the Info-Events draft/RFC.
I am not sure we do. We only need to e.g. allow generic-param in the Info-Package header ABNF, and if needed someone can then in future define (in a separate draft) a CID parameter for Info-Package. Regards, Christer > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of > > Hadriel Kaplan > > Sent: 04 December 2008 06:34 > > To: Paul Kyzivat > > Cc: SIP List; Holmberg; [EMAIL PROTECTED]; Dean Willis > > Subject: Re: [Sip] Multiple body-parts in one INFO > > > > > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, December 04, 2008 12:10 AM I just want it to be > > > clear under what circumstances you can > > use multiple > > > body parts in a message, and how a recipient of a message > containing > > > multiple parts figures out how to process it. > > > > Right, so that has two clear aspects to it: > > 1) Where do we solve it. > > 2) How do we solve it. > > > > I assert that every issue raised so far on this thread with > respect to > > multiple body parts has been equally applicable to most if > not all SIP > > message types. No one has refuted that assertion as far as I can > > tell. > > > > I claim, therefore, that the answer to (1) is: in a separate draft > > which applies to all messages. Otherwise we run the risk > that (a) we > > don't solve it the same way, and (b) we delay this draft, > and (c) we > > create a case where someone fixes their handling for INFO > multi-part > > bodies but not other message types because they only > implemented this > > draft, and we end up with split UA personality disorder. :) > > > > > > > Just in the thread we have already heard a explanation of > > doing it based > > > solely on C-T, which is really wrong. So its obviously not > > clear now. > > > > That is about aspect (2). I agree with you completely that > > C-T is not the right answer, but I don't see what it has to > > do with this draft. We shouldn't be defining a solution to > > the problem for *INFO*. We should be updating INFO to fix > > what's broken in it now, and defining a solution for all > > messages in a separate draft (presumably the body-handling draft). > > > > -hadriel > > _______________________________________________ > > 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
