I'm think I agree with Keith. How about:
[X] No, do not create an IANA registry, but please enumerate known legacy usages in separate draft cheers, (-:bob -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DRAGE, Keith (Keith) Sent: Thursday, October 30, 2008 7:10 PM To: Eric Burger; Paul Kyzivat Cc: SIP IETF Subject: Re: [Sip] Legacy Info Package Registration (As individual) At the moment I think this draft should concentrate on the packages, and interoperability with the legacy issues. I don't think I want to identify (except by way of example for the above) any of the legacy usages. I do not have an objection to creating another draft that creates a registry of legacy usages, and if that wants to list known ones then fine. I have no objection if we do that now or later, but the main draft would not be dependent on it. I would note that if we do create a registry, then whether we need to seed it or not depends on the registration criteria - if it is first come first served, then anyone can register their own legacy usages without waiting for an RFC to do it for them. At the moment I am also unsure what criteria we would use for identifing a legacy usage, apart from some rather vague textual description. It after all does not have a package name. So I'll accept either of these: > [ ] No - please do not create an IANA registry > > [ ] Punt - I may or may not want an IANA registry, but if we > do create one, do it in another draft regards Keith > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Eric Burger > Sent: Thursday, October 30, 2008 4:14 PM > To: Paul Kyzivat > Cc: SIP IETF > Subject: [Sip] Legacy Info Package Registration > > We discussed creating a registry, and we discussed whether it > would be in this document. > > On the one hand, the discussion was not conclusive. On the > other, here are my reasons for not including it in the Info > Packages document: > > 1. We go at lengths to say how to do Info Packages. The last > thing we need to do is say, "by the way, it's not so bad if > you don't." > > 2. People not involved today will look at such a registry > and, no matter how much doom and gloom wording we use, will > think it's OK to not use Info Packages. > > 3. People will be confused, thinking Content-Type is > sufficient to identify an Info Package. It is not. > > 4. How would we possibly police the registry? If someone > comes to IANA to register a new MIME type do the klaxons > ring? That would not be a good thing. > > So, time for another poll: > [ ] 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) > > [ ] No, do not create an IANA registry, but please enumerate > known legacy usages in this draft > > [ ] No - please do not create an IANA registry > > [ ] Punt - I may or may not want an IANA registry, but if we > do create one, do it in another draft > > [ ] Other: ________________________________ > > > > On Oct 21, 2008, at 10:52 AM, Paul Kyzivat wrote: > > > Regarding registration if INFO packages - I thought we also > wanted to > > introduce a registry for legacy usages of INFO, to > encourage them to > > come out into the daylight. I guess maybe that would be a separate > > registry, since the key for it will have to be Content- Type. So it > > *could* be established from a different document. But I > think this is > > the likely place to do it, since its the place where all > the eyeballs > > will be. I think the rule for registering those needs to be > that one > > can only be registered if the Content-Type has not already been > > registered, and it was in *use* with INFO prior to this document > > becoming an RFC. (The registration itself could be done > later. I guess > > it would be the honor system.) Any usages being deployed after this > > becomes an RFC would be required to use the new mechanism. > _______________________________________________ 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 _______________________________________________ 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
