On 5/28/15 1:03 AM, Romascanu, Dan (Dan) wrote:
Hi,
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:
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.
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?
As I just wrote to you and Benoit and Joel in a private email within a
parallel thread...
The "careful testing" we had in mind for XMPP involves just what is
discussed in Section 6.1 of draft-ietf-precis-saslprepbis:
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.
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).
3. Applying either the UsernameCaseMapped or UsernameCasePreserved
profile to all account names.
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).
Peter
Thanks and Regards,
Dan
-----Original Message----- From: Peter Saint-Andre - &yet
[mailto:[email protected]] Sent: Wednesday, May 27, 2015 7:04 PM To:
Romascanu, Dan (Dan); General Area Review Team Cc:
[email protected] Subject: Re: Gen-ART
Review for draft-ietf-xmpp-6122bis
Hi Dan, thanks for the review. Comments below.
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
<https://urldefense.proofpoint.com/v2/url?u=http-
3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq-0A&d=AwID-
g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd
rphpBsFA&m=HAGYK5DCyp4ZrASnAfyBHWxiG_skpr2T7P71C9h1s8I&s=xE06r
-tOf3XD6VjtlB31ercDLaBN3lIdKjpqO-YALV8&e= >
<https://urldefense.proofpoint.com/v2/url?u=http-
3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq&d=AAMFAw&c=BF
pWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBs
FA&m=r8UFfP-
NUIqoQixcKqofblfdzNSaZvjkRfw3L7VsyHc&s=DCDmXhyc7XoNYI-
SEtLco1iUd9vIjB8nxVWrudr4dV0&e=>>.
Please resolve these comments along with any other Last Call
comments you may receive.
Document:
https://urldefense.proofpoint.com/v2/url?u=https-3A__art.tools.ietf.or
g_tools_art_genart_index.cgi_t-3D965_doc-3Fselected-5Fdoc-3Ddraft-
2Die
tf-2Dxmpp-2D6122bis&d=AwID-
g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXC
JfQzvlsiLQfucBXRucPvdrphpBsFA&m=HAGYK5DCyp4ZrASnAfyBHWxiG_skpr2
T7P71C9
h1s8I&s=3PpWUOBw12kraQlL6gjxpgjwXG-4OvUwcK6jAOwEpd0&e=
Reviewer: Dan Romascanu
Review Date: 5/27/15
IETF LC End Date: 6/3/15
IESG Telechat date:
Summary:
Ready with one issue which I believe is worth discussing.
Major issues:
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.
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?
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?
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.
Peter
-- Peter Saint-Andre
https://urldefense.proofpoint.com/v2/url?u=https-
3A__andyet.com_&d=AwID-
g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd
rphpBsFA&m=HAGYK5DCyp4ZrASnAfyBHWxiG_skpr2T7P71C9h1s8I&s=ZrGi4
ShVndAjMY4s7wYilRtegOfs8l0lX-OPtejBQS8&e=
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
