Subject: Re: [precis] registration policy for subclasses

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 02 Oct 2012 19:06:05 +0900

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-----
>