Re: Legacy Info Package Registration

+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