In some sense "enumerate known legacy usages" is what I hoped the
registry would do. If we just try to do it in this document, without
provision for update, then which ones will we get, and which will we miss?
I am opposed to a registry of legacy issues if it isn't restricted to
*legacy* uses. I'd like to restrict it to usages that were in production
use prior to the info usage draft - say before the end of 2008. But I
don't know how to put teeth into that, if somebody comes along in 2010
and says "I have this info usage that I have been using since 2004 but I
didn't know about this registry till now." I think it must be honor
system, and I don't know how well that will work.
Regarding keeping the registry separate from the info package document:
when the document describes legacy usage, IMO it would be helpful to say
that to comply with the new document, the legacy usages you use must be
registered in the registry. That would provide some incentive to get
that registry populated. In terms of encouraging migration to the info
packages, we would have to depend on the honor system for legacy usage.
Eric Burger wrote:
[1] Yes - we really, really need an IANA registry of "legacy" INFO
usages, and we need it done in this draft
(NOTE: creating the IANA registry requires the seed values, which
means this draft will enumerate the
known legacy usages)
[2] Punt - I may or may not want an IANA registry, but if we do create
one, do it in another draft
I can go with either of the above.
Thanks,
Paul
_______________________________________________
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
