I have to agree on this. There some kind of RFCs that only cause problems because nobody applies them, and then in your life as an engineer you will stumble upon some machine that applies an annoying RFC or takes advantage of an RFC in an annoying way, thus messing your interworking.
Few times though they were I was stuck between 2 development teams both advocating their points by referencing to RFCs. No one wants to be there. Kind Regards Ertugrul Iñaki Baz Castillo wrote: > Hi, I wonder how extended is the support of multipart body in the > current SIP devices. > I realize of more and more RFC's *requiring* multipart body to work. > For example: > > RFC 5365 -- Multiple-Recipient MESSAGE Requests in SIP > > (A user sends a special MESSAGE to a server which distributes it along > all the desired destinations). > > This RFC makes use of a MESSAGE requests with two bodies: > 1) The text message itself. > 2) An XML list containing the destinations of the request. > > When the UAC generates such MESSAGE it must include: > Required: recipient-list-message > > I'm sure that if one of these exotic MESSAGE arrives to most of the > current softphones it will be rejected (because the UA doesn't support > that extension), this is, it will not work. > > Why so complex RFC's? why not just adding the multi-destination info > into request headers so devices no implementing multi-part can receive > the MESSAGE ignoring the multi-destination headers? > > As a personal suggestion, this could be the MESSAGE alice sends to a > server which will distribute it: > > ------------------ > MESSAGE sip:[email protected] SIP/2.0 > From: <sip:[email protected]>;tag=xxx > To: <sip:[email protected]> > Multi-To: <sip:[email protected]> > Multi-To: <sip:[email protected]> > Multi-To: <sip:[email protected]>;anonymize=true > Multi-CC: <sip:[email protected]> > Multi-BCC: <sip:[email protected]> > Content-type: text/plain > > Hello all, let's play football > -------------------- > > When the im-server receives this MESSAGE it would send the same > MESSAGE to all the destinations (hidding some destinations). The > MESSAGE to bob would be: > > ------------------ > MESSAGE sip:[email protected] SIP/2.0 > From: <sip:[email protected]>;tag=xxx > To: <sip:[email protected]> > Multi-To: <sip:[email protected]> > Multi-To: <[email protected]>;count=1 > Multi-CC: <sip:[email protected]> > Content-type: text/plain > > Hello all, let's play football > -------------------- > > In this way, if bob UA doesn't understand "Multi-XX" headers (this is, > it doesn't support the RFC) it will receive the MESSAGE as normal. It > must no reject it because no "Require: exotic-extension" exists. > > > Please. compare how simple is my suggestion against the official > specification in RFC 5365: > http://tools.ietf.org/html/rfc5365#section-9 > > > I have a clear opinion about it: such specifications (like RFC 5365) > will *NEVER* work, and will never be widely implemented. Perhaps it > could be implemented into a closed SIP environment (for example a SIP > provider offering his own customized softphone) but no more, and I > expect the future of SIP is based in interoperability. > > I'm becoming very skeptic and pessimistic when reading such > specifications. Not sure if they are really done to be implemented. If > a XMPP developer asks me "does SIP support multiple-recipient > MESSAGE?" I can't answer "yes" even if this RFC 5365 does exist > (writen != implemented). > > Just my pessimistic opinion. Regards. > > > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
