Hello Peter,
On 2012/09/24 23:41, Peter Saint-Andre wrote:
-----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.
Just to be clear, my suggestion was that this information (maybe in a
somewhat more concise form than my example below) go into the actual
template, not into a separate wiki.
Regards, Martin.
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
