Paul Kyzivat wrote:
Let me be clear: for the grandfathering part, I am suggesting that we develop a registry of *existing* usage, not that those existing usages change in any way. I want to get them written down, so at least there is a place to look to find out about something unknown to you, and to ensure nothing new gets defined that is in conflict with something old. If those existing usages can be updated to use the new framework that would be better yet. But I'm not going to hold my breath waiting for that to happen.
Exactly. I agree with all this, and recognise it as a good start. 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). Michael[0] Both the implementation and documentation needs to be lightweight IMO.
[1] RjS' email discusses this further, and he seems less optimistic. [2] Low implementation cost, relatively low risk, no additional stateful behaviour required.
Paul Michael Procter wrote:On Tue, June 24, 2008 3:00 pm, Paul Kyzivat wrote:My latest thought is that we should "grandfather" existing uses of INFO. We would provide a registry of them, without blessing them or standardizing their specifications. That would at least shine some light in the dark corners. At the same time, we would define the new INFO usage framework (still TBD) and ban *new* INFO usages that don't follow it.I agree. The framework proposed in draft-kaplan-sip-info-events-01 seems like a step in the right direction. And I agree with registering existing uses. Even if existing uses aren't updated to use the negotiation mechanism suggested (or whatever solution the WG converges on), I think there is value in strongly encouraging the adoption of the 'Info-Package' header (or similar). This shouldn't noticeably affect interop of legacy devices, but marking the requests like this would allow more recent devices to act appropriately in the presence of multiple incompatible non-standard extensions. Not that such things exist, of course! Regards, Michael
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip