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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
