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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
