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 <[email protected]> wrote: > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
