They could, but I suspect we would end up in a discussion with the APPS area of why we are trying to.
Either we implement MIME or we don't. But to continue the discussion - if you want to do this, then you are going to have to motivate it. I don't see us taking a hum per method and arbitrarily going one way on one method and another way on another. And I don't see the WG being motivated by prior implementation either. I believe we are at the point where we need to make a clear statement on what SIP needs going forwards, not a kludge based on what some existing implementations require to validate their conformance to the new requirements. Regards Keith > -----Original Message----- > From: sunqian 32328 [mailto:[EMAIL PROTECTED] > Sent: Monday, July 23, 2007 12:03 PM > To: Paul Kyzivat > Cc: 'IETF SIP List'; Gonzalo Camarillo > Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 > > Hi, > > Could different SIP methods (INVITE, MESSAGE) be given > different Levels of Support for Multipart? > > Best Regards, > Qian Sun > > ----- Original Message ----- > From: Paul Kyzivat <[EMAIL PROTECTED]> > Date: Sunday, July 22, 2007 12:21 pm > Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 > > > One of the tasks of the draft is to make support for at least some > > subtypes of multipart (e.g. mixed) mandatory. > > > > I hope this is not a suggestion to make dereferencing of external > > bodies mandatory. > > > > If the request is just to include some clarification of the use and > > handling of external bodies in this draft then I guess that > does sound > > useful. > > > > Paul > > > > Eric Burger wrote: > > > Seems like a good idea. However, I would not go so far as to > > mandate> iterative evaluation. I would offer that the UA > > evaluates as needed. > > > > > > > > > On 7/20/07 3:58 AM, "Qian Sun" <[EMAIL PROTECTED]> wrote: > > > > > >> Hi, > > >> I suggest Content Indirection Mechanism defined in rfc4483 > > should also be > > >> considered in this draft. > > >> > > >> It is a little special, an example from rfc4483: > > >> 6.1. Single Content Indirection > > >> > > >> INVITE sip:[EMAIL PROTECTED] SIP/2.0 > > >> Accept: message/external-body application/sdp > > >> Content-Type: message/external-body; > > >> ACCESS-TYPE=URL; > > >> > > URL="http://www.example.net/party/06/2002/announcement";;>> > > EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT"; > > >> size=231 > > >> Content-Length: 105 > > >> > > >> Content-Type: application/sdp > > >> Content-Disposition: session > > >> Content-ID: <[EMAIL PROTECTED]> > > >> > > >> In addition, what happens to the INVITE request if the > > recipient can not get > > >> the indirect content? > > >> > > >> Nits: a letter "l" is missing in the title. > > >> Internet-Draft Message Body Hand"l"ing in SIP > > May 2007 > > >> > > >> Cheers, > > >> Qian > > >> > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > > >> Sent: Friday, July 20, 2007 2:30 AM > > >> To: Gonzalo Camarillo > > >> Cc: IETF SIP List > > >> Subject: Re: [Sip] comments on draft-camarillo-sip-body- > > handling-01 > > >> > > >> Just one comment in addition to what Gonzalo said: > > >> > > >> Gonzalo Camarillo wrote: > > >> > > >>>> The use case described for multipart/alternative - new SDP > > mechanisms>>>> - seems kind of bogus. We've decided not to pursue > > that. Do we have a > > >>>> REAL use case for this? > > >>> AFAICT, we have decided not to pursue SDPng but we still need a > > >>> mechanism in order to be able to, at some point, migrate to > > new session > > >>> description formats. The current consensus, as I understand > > it, is that > > >>> multipart/alternative should not be used to provide > > alternative SDP > > >>> descriptions, but that it could be used to provide alternative > > session>>> descriptions written in different formats. > > >> The other classic example, because it is just like email, is > > MESSAGE>> with a multipart/alternative containing plain > text and html. > > >> > > >> Paul > > >> > > >> > > >> _______________________________________________ > > >> Sip mailing list https://www1.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://www1.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 > > > > > > > > > Notice: This email message, together with any attachments, may > > contain information of BEA Systems, Inc., its subsidiaries and > > affiliated entities, that may be confidential, proprietary, > > copyrighted and/or legally privileged, and is intended > solely for the > > use of the individual or entity named in this message. If > you are not > > the intended recipient, and have received this message in error, > > please immediately return this by email and then delete it. > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.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://www1.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://www1.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
