=============================== IETF Precis WG Agenda for IETF 89, London, UK Tue, 4 Mar 2014 13h00-14h00 mailing list: precis@ietf.org chairs: Marc Blanchet, Yoshiro Yoneya PR: Pete Resnick YY: Yoshiro Yoneya MB: Marc Blanchet TN: Takahiro Nemoto OY: yoiwa DB: David Black PSA: Peter Saint-Andre BL: Barry Leiba JK: John Klensin AMcD: Alex McDonald 1. Administrativia (co-chairs) http://www.ietf.org/proceedings/89/slides/slides-89-precis-0.pdf 2. Document updates / Discussion 2.1 Status report of WG I-Ds (co-chairs) - Framework https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ status: AD review AD still revewing document, but does not expect anything substative. PR : I just started my review before the meeting, so I don't have any comments now, but I don't think it'll be a big deal. - mappings http://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ status: WGLC done. new document published Chair: many comments during LC - nickname https://datatracker.ietf.org/doc/draft-ietf-precis-nickname/ - SASLprepbis http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ OY: I was wondering if we PSA: I did not review the http changes in detail since last meeting, so I don't know if we should change things. We are calling it a password profile and not just a SASL password profile AM: I don't think there is a reason to have different profiles between http and sasl. There might be a need for a different username profile, but I'm not convinced right now. OY: I think we can share the same profile for password, but I don't think we can share a username profile. PSA: Something that came up in the IAB Int'l list about the potential of having too many profiles. PRECIS was meant to have a couple of simple profiles that everyone can use. The idea that we would have protocol-specific profiles defeats the purpose of the PRECIS profiels, and have we failed at that. I think we need to look at the username usecase specifically; each protocol has their own requirements than what we thought was safe. Do we need to go back to look a little more general or should we say that such protocols are just legacy and we should tell people don't do that anymore. PR: Should we start showing up in other meetings and tell them to stop doing things and tell them to start using our output. BL: No we shouldn't tell them to stop, but we should tell them to look at our work. THey have shorter timeframe than we do. AM: PR: Framework was a complex thing to get together. But for saslprep-bis, there are protocols that need this output so we need to get this done more quickly. YY: Suggest we take the discussion to list to see if we need a separate document. OY: Is there anyone else that needs a protocol-specific profile like http-auth? DB: I care the most about iSCSI names, and I will pick something out of the framework and do something special. We do have a notion of a username, so if you came up with a profile for username we could probably use that. 2.2 Discussion on WG LC comments (1) mappings (Takahiro) http://www.ietf.org/proceedings/89/slides/slides-89-precis-1.pdf 2nd Issue: DB: I think for final sigma and eszett, this is fine. I think for Turkish, 'I' maps to one thing there and something else everywhere else. If you choose to pick up the SpecialCasing.txt file, then you get everything. It means you pick up the mapping for Turkey even if that's not where the locale is. JK: I think it's worse. You're solution might be the right one, unless you have very detailed locale information, you can get it wrong. There are a number of Eastern European countries have gone from Latin (Turkish)-to-Cyrillic-to-Latin (other). So the solution we pick now based on user expectations will likely be wrong in the future, but if you pick something that does not account for user expectation then you will be wrong for some users but be consistent. We are moving down the path of more and more profiles, and that will lead to massive confusion. AMcD: We are talking about Turkey charsets, and it's a problem of character set and not just locale. Any time you do some form of normalization it will be a problem for things like Turkish. The other observation is that these are political decisions, and I don't know how to solve that at a technical level. PR: To a certain extent, my feelings on this issue depends on the output of the next issue. If this is informational, then we can say "There be (Western Evil) Dragons" and give people information on where to look for the dragons and leave it to the implementers to do something. If it's Proposed Standard, we need to give them definite guidance which it doesn't seem like we can. AS: I think you should reverse your priority, and instead determine if we can or cannot do a standard here. JH: "Too bad you have to solve it anyway", but now with my red dot, "Thou shalt solve it anyway" JH: The opposite of this is we have an english-only internet. I don't think we've exhausted all of the brainpower in the room. AS: The problem here is you can't both do i18n and l10n omnipotently. We are trying to write a standard for the internet, and we are trying to do mapping for people in a certain locale for people are in a different locale. You can't know that in a general case. We can say that here are places where it can fall down. This is the problem with doing i18n and l10n simultaneously, and we have to accept the limits. Unfortunately some users lose. JH: Let me give you an example of something we could do -- we could take those things that are not recognizable and put it into a locale exceptions table. The receiving software on the other side could try and do something based on that table. PR: We might want to say more explicitly that a certain class of things to deal with are user method input problems that will be locale-dependent. The framework says you should try to limit the acceptable class of characters because they can be problematic. So you can either say "allow case-sensitive compares or you deal with exceptions on the mappings" and rely on the user input method to "do the right thing." JK: The only work that will work is that "if anything is dicey then break it out", and "if something will map to something interesting, and you warn them that it can map differently for different locales and don't map it". If you take mappings out and make them localizations something else. I don't think it's right for us to tell others (writers of ) that you're wrong because most of the world is one way. DB: I think I like where this is going, because Pete is talking about "user input method". We expect all of this to be done before it gets to the protocol. Much as I appreciated the "don't be sticky", but we can't prohibit very common letters. Joe suggested disallowing lowercase dotless-i, which I don't think we can do that. But this document says do lowercase.txt [FULL STOP]. If you get something that is expected, you're good -- if you get something unexpected, you ask the user to enter it lower case. JH: I think what John is suggesting is you look for characters that are unstable in mappings, then you ask the user what to do. JK: I am saying "these characters are dicey under mapping, then don't map". JH: +1 DB: +1 LET IT BE NOTED THAT JOHN KLENSIN, JOE HILDEBRAND, and DAVID BLACK AGREE PR: Do you need more suggestion (more text?) YY: Yes! PR: The document editor has requested that someone produce text to add. I would like the chairs to stick this to specific people. JK: I volunteer to work with the document editor on the text JH: I volunteer to review text. DB: I volunteer to review text. 3rd Issue: DB: I thought the framework added text to normatively reference this document. did we just break that? PSA: We did say you should use the case folding. We could instead say you could use this if you want. BL: I don't think there's anything that stops a normative reference to an informational document. JK: The problem is that the framework document contains text that contradicts what was decided here. The framework needs to be patched to agree with this document. AM: Why is this document Informational? It sounds like it's experimental. PR: The conversation is "there is no concrete rule on how to map. THere are recommendations we can make, but it's ultimately a user input decision." While the framework says "go do mapping here". JK: This issue is not about Informational vs. Standards Track. The issue is that this document needs to lay down the rules. I think informational here is completely clear, and the framework needs to be tweaked. MB: We know stringprep profiles want case mapping, are we kicking the can down the road? JK: I think we need to get over the stringprep stuff that got IDNA2003 in trouble. The root is that stringprep was over ambitious, and this WG needs to fix that. It probably means that we call out you can't quite do that. It's bad news for them. PR: I think to answer your question is -- yes, we are probably punting it down the road. PR: For reference, section 4.1.3 and section 5 are the problem points (reads text). What we could say is that this problem is locale dependent, and they can't just do simple case mapping. DB: iSCSI does case folding, and I think I see a way forward from here. It's not going to be take the stringprep profile and try to find a worldwide rule. What I am thinking is that we say case-folding are locale dependent -- either make sure both ends are in the same locale and otherwise require everything to be lowercase and leave it up to the UI to figure it out. MB: Are you saying that your profile will not normatively reference the mapping document? DB: It feels like the mappings document is turning into a mappings guidelines document. I'm likely to reference it for information. JH: I also that a little bit of guidance for new protocols don't have to go through a big process. MB: We could have started the guidelines document before, but it would have been rewritten many times. PSA: From a text perspective, I think we can just say "We RECOMMEND using the UNICODE case folding, and look at this other document for locale exceptions". AS: I agree with that approach, but I am concerned with what David said. The advice is "this is hard, so you should make sure the two ends have the same locale." It seems to me that you need to have some strong advice to not recommend this or have a mechanism to carry locale info. We can't depend on UNICODE because we can't depend on its locale definition. It would be possible to do, but would be much more complex to do. I am opposed to the second track, but it is a possibility. AMcD: We've been discussing on the NFSv4 list, and are you recommending something like this? DB: I have been talking with NFSv4, and we've been struggling with this. We've documented the case-folding as start with UNICODE, then add in the special-casing file, and you add what you need. Some perspective for Andrew, all of the case folding is in the input method. I can punt the whole problem up there, and say at the protocol that it already be lowercase. 2.3 Related documents - IETF Policy on Character Sets and Languages (Andrew) http://tools.ietf.org/html/draft-sullivan-rfc2277-bis-00 No time left. Next meeting. Ajourned at 14h05.