Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed;
 boundary="Apple-Mail=_4D876CB9-AB30-494A-AF36-D4D1E8CD89C0";
 protocol="application/pgp-signature"; micalg=pgp-sha512
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <556716C5.8000203@andyet.net>
Date: Thu, 11 Jun 2015 13:30:19 +0300
Message-Id: <A073E04C-FC39-4113-8CAF-9F9B5673089D@piuha.net>
References: <9904FB1B0159DA42B0B887B7FA8119CA5CA3C683@AZ-FFEXMB04.global.avaya.com>
 <5565EB04.1090402@andyet.net>
 <9904FB1B0159DA42B0B887B7FA8119CA5CA3D772@AZ-FFEXMB04.global.avaya.com>
 <556716C5.8000203@andyet.net>
To: Peter Saint-Andre - &yet <peter@andyet.net>
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/jXQ-oI8U8_9tXZHEA5uHiqNwQmA>
Cc: "draft-ietf-xmpp-6122bis.all@tools.ietf.org"
 <draft-ietf-xmpp-6122bis.all@tools.ietf.org>,
 General Area Review Team <gen-art@ietf.org>
Subject: Re: [Gen-art] Gen-ART Review for draft-ietf-xmpp-6122bis
Precedence: list


--Apple-Mail=_4D876CB9-AB30-494A-AF36-D4D1E8CD89C0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Thanks for the good review, Dan, and for the changes, Peter. I have =
balloted No-Objection.

Jari

On 28 May 2015, at 16:23, Peter Saint-Andre - &yet <peter@andyet.net> =
wrote:

> On 5/28/15 1:03 AM, Romascanu, Dan (Dan) wrote:
>> Hi,
>>=20
>> What is missing in my opinion are more details for the operators
>> about what tests can be made in order to avoid compatibility and
>> migration problems. The text in  draft-ietf-xmpp-6122bis-22 says:
>>=20
>>> Because it is
>> possible that previously-valid JIDs might no longer be valid (or
>> previously-invalid JIDs might now be valid), operators of XMPP
>> services are advised to perform careful testing before migrating
>> accounts and other data.
>>=20
>> What does this 'careful testing' include so that operators avoid
>> problems for the XMPP and XMPP applications users?  Can we be more
>> precise? Section 6.1 in draft-ietf-precis-saslprepbis (which needs to
>> be referred here) seems to provide indications for application
>> developers to avoid incompatibilities - this is fine. What needs an
>> operator with an installed base of 'legacy' 6122  do and test?
>=20
> As I just wrote to you and Benoit and Joel in a private email within a =
parallel thread...
>=20
> The "careful testing" we had in mind for XMPP involves just what is =
discussed in Section 6.1 of draft-ietf-precis-saslprepbis:
>=20
> 1. Looking for account names that have Unicode code points with =
compatibility equivalents (e.g., U+017F LATIN SMALL LETTER LONG S and =
U+2163 ROMAN NUMERAL FOUR) - this is the major concern.
>=20
> 2. Looking for account names that have Unicode code points from the =
PrecisIgnorableProperties (M) category defined in Section 9.13 of RFC =
7564 (e.g., U+00AD SOFT HYPHEN) - these are less likely to have ever =
been allowed in account names but I suppose it's possible (and they =
would have been "mapped to nothing" in Stringprep so in practice a user =
would not notice the difference if under PRECIS those code points are =
removed).
>=20
> 3. Applying either the UsernameCaseMapped or UsernameCasePreserved =
profile to all account names.
>=20
> If Section 6 of draft-ietf-precis-saslprepbis is complete, then =
referencing that section from draft-ietf-xmpp-6122bis should be =
sufficient - perhaps with some more explanatory text as above, =
preferably in the saslprepbis document because it would be helpful to =
operators of any application service that used SASLprep (putting that in =
the XMPP document won't help operators of non-XMPP services).
>=20
> Peter
>=20
>>=20
>> Thanks and Regards,
>>=20
>> Dan
>>=20
>>=20
>>> -----Original Message----- From: Peter Saint-Andre - &yet
>>> [mailto:peter@andyet.net] Sent: Wednesday, May 27, 2015 7:04 PM To:
>>> Romascanu, Dan (Dan); General Area Review Team Cc:
>>> draft-ietf-xmpp-6122bis.all@tools.ietf.org Subject: Re: Gen-ART
>>> Review for draft-ietf-xmpp-6122bis
>>>=20
>>> Hi Dan, thanks for the review. Comments below.
>>>=20
>>> On 5/27/15 7:00 AM, Romascanu, Dan (Dan) wrote:
>>>> I am the assigned Gen-ART reviewer for this draft. For background
>>>> on Gen-ART, please see the FAQ at
>>>>=20
>>>> <https://urldefense.proofpoint.com/v2/url?u=3Dhttp-
>>> 3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq-0A&d=3DAwID-
>>> g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd
>>> rphpBsFA&m=3DHAGYK5DCyp4ZrASnAfyBHWxiG_skpr2T7P71C9h1s8I&s=3DxE06r
>>> -tOf3XD6VjtlB31ercDLaBN3lIdKjpqO-YALV8&e=3D >
>>> <https://urldefense.proofpoint.com/v2/url?u=3Dhttp-
>>> 3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq&d=3DAAMFAw&c=3DBF=

>>> pWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBs
>>> FA&m=3Dr8UFfP-
>>> NUIqoQixcKqofblfdzNSaZvjkRfw3L7VsyHc&s=3DDCDmXhyc7XoNYI-
>>> SEtLco1iUd9vIjB8nxVWrudr4dV0&e=3D>>.
>>>>=20
>>>> Please resolve these comments along with any other Last Call
>>>> comments you may receive.
>>>>=20
>>>> Document:
>>>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__art.tools.ietf.or
>>>>=20
>>>>=20
> g_tools_art_genart_index.cgi_t-3D965_doc-3Fselected-5Fdoc-3Ddraft-
>>> 2Die
>>>> tf-2Dxmpp-2D6122bis&d=3DAwID-
>>> g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXC
>>>>=20
>>> JfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DHAGYK5DCyp4ZrASnAfyBHWxiG_skpr2
>>> T7P71C9
>>>> h1s8I&s=3D3PpWUOBw12kraQlL6gjxpgjwXG-4OvUwcK6jAOwEpd0&e=3D
>>>>=20
>>>> Reviewer: Dan Romascanu
>>>>=20
>>>> Review Date: 5/27/15
>>>>=20
>>>> IETF LC End Date: 6/3/15
>>>>=20
>>>> IESG Telechat date:
>>>>=20
>>>> Summary:
>>>>=20
>>>> Ready with one issue which I believe is worth discussing.
>>>>=20
>>>> Major issues:
>>>>=20
>>>> I have a concern about backwards compatibility and migration. In
>>>> the migration between 6122 and 6122bis deployments it is possible
>>>> that previously-valid JIDs might no longer be valid or
>>>> previously-invalid JIDs become valid. Because of this the
>>>> Introduction says that operators of XMPP services are advised to
>>>> perform careful testing before migrating accounts and other
>>>> data.
>>>>=20
>>>> In a dialog with Peter Saint-Andre (document author) I asked if
>>>> there are any recommendations that could be made to the
>>>> application designers and operators respectively to ease the
>>>> migration?
>>>>=20
>>>> His answer pointed to section 6 (actually I think that 6.1
>>>> applies) in in draft-ietf-precis-saslprepbis. I believe that a
>>>> pointer to that section in a 'migration / backwards
>>>> compatibility' section would be useful for the application
>>>> designers. What about the operators, however? Can more details
>>>> about what operator should test to ensure compatible migration of
>>>> users and applications be provided  beyond what is mentioned in
>>>> the introduction?
>>>=20
>>> We tried to make Section 6 of draft-ietf-precis-saslprepbis focused
>>> on the needs of operators, not application designers. (I happen to
>>> be the operator of a relatively large instant messaging service
>>> that will need to do some testing and possibly some data munging
>>> when we migrate our account data from Stringprep to PRECIS, so I
>>> wrote that text with my operator hat on.) If the text in
>>> draft-ietf-precis-saslprepbis is not complete enough, then we need
>>> to figure that out now because it's on the IESG telechat tomorrow.
>>> I do think that's the right place to discuss the matter, because
>>> draft-ietf-xmpp- 6122bis merely uses the UsernameCaseMapped profile
>>> defined in that document.
>>>=20
>>> Peter
>>>=20
>>> -- Peter Saint-Andre
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
>>> 3A__andyet.com_&d=3DAwID-
>>> g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd
>>> rphpBsFA&m=3DHAGYK5DCyp4ZrASnAfyBHWxiG_skpr2T7P71C9h1s8I&s=3DZrGi4
>>> ShVndAjMY4s7wYilRtegOfs8l0lX-OPtejBQS8&e=3D
>=20
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art


--Apple-Mail=_4D876CB9-AB30-494A-AF36-D4D1E8CD89C0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVeWM7AAoJEM80gCTQU46qSbkP/2joO45QL8XjwG0fN34pue2/
WeHY/jmJ4F4gTMj5NEh4qFJFiOD8k+nRAmBJTixKs0XgAPMetXylGNJW66SgdgWG
G1mxveN41n97EAeU1zYHt7JlQielifpQSllM9uMEYVTCiZKV6ZjMBxHMPmy1Uv1j
lUtExuKRawJKLEvL3RScxaWzMEfhxmwufHjPns8YFKKPey8kSt26IVnog76l7xG3
9M5x4Lmka9Lp2bNv2YjjuUObMzJxGxVBulO3qXQsMs77hRcg5h5aZTqARPrsaYHK
vsRtUXev5rrmQ9l2aajJqgF/gizhmkDAZY6a1DLtn34HI2nTrNae2jJBvK2Xn6v2
dPPo4KJ9eMndf8s3oFcL9vtUonLgLC9ArEaJ9c7zVMNzqqOmxL3CmKPxDpbUPRPF
0B1UJzXtJ1k+JNEvQb1/pZ2O4IWfxFYRqSkQRyM8xv1uB4PrJGM7qekxwZZ9iDYn
K6mbdro2yA046b7aKrbDgFtcJfP2GtM24T7Y8usIo1/RFxed/+ZFk+9mwQXLfjOU
Ig0l4TrNtMseYp/jZknPaIIVgA1Ay/1sLOdC3pvUQCeXY1e/tWqF6lGJqvnv4Uia
OPQhgtYdIxJbRPYFqWDai6XWSJvSBmqJNghnI09rwEY/dkpBU//iO+/TJu88k84V
YPlioQlwQMVzLW01RyC+
=XbXd
-----END PGP SIGNATURE-----

--Apple-Mail=_4D876CB9-AB30-494A-AF36-D4D1E8CD89C0--