IETF
precis@jabber.ietf.org
Thursday, 28 July 2011< ^ >
stpeter has set the subject to: précis wg :) | http://tools.ietf.org/wg/precis/
Room Configuration

GMT+0
[10:10:54] Bjoern joins the room
[10:40:21] Bjoern leaves the room: Disconnected
[10:42:55] Bjoern joins the room
[15:00:07] stpeter joins the room
[15:08:45] linuxwolf joins the room
[15:25:45] linuxwolf leaves the room
[15:26:34] stpeter leaves the room
[16:40:41] yone joins the room
[16:41:49] linuxwolf joins the room
[16:46:03] stpeter joins the room
[16:53:07] Andrew Sullivan joins the room
[16:53:55] hildjj joins the room
[16:56:08] Marc Blanchet joins the room
[16:56:49] josephyee joins the room
[16:57:12] stpeter has set the subject to: précis wg :) | http://tools.ietf.org/wg/precis/ | IETF 81 | slides at https://datatracker.ietf.org/meeting/81/materials.html#wg-precis | audio at http://ietf81streaming.dnsalias.net/ietf/ietf802.m3u
[17:00:57] <hildjj> Note: OSX 10.7 "Lion" has a new input mechanism for accented characters. Push and hold down the "base" character, then choose which variant you want. Example, hold down "e" then type "2" to get é.
[17:01:45] Jim Galvin joins the room
[17:02:08] Dowon Kim joins the room
[17:03:11] <linuxwolf> administrivia
[17:03:11] yoiwa joins the room
[17:03:23] Simon Perreault joins the room
[17:03:27] <linuxwolf> wg deliverables
[17:03:28] <stpeter> we will work to capture action items and major points of discussion in the jabber room
[17:03:29] resnick joins the room
[17:04:10] <linuxwolf> wg doc status
[17:04:59] <linuxwolf> problem statement discussion (Andrew Sullivan)
[17:05:03] Dave Thaler joins the room
[17:05:19] <linuxwolf> -0 major changes
[17:05:27] <linuxwolf> s/-0/-03/
[17:05:31] microai76 joins the room
[17:05:51] <linuxwolf> -0 new problems
[17:06:01] <linuxwolf> s/-0/-03/
[17:07:17] <linuxwolf> problem statement vs framekwork
[17:07:26] <linuxwolf> s/framekwork/framework
[17:08:16] <linuxwolf> peter saint-andre: Not sure if blobs are useful. Are they for things for the application to need to fit in a slot, or is it just something that's there and the application does what it will with
[17:08:40] <linuxwolf> AS: I wanted to distinguish between freeform things and things that are there but shouldn't be messed with
[17:09:04] <linuxwolf> AS: Example — I had an example in mind when I wrote this down, but I can't remember it now
[17:09:24] <linuxwolf> Joe Hildebrand: I think there are things we'll need to pass along, but do not need c18n work
[17:09:46] <linuxwolf> JH: Things that are there that shouldn't be futz with, just byte-for-byte comparisons
[17:10:01] <linuxwolf> AS: Wondering if you ever had a free class that doesn't need to be normalized
[17:10:29] <linuxwolf> AS: If there needs to be a distinction, then we can keep it, otherwise it's stupid and we should get rid of
[17:10:51] <linuxwolf> Pete Resnick: If we have something that's just data and needs to be there, then we need a blob class
[17:11:20] <linuxwolf> ??: If they're just bytes, then that shouldn't be PRECIS?
[17:11:38] <linuxwolf> PR: The blobclass is the exclusion, that shouldn't be touched
[17:11:53] <linuxwolf> JH: I disagree with based on user input
[17:12:11] <linuxwolf> JH: If there transformed in one way, but are not messed with in any other way
[17:12:35] <linuxwolf> JH: For instance, I set a resource which is important for lookups…but the server never should do anything with it
[17:12:58] <linuxwolf> PSA: Disagree, since we sometimes copy-and-paste identifiers for sending
[17:13:33] <linuxwolf> PR: There's never a case where I copy something and place that into a user input field, and expect that to be directed to you?
[17:13:41] <linuxwolf> JH: let's thing about a case...
[17:14:07] stpeter is now known as πßå
[17:14:08] <linuxwolf> JH: If we have a list of room occupants, and the user clicks on that sends it is one issue
[17:14:18] <πßå> gotta use some non-ASCII characters here :)
[17:14:26] <linuxwolf> JH: but the client shouldn't be touching it beyond the exact octets it got
[17:14:35] yuioku joins the room
[17:14:48] <linuxwolf> MB: Why are we spending a lot of time on this if it's not something we need to identify on it
[17:15:01] <linuxwolf> PSA: It's worth talking about it to determine if we need the distinction
[17:15:09] <linuxwolf> JH: I think the distinction is important
[17:15:30] <linuxwolf> JH: If we need something that says "don't futz with it at all", then we have a blobclass
[17:15:47] <linuxwolf> JH: But if have something that might be messed with a little, then this is what the freeclass can be fore
[17:15:48] <linuxwolf> for
[17:15:52] Florian Zeitz joins the room
[17:16:00] <linuxwolf> (please correct my mistakes)
[17:16:09] <linuxwolf> Appendix A table slide
[17:16:34] <hildjj> To clarify for the notes, the kind of "messing" that I'm talking about is NFK?[CD] and not much else
[17:16:42] <linuxwolf> David Black: I think the table's mapping from the protocols to the tables being used is useful
[17:17:04] <linuxwolf> DB: I got the easy one, iSCSI done, and now I need to mess with NFS
[17:17:21] <linuxwolf> AS: Is this table useful, or do we have things that need to be added?
[17:17:26] <linuxwolf> DB: I think it's fine for now
[17:17:37] <linuxwolf> ??: I also think it's useful and fine for onw
[17:17:38] <linuxwolf> now
[17:17:42] <Dave Thaler> ??=Dave Thaler
[17:18:01] <linuxwolf> MB: point of clarification, this is about appx B, not A
[17:18:20] <linuxwolf> AS: The intention was to copy the info out of the tracker, but we just need to summarize?
[17:18:41] <linuxwolf> MB: Just copy-paste is fine for now, but some level of editorial may be needed
[17:18:55] <linuxwolf> — framework (Peter Saint-Andre) --
[17:19:40] microai76 leaves the room
[17:20:02] <linuxwolf> Goals
[17:20:16] <linuxwolf> (emphasis on **usable**)
[17:20:34] <linuxwolf> probably talk about protocols to subclass
[17:20:42] <linuxwolf> Framework slide
[17:21:37] <linuxwolf> String Classes slide
[17:21:47] <linuxwolf> boo on the names
[17:21:50] <linuxwolf> (-:
[17:23:12] <linuxwolf> DB: I assume domain names are CIDNs and that probably needs to be stated here because it doesn't always turn up
[17:23:21] <linuxwolf> PSA: I think we need to just say, "see IDNA"
[17:23:31] <linuxwolf> NameClass: PVALID slide
[17:24:07] <linuxwolf> NameClass: DISALLOWED slide
[17:24:33] <linuxwolf> need to talk about things that have a compatibility equivalence?
[17:24:50] <linuxwolf> NameClass; Mapping slide
[17:25:12] <linuxwolf> SecretClass: PVALID slide
[17:25:48] <linuxwolf> SecretClass: DISALLOWED
[17:25:53] <linuxwolf> might actually want spaces
[17:26:22] <linuxwolf> John Klensin: The only thing you want to watch out for in compatibility equiv is because the editor might sometimes try to change things on you
[17:26:40] <linuxwolf> JK: You might get two different characters even though you typed in the same thing (across different systems)
[17:26:51] Jacky Yao11 (Health Yao) joins the room
[17:27:11] <linuxwolf> Stuart: Maybe I'm misunderstanding this, but the rules for DISALLOWED goes against the face of good practice
[17:27:34] <linuxwolf> PSA: Well, everything in ASCII is grandfathered in…but anything else is up for discussion
[17:27:51] <linuxwolf> Stuart: maybe I didn't have all the context, but the slide is not entirely clear
[17:28:05] <linuxwolf> PSA: Its still a good point, there might be more we want to introduce here
[17:28:21] <linuxwolf> Tony: I made the same mistake here, without all of the context
[17:28:38] <linuxwolf> PSA: The more important question is whether we want the other things in there
[17:29:08] <linuxwolf> KJ: and that's the question here…if you want the card gylphs, and chess signs, and what not may not be wanted…but adding them might make for really good passwords
[17:29:27] <linuxwolf> KJ: I can't give you any advice here, but is worth considering
[17:29:47] <linuxwolf> PSA: It might be that SASL says it's ok, but the systems might want to do something more restrictive
[17:30:06] <linuxwolf> KJ: and single signon things might want to allow more here to meet their requirements
[17:30:27] <linuxwolf> JH: So there's a bunch of codepoints that are 127 or below that are, surprising to me, that have class information
[17:30:41] <linuxwolf> JH: For instance the h-tab is marked as a control character, not a space charactre
[17:30:54] <linuxwolf> JH: It's a finite set, and relatively easy to compare
[17:31:16] <linuxwolf> JH: So for 127+ we have the character classes, but for 127 and below we have the specific character tables for those
[17:31:53] <linuxwolf> PR: The problem with symbol and punctuation characters is that on a different keyboard might not produce what you want (or even if you can)
[17:32:04] <hildjj> another example: \r and \n are not whitespace, they're control characters.
[17:32:35] <linuxwolf> PR: However, if I know what I've got, then being able to use more characters that will make it harder for someone else to guess it because their keyboard can't input that
[17:32:53] <linuxwolf> PR: Like those on a spanish keyboard has the ¿ that it;s really convenient to use
[17:33:02] <linuxwolf> PR: so we don't want to restrict this too much
[17:33:04] <linuxwolf> (??)
[17:33:37] <linuxwolf> MB: Not being a native english speaker, I don't think people will want to be constrained by english, and will want to type things as their native language allows
[17:33:58] <linuxwolf> MB: And maybe we should talk to the kerberos and kitten people to see what they're input is
[17:34:05] Suz joins the room
[17:34:16] <josephyee> (??) = Klensin - but don't want over encourage such use
[17:34:19] <linuxwolf> MB: And we might not want to restrict this, and should talk to the others to see what their characters are
[17:34:26] <linuxwolf> grazie
[17:35:10] <linuxwolf> Stuart: I think the IETF should have some document that clearly states what is allowed, so those with bad processors (e.g. stupid perl scripts) we can go back and tell them to fix them
[17:35:32] <linuxwolf> Stuart: And to Klensin's point, I think having it clarified is worth having somewhere
[17:36:05] <linuxwolf> AS: This all started with IDNA2008…we've got this ginormous repetríore of characters to use, but don't use them all
[17:36:42] <linuxwolf> PSA: Here are the guidelines, but it's up to the protocols and users
[17:36:58] <linuxwolf> AS: That was a general remark for all of our classes
[17:37:10] yuioku leaves the room
[17:38:03] <linuxwolf> PSA: Going with the Principle of least surprise, we don't want things to be radically different between say an email client and a jabber client
[17:38:23] JcK joins the room
[17:38:24] <linuxwolf> PSA: and maybe we need to provide some guidance for consistency to help with the consistency
[17:38:31] <linuxwolf> SecretClass: Mapping
[17:38:43] <linuxwolf> PR: I think we can be stronger on some of these things, like NOT map case
[17:39:15] <linuxwolf> PR: Normalization maybe, but bidi…most of these things aren't displayed to the user, so it might not be necessary to worry about
[17:39:37] <linuxwolf> PR: But even copy-paste should work, because it'll be copied in the logical order, as long as you copy the entire thing
[17:39:51] <linuxwolf> PR: But you might be surprised if you copy from the secret to something visual
[17:39:59] Simon Perreault leaves the room
[17:40:11] Suz leaves the room
[17:40:12] <linuxwolf> JH: I agree with Pete, but might go a little further, and give a little more guidance
[17:40:35] <linuxwolf> JH: We suggest you obscure what the user types, and here's some things that might be bad if you end up displaying what the user types
[17:40:48] <linuxwolf> FreeClass: PVALID
[17:40:54] <linuxwolf> (anything goes)
[17:41:03] <linuxwolf> FreeClass: DISALLOWED
[17:41:11] <linuxwolf> FreeClass: Mapping
[17:41:48] <linuxwolf> apps might want to map case and other things, but we don't put a restriction here
[17:42:03] <linuxwolf> JH: We might do those special cases into a different registrar
[17:42:25] <linuxwolf> JH: For instance, if we wanted to have a restriction in XEP-0045, we can do that in the XEP and have a registrar for that
[17:42:53] <hildjj> By the way, the confusable stuff is now talked about in Unicode's TR39: http://unicode.org/reports/tr39/#Confusable_Detection
[17:42:59] <linuxwolf> PR: I think it's worth mentioning that in the document explicitly, about registration … we are using IDNA as the basis
[17:42:59] <hildjj> and the table is here: http://www.unicode.org/Public/security/revision-04/confusables.txt
[17:43:14] <linuxwolf> PR: We are using protocol as you use them versus as you type them
[17:43:38] <linuxwolf> PR: what you type might have some different requirements than how you use them
[17:43:49] <linuxwolf> JH: We might come up with a new confusing error condition
[17:44:18] <linuxwolf> PSA: For instance, someone is using latin-a, and you attempt to join with cyrillic-a, you can't join
[17:44:27] <linuxwolf> MB: So the error code is confusing?
[17:44:36] <linuxwolf> JH: That's for the XMPP WG to figure out
[17:44:40] <linuxwolf> Case Study: XMPP
[17:45:08] <linuxwolf> (this is talked about in 6122bis)
[17:45:37] yuioku joins the room
[17:45:46] <hildjj> <confusing xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
[17:46:35] Dave Thaler leaves the room
[17:47:37] <linuxwolf> JH: this is a place where if we had had the blobclass, and we had it to begin with, we would have used it here
[17:47:53] <linuxwolf> JH: but since we didn't, then freeclass is what we use here
[17:48:03] <linuxwolf> JH: Maybe for something in the future, we just use the blobclass
[17:48:21] <linuxwolf> PR: <ominously approaches mic>
[17:48:31] <linuxwolf> PR: two things
[17:49:16] <linuxwolf> PR: On Joes point, one of the things you can do is push it back to a mapping on the user input, and reduce them to something that will only be used with NFC, and might reduce the user surprised
[17:49:34] <linuxwolf> PR: two, you said that any RTL means the whole thing is RTL?
[17:49:42] <linuxwolf> PSA: We're not sure either
[17:50:05] <linuxwolf> PR: it sounds like what you're saying is, if you want a RTL character, then it must all be RTL, but that's really complicated and lousy
[17:50:31] <linuxwolf> PR: mostly because a lot of characters that are LTR, are really easy to type in RTL
[17:50:42] <linuxwolf> JH: We might have to fall back to the bidi rule
[17:50:54] <linuxwolf> PR: caveat, this is coming from someone that objects to the bidi rule
[17:51:08] <linuxwolf> PR: Bidi characters can do weird things when you see them on the screen
[17:51:26] <linuxwolf> PR: and IDNA wanted to restrict the weirdness
[17:51:47] <linuxwolf> PR: You can say that you're willing to put of with the weirdness, because they're mostly used in one case, and not in others
[17:52:11] <linuxwolf> JK: The bidi rule is meant to produce predictability, but not meant for natural viewing
[17:52:31] <linuxwolf> JK: good for predictability, but not good for what the user sees
[17:52:54] <linuxwolf> JK: there INDA2003 bidi rule, the IDNA2008 bidi rule, and the new revised bidi rule
[17:53:07] <linuxwolf> JK: we need to be clear on what bidi rule we are using, or come up with a new one
[17:53:17] <linuxwolf> PSA: we are referring to 5824? rule
[17:53:46] <linuxwolf> PR: the IDNA folks adopted the bidi rule is a situation where this stuff should be internationally recognized
[17:53:56] <linuxwolf> PR: If you see it on the side of a bus, you might want to type these
[17:54:25] <linuxwolf> PR: the bidi rule is something where you can hunt and peck, and think that's what was seen on the ad or bus
[17:54:54] <linuxwolf> PR: But most people typing these might only have one context in different things
[17:55:25] <linuxwolf> JH: What he said, IIRC, you can normalize on the user input
[17:55:38] <linuxwolf> JH: but if you say that, you might as well call these bag-o-bits
[17:55:39] Chris Newman joins the room
[17:55:48] <linuxwolf> PR: not necessarily (per protocol)
[17:56:11] <linuxwolf> PR: you might type these in, you might do some normalize, but then in use from different aspects you use different forms
[17:56:28] <linuxwolf> JH: I hear what you're saying, but don't think that happens
[17:56:40] <linuxwolf> AS: I don't think near predictability is useful for a lot of users
[17:56:56] <linuxwolf> AS: I happen to be working with a lot of users, and they say, "but that's not how it should display"
[17:57:11] <linuxwolf> AS: They have a lot of intuition on how it should display, and bidi isn't it
[17:57:38] <linuxwolf> AS: We should get some input for people to not come up with a new bidi rule, but to determine why there's a psychic resistance to it
[17:58:04] <linuxwolf> JH: The people coming up withe the new bidi rule have that expertise, and will result in something less unexpected?
[17:58:10] <linuxwolf> JK: Yes..or no!
[17:58:20] <linuxwolf> AS: The right answer in a lot of these cases is…it doesn't work
[17:59:06] <linuxwolf> JK: Joe, despite the fact that I get irritated with the situation where we use UNICODE in environment where we use characters across scripts
[17:59:34] <linuxwolf> JK: They were faced with a near impossible task, and have to make comprimises…do they get it right…mostly
[17:59:43] <linuxwolf> JK: The question turns out not to be well formed
[17:59:51] <linuxwolf> JH: Let me ask a slightly different question
[18:00:16] <linuxwolf> JH: With our crystal ball hat…do we think the new rule will fit their current purpose, or not
[18:00:40] <linuxwolf> JK: The old bidi rule was addressing a different purpose than this, the new bidi rule was addressing a different purpose than this…take your pick
[18:00:46] <linuxwolf> Open Issues
[18:00:51] <linuxwolf> JK: One more thing.
[18:01:05] <linuxwolf> JK: Keep in mind the number of strictly RTL scripts is 0
[18:01:29] <linuxwolf> JK: The possibility of getting this right is 0 because there is no right
[18:01:44] <linuxwolf> JH: Then this is when I say we need to do something that slightly less wrong
[18:01:58] <linuxwolf> PR: Let me go back to something we said earlier…there is no right here (JK is right)
[18:02:10] <linuxwolf> PR: However, it could be that your protocol doesn't care about this issue
[18:02:32] <linuxwolf> PR: domain names have a special requirement that makes this more uptight…maybe we shouldn't get too uptight about this
[18:02:47] <linuxwolf> JK: Most users of the internet are smart or educationable or both
[18:03:05] <linuxwolf> JK: So tell them to just get used to it because there's not way to fix it
[18:03:37] <linuxwolf> JK: When we first put this together, people have gotten used it, and now we're trying to be much more explicit
[18:03:43] <linuxwolf> (back to open issues)
[18:05:19] <linuxwolf> MB: I think some answers to these questions are up to the customers of precis
[18:05:33] <linuxwolf> MB: this is a call to the customers to precis to think of what you need, and fix the base classes
[18:06:06] <linuxwolf> PR: I would like to drag up whoever is a protocol person, and say "Do you think we have the right classes"
[18:06:29] <linuxwolf> PR: I do think that distinction between the subclassing and registration will help come up with some of the fixes
[18:06:47] <linuxwolf> DB: I suspect for iSCSI that we have the building blocks
[18:07:04] <linuxwolf> DB: But I suspect I'll have some subclasses to come up with because of punctionation
[18:07:10] <linuxwolf> DB: mapping…yes please, guidance
[18:07:22] <linuxwolf> DB: NFS is going to be a bit more complicated, so we need to figure out what's going to go on there
[18:07:42] <linuxwolf> DB: And what should we do with the stuff that breaks with moving to IDNA2008, and what should we do about that
[18:08:29] <linuxwolf> DB: in essence, independent of what you do going forward…whatever you do will need to deal with backwards compatibility with the ancient version of unicode
[18:09:07] <linuxwolf> JH: I would prefer that we don't need to have XEP-0106 anymore because of different restrictions, and have one way of quoting stuff to be in your accepted list would be useful
[18:09:29] <linuxwolf> JH: But if you use the generic percent encoding thing, but have the same semantic meaning with different bytes on the wire
[18:09:45] <linuxwolf> JH: We only allowed for specific encoding for those things that are not allowed in your subclass
[18:09:50] <hildjj> http://xmpp.org/extensions/xep-0106.html
[18:10:08] <linuxwolf> AS: since the mapping case came up, I don't know what that means…does that mean the document should have mapping itself, or do it like IDNA2008
[18:10:25] <linuxwolf> AS: where you don't have a mapping, but you have a rule, which might have some mapping translation
[18:10:33] <linuxwolf> JH: I was talking about mapping between protocols
[18:11:01] <linuxwolf> AS: one answer for the backward compatibility problem is we'll generate this list, and before you enter this in you have a shim that does some preprocessing that fixes it before it goes
[18:11:15] <linuxwolf> AS: So we make it part of the protocol that as a nice effect that it can solve this problem
[18:11:28] <linuxwolf> MB: About the point on mapping guidlines
[18:11:58] <linuxwolf> MB: we also have another document about guidelines, and start to talk about what we put in there versus the framework
[18:12:13] <linuxwolf> PSA: I couldn't remember the difference between what goes where
[18:12:47] <linuxwolf> DB: One example — mapping with protocols that I care about, the mapping happens before you drop the string goes into the protocol…but it's possible to screw it up
[18:13:38] <linuxwolf> Joseph Tee: With regard to the your classes, what about half-width/full-width
[18:13:50] <linuxwolf> PSA: We didn't have the expertise in the room for the Brussels meeting
[18:14:25] <linuxwolf> JH: The particular question we had was that these were compatibility equivalent but not canoncially equivalent
[18:14:37] <linuxwolf> JH: The question is do you need to use both?
[18:15:12] <linuxwolf> JT: I don't remember the property to determine the mapping
[18:15:46] <linuxwolf> PR: I am 99.9% certain that NFKC maps the half-widths to full-widths
[18:16:17] <linuxwolf> PR: So the question is that the full and half width won't map to each other…so if you map both to ASCII
[18:16:36] <linuxwolf> JH: I am worried about half-width hangul
[18:16:40] <linuxwolf> room: that's different
[18:17:04] <linuxwolf> JH: half-width characters have a compatibility property to a full-width character
[18:17:17] <linuxwolf> TY: Do you want to use them is some classes, but not others?
[18:17:32] <linuxwolf> JH: The one we're most worried about is names…as long as you can type them distinctly
[18:17:47] <linuxwolf> JH: as for free class, I don't think I really care, as long as registries help with this
[18:17:58] <linuxwolf> JH: I think I only care about this for name class
[18:18:20] <linuxwolf> JY: I will do some research
[18:19:40] Dave Thaler joins the room
[18:19:49] <linuxwolf> PSA: The mapping recommendations is something we can probably say more about…it's one of the biggest problems we have in other protocols
[18:20:28] <linuxwolf> PR: because domain names have a set of constraints that made life..predictable…the registrar is going to deal with this problem, and you'll build tools to get the result you want
[18:20:57] <linuxwolf> PR: Maybe the chairs should assign someone to do some research and get some general answers to the problems and write them up in some interesting way
[18:22:07] <linuxwolf> PSA: Confusable characters
[18:22:28] <linuxwolf> PSA: This might not be something we want to talk about directly, but we might want to provide some recommendation to registrars
[18:22:54] <linuxwolf> JH: I did some research, and found there's now a table for a mapping to potentially confusable characters
[18:23:14] <linuxwolf> PR: there can be discussion of confusables, but almost inevitably you can't solve this problem.
[18:23:29] <linuxwolf> PR: and we can say you could go down this path, but you can't really solve this problem
[18:23:51] <linuxwolf> JH: If we're going to make this suggestions to registrar-like things, we need to say something
[18:23:58] Jim Galvin leaves the room
[18:24:07] <linuxwolf> JH: It seems reasonable to go talk to the UNICODE people and add this to the unicode table
[18:24:28] <linuxwolf> AS: the thing that is slightly dangerous is that this table can open up a new list of backward compatible list...
[18:24:47] <linuxwolf> AS: and things that were differentiated, and now aren't...
[18:25:21] <linuxwolf> AS: It seems to me is what we've got here is a category of disallowed, and if this is one of those then we can put this here…and trust unicode on this
[18:25:41] <linuxwolf> AS: The problem is if something seriously changes, we'll have a problem we'll need to deal with here
[18:26:15] <linuxwolf> AS: This is the first time the confusables list is the first time it's shown to anywone, while the backward compatibility list has been around a little longer
[18:27:02] <linuxwolf> JH: I would expect that if there were new things that were added to that list, that the registrars would need to go back and look at that list, and treat this as policy issues.
[18:27:26] <linuxwolf> AS: It's fine if we call this a policy issues, but users are going to be impacted by this no matter what
[18:27:48] <linuxwolf> JH: So dealing with the unassigned list needs to be put on the open issues list
[18:28:24] <linuxwolf> AS: We have a category for unassigned…someone might have a version of unicode that has it assigned, then you need to interoperate or lose
[18:28:53] <linuxwolf> AS: As a registry you can have a policy, but you should be careful on how you use the confusable list
[18:29:20] <linuxwolf> JH: I guess what we need to do is to map unassigned to an error rather than to nothing
[18:29:42] <linuxwolf> Chairs ask if we should add this as a working group document
[18:30:23] <linuxwolf> consensus to adopt framework as a wg document
[18:30:47] <linuxwolf> PSA: I will be happy to move to the working group, and clean up things from this meeting
[18:30:53] <resnick> More importantly: No objections to adopting.
[18:31:00] <linuxwolf> thanks
[18:31:06] hildjj leaves the room: Disconnected.
[18:31:06] <resnick> (Everyone always *wants* to adopt documents. ;-) )
[18:31:08] Marc Blanchet leaves the room
[18:31:11] <linuxwolf> *chairs bang gavel*
[18:31:19] Chris Newman leaves the room
[18:31:19] <linuxwolf> good point
[18:31:22] JcK leaves the room
[18:31:27] <linuxwolf> and now my fingers hurt (-:
[18:31:34] <linuxwolf> at least we didn't have EKR
[18:31:50] Andrew Sullivan leaves the room
[18:32:43] linuxwolf leaves the room
[18:32:55] resnick leaves the room
[18:33:46] yuioku leaves the room
[18:33:55] josephyee leaves the room
[18:34:41] Dowon Kim leaves the room
[18:34:54] Florian Zeitz leaves the room
[18:34:58] Florian Zeitz joins the room
[18:40:35] Jacky Yao11 (Health Yao) leaves the room
[18:42:03] yoiwa leaves the room
[18:42:26] yone leaves the room
[18:45:35] Dave Thaler leaves the room
[18:52:51] behnam joins the room
[18:53:11] behnam leaves the room
[18:53:30] Florian Zeitz leaves the room: offline
[19:01:17] Jacky Yao11 (Health Yao) joins the room
[19:03:16] Bjoern leaves the room
[19:13:05] Jacky Yao11 (Health Yao) leaves the room
[19:23:51] Jacky Yao11 (Health Yao) joins the room
[19:24:49] Jacky Yao11 (Health Yao) leaves the room
[19:29:15] linuxwolf joins the room
[19:45:31] Marc Blanchet joins the room
[19:54:34] linuxwolf leaves the room
[19:58:58] Chris Newman joins the room
[20:06:04] Chris Newman leaves the room
[20:09:37] Chris Newman joins the room
[20:26:30] Dowon Kim joins the room
[20:27:33] Dowon Kim leaves the room
[20:31:43] linuxwolf joins the room
[20:46:58] Chris Newman leaves the room
[21:10:36] linuxwolf leaves the room
[21:14:53] Marc Blanchet leaves the room
[22:25:29] πßå leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!