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:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBfQkUACgkQNL8k5A2w/vzGSACgtudyUwkQ48ssylX2LjC9OLja
Oi8AoNG6xUGKCHBKnk2M1qNa4OckcQRl
=QnFO
-----END PGP SIGNATURE-----
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
