=============================== IETF Precis WG Agenda for IETF 88, Vancouver, CA MB: Marc Blanchet AS: Andrew Sullivan PSA: Peter St-Andre JH: Joe Hildebrand JK: John Klensin DB: David Black YO: Yutaka OIWA YY: Yoshiro Yoyena mailing list: precis@ietf.org Administrativia Minute scribe: Marc Blanchet, John Levine Jabber scribe: Barry Leiba to channel Document updates / Discussion - RFC 6885 - Framework https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ WGLC done. new document published, discuss today - Preparation and Comparison of Nicknames https://datatracker.ietf.org/doc/draft-ietf-precis-nickname/ WGLC done. waiting for writeup - Mapping characters for precis classes http://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ WGLC done. new document published, discuss today - Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ Ready to WGLC? (forward to kitten) [ no comments in room ] Framework WGLC comments Peter St-Andre http://www.ietf.org/proceedings/88/slides/slides-88-precis-1.pdf updates to implementations resulted in some codepoint table fixes feedback incorporated from various people Simplify, simplify: changed to specify classes and profiles only classes: define rules for allowable characters profiles: define width mapping, normalization, directionality Clarify, Clarify Where we stand Joe Hildbrand - It would be nice to revisit visual examples when the RFC format does handle Unicode. Marc Blanchet - Is your first that we need this document to wait, or is this more appropriate for the guidelines document? Peter Saint-Andre - We need some automated way of validating thigs. MB - But how much of these do we need to write down in the framework document PSA - There's nothing that has to go into the documents. MB - Is this something we need to do now, or work out as we go? PSA - It's something we work out as we go Andrew Sullivan - We need to have some form of checks and balances, and we need some way to check that we're forward compatible. PSA - We do, but we can work on it in parallel with all the remaining steps (IETF LC, AUTH48, etc etc) [ Chairs ask for comments ] AS - I think it's ready now. MB - There were a lot of changes in LC Barry Leiba - Maybe that means the shepard writeup notes that it might not have gone through a lot of review AS - I followed closely the discussions, I commented on things, and I think they're done. PSA - It seemed on the list that Florian thought it was done. Alexey Melnikov - I read the diffs, and I think the document is done. Pete Resnick - When a document comes to the IESG, and comments are made and changes are made and so long as people have been paying attention, we don't normally do a new Last Call. So long as your comfortable that the changes are appropriate and they haven't screwed things up, you don't need to do a new WGLC. MB - But it's probably safer to have another pass. PR - It's up to you. Florian Zeitz (via LB) - I personally think this is mostly ready, I'm also under the impression that the most recent version might not be widely reviewed. We also might have to talk about the way UNASSIGNED is defined right now though. The framework draft currently says to disallow them, I'm not actually sure how that interacts with networked systems using different Unicode versions. AS - What I think happens with UNASSIGNED, you are allowed to use the minimum union set (anything unassigned is not allowed) MB - There is an underlying assumption that everyone knows what versions everyone else is using. AS - That does mean the older software doesn't work if it's given text using newer code points. PSA - We actually say it's REJECTED, and I think that's consistent with the IDNA spec. Joe Hildebrand - Does that mean applications should have a specific kind of error code for that. PSA - I think that's up to the protocol, but it's not a bad idea. We have something in XMPP. JH - I agree it's up to the protocol, but just suggesting we might need to recommend it. [ Chairs ask how many have reviewed the latest version and that all of the comments are addressed ] -- one hand in room and another one added, when the question was explained. John Klensin - You might need to ask separate questions Mapping characters for precis classes Takahiro NEMOTO http://www.ietf.org/proceedings/88/slides/slides-88-precis-2 * Issues Raised * Solutions (1/3) * Solutions (2/3) * Solutions (3/3) [ comments on mapping document ] AS - I move concerns than of the framework. I think it would not be a bad idea for another WGLC. The example on slide 3 is a good example of where things get weird. This might be easier if you could tell where the end of a word was, but we don't have an obvious way to do that, so maybe you just need to pick one. AS - Now that I've read it several times, I think I get it, but it took a few reads. PSA - I had to read it several times, and try and follow the trail for several characters, before I really got it. I think there are some suggestions for making it clearer, but I do think I need to review it again. JK - I had the same reading experience. Consistency means we have an obvious result, but if there is a disconnect with what users expect intuitively we have a protocol failure. PSA - My user experience design is limited to ancient greek. DB - What are you thinking of for user interface, so we can blow it up? To start a strawman, are you asking for what the user's inputs or what gets rendered? (??) JK - Characters that are expected to be treated specially such as when they're supposed to be used to end a sentence can drive users nuts if not done intuitively. One way is to have a rule to "not do this", and while it upsets people it does so uniformly. DB - And one example is the dotless-I in Turkish. I think we should limit this to graphical output, but I know someone versed in Greek and we should consult them to get a good answer. AS - This all does not solve the general problem. The question is whether that rule is consistent enough that users can learn it, and I don't know what the answer is. It's a really simple rule, so it might be that users will probably adapt. For example, the Upper Sigma case might mean users don't use it. The question is if the users will adapt. One group has said "we won't do that, you need to fix the internet." JK - ?? AS - It is a "don't use that rule", but it should be that your policy is "don't use that." And something similar in IDNA 2008 to push it out to the operators. JK - The difference is that we tried to push this out to where there is one possible answer. And here the one possible answer is a "don't use that" rule. I'm just saying that it is far easier for users to understand that rule. JK - My additional observation is that this document needs more examination. [ Chairs ask how many reviewed the document ] - two/three hands YY - AS - I did review it, but I'm not sure a new reader will understand this document. I suggest that those that did not raise their hands review this document. BL - I will review next week. JK - I started reading this six weeks ago, but had to put it down. I finally forced myself to read it, and it took effort to understand it. PR - If this document does not go to IETF LC with the others, it's not a big deal. There are others that I hope go together for IETF LC. This is a hard problem; IDNA threw up their hands and said not to use these charaters. Others threw up their hands and said nothing. PSA - It might be an uncrackable nut for which we nave a normative reference in the framework document. I'm not under the impression it needs to be a normative reference. JK - As I read the framework document, I don't think it needs to be a normative reference, as long as we understand that there might be some issues with interoperability. PR - For the consumers, do you have a sense of what it means if case mapping is not normative for your protocols? MB - We already knew from the problem statement that it was significant JH - For XMPP, we'll probably just pick something and it will probably be wrong. DB - Roughly the same as JH, and if we don't have this document we won't get dotless-I right. JK - Any time special casing gets involved cans of worms get opened. In the case of the top box, we will have to train users for some non-intuitive behaviors. Alan DeKok - I will note that no other solution has worked. In cases where mapping is important, it's not enough to just let some intl library deal with it. We really don't know what to do. AS - For those that want to consume this, then they need to walk through the framework and ask "how does this work?", and see if they have some of these special cases. AS - Second, can you understand this document to implement it, then this document is not ready. JK - Some application will find the nearest library that kind-of sort-of does it for them, and leaves the problem to that. PR - So far, I'm hearing is that this probably needs to be normative, which means we have to go back through a review to see if we've gotten this right. This whole special casing is a problem. We need to make this usable, and maybe JH can say how to do it. I think AS's suggestion to walk through it is too hard for them to do. JH - For libraries, I think the best we can do is to have lots of test vectors of what is expected, and get those implementations to run those tests. JK - I think that's a really good idea, as soon as we realize that the set of test cases will be the empirical standard. JH - At least we have some people that have written code for this WG, and if we can have them run the tests then at least it's something. MB - My sense of the discussion is that the document is not ready for any Last Call, and we need more reviews, and will likely require the document to be revised. PSA - To John's point, part of the problem is that we don't have good intuition into the languages. The special casing stuff is that we don't have speakers of these languages that can help us. Absent finding them, we have to look into whether we get into the special case-mapping. I think we're damned if we do and damned if we don't. JH - I think there's at least two sources of data not yet tapped. One is the entire community of IETF participants, and maybe we need to break the test cases out into a separate document. This is one of those things where posting to Slashdot might actually help, even with the high signal-to-noise ration. JH - The other thing is maybe we should try to get the Unicode folks to pitch in. PSA - We have in XMPP a large community of implementers with large internationalization databases, so maybe we should ask them. BL - ISOC has worldwide chapters, and I'm happy to ask there. PR - Recommendations to chairs is to take names for those seeking out the help. I do think we need more eyes on this, and different sets of eyes, and I suggest you find people to help find those eyeballs. PSA - I think JH's suggestion is a good one, since we don't have that separate thing to hand out. JH - One way to do this is to have a github project with a single file per language. JK - One problem with that kind of survey is you get the trolls. MB - For the record, I agree. JH - I don't know what else we can do -- either we ask for it now or we deal with the complaints later. JK - I am just making the observation that we might need to be careful because it is a somewhat strange audience. JH - I'm open to other suggestions, but we need to do something. AS - I "like" the idea of calling up Unicode and asking them to review the special casing document, and if they strongly object then maybe we'll understand why. We just have to deal with them, and we need a completely algorithmic rule because we'll need to deal with the future changes. We'll need a rule, and it will break someone. My question is can we get good enough advice from the people who developed the character set? MB - I agree with everything you said (??). MB - I sense this is a problem we need to handle somehow, and we need additional input to figure out what needs to be done. Therefore, this document is not ready to progress. [ no objections to that summary ] 3. Next steps 3.1 Profile documents 3.2 Guideline documents AS - I don't fully understand what the plan is for the documents are? If we want to ship them somewhere else, we need the other groups to agree. If we want to LC them, then we need to get outside review. YY - If the document is already in this WG, then we will support it. If the document is in another WG, then they can ask for review. AS - The question is "if you need this, do you understand this well enough to put this into your protocol?" This might be the time to do this. JK - The other question that should be asked is "Why do you need a new profile?" MB - Until the WG is closed, there are people that can do the reviews. I think it is up to the ADs when this WG is closed. PSA - My recollection/suggestion from Berlin is that I don't know why we needed a special profile for HTTPbis. I think the nickname thing is different enough that we need a special profile. Some of the profiles (e.g. XMPP profile) have some characters that are disallowed for historical reasons that might have been lost over time. There are some protocols will need separate protocols for these reasons, but I do agree we should ask the question and be critical of why a new profile is needed, or we will increase user confusion. AS - I agree with that, but I don't think it's our problem. I think the framework should say "if you think you need a new profile, think really hard about that." This problem is not unique to the internationalization group, even down to individual applications. What this really says is there is a general usability problem that we can't solve. MB - I agree with that assessment. In the various reviews of other profiles for stringprep there was a lot of though, but I agree one should look aroundbefore doing your own stuff. YO - I would like to merge the httpbis and saslprep documents, but I'm not completely happy with where it is. And this might be the case with other protocols. I think it's ok to have a separate discussion for each profile. YY - If implementers want to use each of these protocols, it means they have to implement each protocol's profile, and that is a large amount of work. YO - One suggestion is to have one profile, and several application guidelines. For example, salting the password means the username is case sensitive, so reusing the saslprep profile isn't really possible. PSA - For the saslprepbis version, we have some acquiescence with kitten around how to use it for SASL and non-SASL cases. At first pass, I see a lot of similarities between saslprepbis and httpbis documents. I'll do another review, and I suggest YO do another review from the httpbis document. DB - I need to think about what this means for iSCSI, hopefully by London. YO - In my case, if the httpbis document is completely separate from saslprepbis, I can work on just that profile off of saslprepbis.