-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You're probably right. Those "in the know" who actually read the relevant specs are well aware of these historical relationships. Tracking which PRECIS usages replace which Stringprep profiles might be something that is better left to a wiki, not an IANA registry.
On 9/24/12 1:06 AM, "Martin J. Dürst" wrote: > Given that there are quite a lot of ways in which this "obsoletion" > can happen, I think an entry of the form > > Obsoletes: foo > > is totally inappropriate. It should be replaced by some more > detailled description, such as (just an example): > > Historical Relationship: This registration is intended to replace > the "foo" stringprep profile wherever possible. It the data has > been carefully checked to avoid any changes from the "foo" profile, > with the exception that this profile is no longer based on a fixed > version of Unicode and therefore includes more characters. Also, > the two characters BAR and BAZ were excluded because they lead to > heavy ... in practice. Specifications are recommended to update > their references to this registration after a careful analysis of > the consequences. > > As I said, this is just an example, but I hope it shows the idea. > > Regards, Martin. > > On 2012/09/24 2:09, Peter Saint-Andre wrote: On 9/22/12 5:08 AM, > "Martin J. Dürst" wrote: >>>> On 2012/09/22 3:53, Peter Saint-Andre wrote: One further >>>> thought: would it make sense to capture the fact that some >>>> new precis usages obsolete a old stringprep profiles? >>>> >>>>> What does "obsoletes" mean here? Is the result still the >>>>> same (just a different framework), or are changes to the >>>>> definition allowed? > > Good question. I mean "replaces" or "supersedes", where going > forward the new Precis usage is intended to be used instead of the > old Stringprep profile when handling the relevant protocol > elements. For example, the Precis profiles we're defining in > draft-ietf-xmpp-6122bis for XMPP localparts and resourceparts are > intended to be used in the future instead of the Nodeprep and > Resourceprep profiles of Stringprep first defined in RFC 3920. > Although in the XMPP community we are working to make sure that the > new Precis profiles have very similar output to the old Stringprep > profiles (i.e., the same result using a different framework), I > think any changes to the definition are a matter for the > application protocol and not the Precis framework. > > Another way to handle this matter is to make sure that the > application protocol specs contain an IANA action to change the > status of the relevant Stringprep profile(s): > > http://www.iana.org/assignments/stringprep-profiles/stringprep-profiles.xml > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBgcR0ACgkQNL8k5A2w/vyJFwCgpalBsopDctr2HxMtTiI2Sn68 u3wAoJL5N45YgkHDBranX7O2t1Cy/3mJ =qQQ/ -----END PGP SIGNATURE----- _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
