> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Michael Procter > > I went on to propose a half-way house between no changes for legacy > uses, and full adoption of a new framework. A lightweight[0] framework > may[1] attract new uses, but the negotiation features present in > Hadriel's current draft seem likely to deter the migration of legacy > uses. I am merely suggesting that using the INFO-labelling part of > Hadriel's draft but not the negotiation aspect could seem more > attractive[2] to legacy uses, and would still provide the rest of the > community some value (namely being able to identify all the INFO > messages flying around their networks).
I don't think there's much value in documenting the labeling part without negotiation. One of the main issues right now is you don't know which INFO mechanisms the far end wants/needs/supports. There isn't really much issue with discerning what the INFO you received was for once you got it, 'cause the content-type has been unambiguous so far for all of the current usages I think (or majority thereof). It was the potential for content-type ambiguity in the future that was one of the concerns of INFO, but the real driver for me at least is the "what does the other end want/expect" problem. I'm all for making the "negotiation" part as trivial and KISS as possible - I started with what I thought was trivial, but people wanted to pile onto it to cover 3PCC and other scenarios. I'm cool with going back to simple as a better-than-nothing approach. :) -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
