+1 I think we will get into difficulties trying to put legacy usage into the present draft.
John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of DRAGE, Keith (Keith) > Sent: 30 October 2008 23:10 > 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
