Re: i18n name badges
John, Ah I see now. Yes, there is leakage in Punycode now and will be for a while. It is not nice but I couldnt think of any encoding which wont leak. (UTF-8 will give you gibberish if client are not UTF-8 aware or with the right fonts). Same arguments we have in IDN WG many years ago. We want to put punycode on the badge so that eat our own dogfood, then yes, maybe we should. But given the space constraint on the badges, I rather put something more meaningful, like an .PNG of the person name. -James Seng John C Klensin wrote: James, My apologies for being a bit cryptic -- I hoped people would understand the issues well enough by now to get the point. The difference between the design of --and hopes for-- IDNA and what is happening is something the community needs to understand and be better informed about. The design of Punycode was for machine-to-machine communication, as you point out. It was never really intended or expected to leak into use environments. Indeed, it was chosen, in preference to some other options, on the grounds that * it could be deployed quickly, * applications could (and would) be speedily updated to support it and provide proper native character set presentation to users, * when it did leak, users would find that acceptable because they could always convert to and from native/local characters with cut and paste and readily-available tools. The reality so far is different. The IDN browser world has turned into one of conflicting plug-ins, apparently none of which are fully satisfactory. For other applications, the conversion/ upgrade rate has been low and most estimates seem to point to its being at least 18 more months before we see significant progress in applications that have really wide deployment (and estimates that optimistic often depend on other conditions or contingencies that might or might not happen). So IDNA/punycode is leaking a lot, and can be expected to leak a lot for the next several years, at least. And that implies that the IETF community should probably understand what it looks like and what the issues are in converting to and from it, including the fact that, for expression of names, nameprep is a lossy conversion. And that is precisely the eat our own dogfood point.More important, we need to think about --and probably experience-- that point as we consider approaches for email local parts, which more often contain names about which people are _really_ sensitive. john --On Thursday, 20 November, 2003 11:05 +0800 James Seng [EMAIL PROTECTED] wrote: I think having the punycode form have no value on a name badge. Punycode, as it is designed, is meant for machine-to-machine communication. But I like the idea of allowing participation to put their own native names together with their ASCII version on the name badge especially for the next IETF. But... 1. What if the person don't have ASCII only name? (e.g. Patrik Fältström) 2. What if the person have a name which the computer cant be printed? (Maybe it is not in ISO 10646, maybe it is but there is no fonts, maybe the fonts is there but the rendering is wrong?) Since we are on the topic of the name badge, it is possible to somehow tag the family name of the person? (e.g. underline? bold? captialized?) Not everyone follows the Last Name First Name convention. In fact, the concept of First and Last name is quite alien to me. -James Seng Dave Crocker wrote: Fred, FB What I would suggest, if we do this, is writing the person's name *twice*: FB once in their native character set, and once in a form that an FB english-reader can read. The latter is an established interchange architecture I believe that was the intention in the proposal. List names in the same way we always have, AND list them in their native form. Whether it would helpful to provide a third form -- the ascii encoding of the native form, as it would be seen in an email address header -- is a separate question. /d -- Dave Crocker dcrocker-at-brandenburg-dot-com Brandenburg InternetWorking www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253
Re: i18n name badges
On 23-nov-03, at 12:47, James Seng wrote: Yes, there is leakage in Punycode now and will be for a while. It is not nice but I couldnt think of any encoding which wont leak. (UTF-8 will give you gibberish if client are not UTF-8 aware or with the right fonts). Same arguments we have in IDN WG many years ago. This implies that the conversion must take place at the semantic level rather than the encoding level. This should result in converted representations that can be pronounced, remembered and recognized, at the cost of somewhat large translation tables.
Re: i18n name badges
James, My apologies for being a bit cryptic -- I hoped people would understand the issues well enough by now to get the point. The difference between the design of --and hopes for-- IDNA and what is happening is something the community needs to understand and be better informed about. The design of Punycode was for machine-to-machine communication, as you point out. It was never really intended or expected to leak into use environments. Indeed, it was chosen, in preference to some other options, on the grounds that * it could be deployed quickly, * applications could (and would) be speedily updated to support it and provide proper native character set presentation to users, * when it did leak, users would find that acceptable because they could always convert to and from native/local characters with cut and paste and readily-available tools. The reality so far is different. The IDN browser world has turned into one of conflicting plug-ins, apparently none of which are fully satisfactory. For other applications, the conversion/ upgrade rate has been low and most estimates seem to point to its being at least 18 more months before we see significant progress in applications that have really wide deployment (and estimates that optimistic often depend on other conditions or contingencies that might or might not happen). So IDNA/punycode is leaking a lot, and can be expected to leak a lot for the next several years, at least. And that implies that the IETF community should probably understand what it looks like and what the issues are in converting to and from it, including the fact that, for expression of names, nameprep is a lossy conversion. And that is precisely the eat our own dogfood point.More important, we need to think about --and probably experience-- that point as we consider approaches for email local parts, which more often contain names about which people are _really_ sensitive. john --On Thursday, 20 November, 2003 11:05 +0800 James Seng [EMAIL PROTECTED] wrote: I think having the punycode form have no value on a name badge. Punycode, as it is designed, is meant for machine-to-machine communication. But I like the idea of allowing participation to put their own native names together with their ASCII version on the name badge especially for the next IETF. But... 1. What if the person don't have ASCII only name? (e.g. Patrik Fältström) 2. What if the person have a name which the computer cant be printed? (Maybe it is not in ISO 10646, maybe it is but there is no fonts, maybe the fonts is there but the rendering is wrong?) Since we are on the topic of the name badge, it is possible to somehow tag the family name of the person? (e.g. underline? bold? captialized?) Not everyone follows the Last Name First Name convention. In fact, the concept of First and Last name is quite alien to me. -James Seng Dave Crocker wrote: Fred, FB What I would suggest, if we do this, is writing the person's name *twice*: FB once in their native character set, and once in a form that an FB english-reader can read. The latter is an established interchange architecture I believe that was the intention in the proposal. List names in the same way we always have, AND list them in their native form. Whether it would helpful to provide a third form -- the ascii encoding of the native form, as it would be seen in an email address header -- is a separate question. /d -- Dave Crocker dcrocker-at-brandenburg-dot-com Brandenburg InternetWorking www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253
Re: i18n name badges
John, JCK The design of Punycode was for machine-to-machine communication, as JCK you point out. It was never really intended or expected to leak JCK into use environments. ... JCK Indeed, it was chosen, in preference to some other options, on the JCK grounds that JCK* it could be deployed quickly, JCK* applications could (and would) be speedily updated to ... JCK* when it did leak, users would find that acceptable ... The ascii-encoding paradigm for incremental adoption is expected to have four usage characteristics: 1. It can be deployed usefully on an incremental basis, where incremental means that it becomes useful when very few people have adopted it -- for example, useful for the first two users that exchange it -- and is increasingly useful as more people adopt it. 2. It is transparent to the transfer infrastructure 3. When it shows up at an un-modified application, such as a mail user agent, it does not break the system. 4. Data entry can be done in unmodified application, such as an email Reply command, albeit typing the string will probably not be an experience to savor. Hence, #1 #2 mean it can be deployed quickly because it does not require everyone to adopt it, before it is useful. This is in marked contrast with any approach that first requires modifying the infrastructure. #2 and #3 clearly imply that end-users will see these strings. So, leakage is entirely expected. It is not desired, but it is expected. The concern is not whether such leakage occurs or whether the string is human-friendly. The concern is whether anything breaks, when it does show up, as we know it will. And, indeed, Punycode does not break legacy software. So it satisfies the requirements and expectations of this incremental adoption paradigm, just fine. JCK The reality so far is different. The IDN browser world has JCK turned into one of conflicting plug-ins, apparently none of JCK which are fully satisfactory. Since I am far less than a diligent reader, I have not seen the discussion of this, but I certainly would like to understand it better. Any citations to material on this would be appreciated. My sense of most adoption processes, for any interesting bit of application technology, is that it has an ugly startup. For example, the first interoperability test of TCP did not initially work. Folks had read the spec differently for the checksum algorithm. (And the way this was resolved was to look for the first pair of hosts that could communicate and then retrofit the specification with whatever algorithm they were using.) Another downside of not being a diligent reader is that I do not recall seeing discussion of interoperability testing for IDNA. Surely it has been done? Should more events be scheduled? JCK For other applications, the JCK conversion/ upgrade rate has been low and most estimates seem to JCK point to its being at least 18 more months before we see JCK significant progress in applications that have really wide JCK deployment Let's ignore that the RFCs were issued only in March of this year. Let's use the IESG Last Call as the release date. That means May, 2002. Starting from that milestone, and accepting your estimate of 18 months, it means that IDNA will be significantly useful within 3 years of completion. Offhand, I'd say that matches the experience with MIME, and matches the general expectations for adoption of a scheme that provides incremental benefit. This is quite a bit shorter than the adoption times for an approach that requires infrastructure change. (Even now, does anyone really rely on email Delivery Service Notices working over the public Internet? It had its last call in 1995.) So, your assessment of the likely time it will take for IDNA to be significantly useful strikes me as very good news, indeed. JCK the IETF community should probably understand what it looks like JCK and what the issues are in converting to and from it, including JCK the fact that, for expression of names, nameprep is a lossy JCK conversion. And that is precisely the eat our own dogfood JCK point.More important, we need to think about --and probably JCK experience-- that point as we consider approaches for email JCK local parts, which more often contain names about which people JCK are _really_ sensitive. The question of lossiness does not have to do with the incremental adoption paradigm. It has to do with problems in the details of the IDNA mapping algorithm. My own suspicion has been that it tries to do too much. That is certainly my sense of the IMAA scheme. It needs to do less. It needs to be more literal. From a design standpoint, this is a matter of tuning the details, rather than rejecting the paradigm. d/ -- Dave Crocker dcrocker-at-brandenburg-dot-com Brandenburg InternetWorking www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253
Re: i18n name badges
On 20-nov-03, at 4:05, James Seng wrote: I think having the punycode form have no value on a name badge. Punycode, as it is designed, is meant for machine-to-machine communication. So why don't we come up with a machine-to-human transliteration mechanism? So if someone called (trouble with spamcontrol again...) a translation table could turn this into Zeus and back again where appropriate. If the translation table doesn't know this could be translated into ZITA-epsilon-ypsilon+grave-sigma, which isn't great but still much better than just numbers or base64 or whatever. But I like the idea of allowing participation to put their own native names together with their ASCII version on the name badge especially for the next IETF. But... 1. What if the person don't have ASCII only name? (e.g. Patrik Fltstrm) I guess do the same thing as is being done today... 2. What if the person have a name which the computer cant be printed? (Maybe it is not in ISO 10646, maybe it is but there is no fonts, maybe the fonts is there but the rendering is wrong?) Easy enough: allow people to supply a graphic.
Re: i18n name badges
JORDI PALET MARTINEZ wrote: It should be RFID, cheaper, and easier, not only for the blue sheets. How would RFID be cheaper than barcodes? Someday, maybe, but today the tags are expensive--according to CNet, depending on volume, customers can expect to pay 30 cents to $1 per radio tag. The IETF would be low-volume, so we'd probably be paying closer to $1 apiece. So just the tags for just one meeting would cost more than a passel of barcode scanners. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |A successful tool is one that was used to do something undreamed| |of by its author. | \/
Re: i18n name badges
Dave Crocker wrote: What I would suggest, if we do this, is writing the person's name *twice*: once in their native character set, and once in a form that an english-reader can read. The latter is an established interchange architecture I believe that was the intention in the proposal. List names in the same way we always have, AND list them in their native form. Whether it would helpful to provide a third form -- the ascii encoding of the native form, as it would be seen in an email address header -- is a separate question. It seems to me that this is really the heart of the matter. There are too many encodings. There are going to be *at least* three desirable encodings of a person's identity -- the 'natural' encoding in the preferred/native charset of the person's name, some kind of phonetic-ASCII encoding that tells non-natives how to pronounce the name, and the email/idna encoding[s] that folks would use to exchange mail. Of the two 'name' forms, it might be possible for the protocol to choose just one encoding based on the meeting context. For example, if the meeting attendees are entirely (or mostly) native speakers of the same language, then use the natural encoding for the names and just ignore the phonetic ASCII entirely. If the meeting is heavily internationalized, then the phonetic form is needed and the natural forms are less useful and can be dropped. So, I would think that part of the protocol should look at trying to determine the meeting context, choose the appropriate encoding, and drop the other (contextually inappropriate) name representation. I think that the default case for IETF meetings would probably be the phonetic ASCII representation given the constituency, but the protocol should still attempt to deliver on the right context even when we know what the context will be for these particular meetings. I would also suggest that if the meeting context is determined to be mostly local, and the name is determined to use a natural encoding, then any contact (email) data should also be provided in that encoding, since it will be memorable to people who can understand the name context. If the meeting context is mixed-international, then an ASCII representation should be used. Whether or not the ASCII representation is IDNA or a phonetic (pre-IDNA) address is up to the the person who provides that data. Also, the designers should remember that there will be some cases where meetings that prefer natural encodings will still have phonetic contact addresses (pre-IDNA, again). If done correctly, there would only need to be the two identifiers, and they would only need to be provided in a single encoding each, determined by the context of the specific meeting itself. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
RE: i18n name badges
Actually, I think RFID is much more expensive than bar codes, and it's even more expensive the more you use it. With barcode, you pay once for the readers. Printing barcodes on badges doesn't cost anything. RFID tags cost money every time you make a badge, plus the readers are what, 10X the cost of a barcode reader now? RFID tags with storage are currently pretty expensive, and unnecessary, IMO. Just a unique serial number and the registration database is sufficient. I think we can make both optional. Barcode is easily optional, just don't swipe in. I think you can easily lower the range of RFID so that accidental swiping isn't likely. You can also just decline to get the barcode or RFID tag. Brian -Original Message- From: JORDI PALET MARTINEZ [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 4:28 PM To: [EMAIL PROTECTED] Subject: Re: i18n name badges It should be RFID, cheaper, and easier, not only for the blue sheets. The badge could be pre-configured with the data from our own IETF registration. The badge will store the names of the people who we have been talking during the week, and data like when, how much time, We can then use an inexpensive reader to get a small database out of it. Someone can complain about privacy issues, but I feel that is the same now when the blue sheet is circulated, or the attendance list is in the web site, right ? It will save a lot of time (money) to all of us, including the IETF secretariat. Regards, Jordi - Original Message - From: Rosen, Brian [EMAIL PROTECTED] To: 'JORDI PALET MARTINEZ' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 10:14 PM Subject: RE: i18n name badges Let's keep going. I'd contribute, say, $25, plus write some code towards getting a barcode reader (or, maybe RFID??) for each meeting room that would be used to swipe in and automate the blue sheets. Brian -Original Message- From: JORDI PALET MARTINEZ [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 3:08 PM To: [EMAIL PROTECTED] Subject: Re: i18n name badges Keith, I'm not sure if you are joking, but I think is an excellent idea ... A badge communication protocol ... if you start with the draft, I will be happy to contribute ! Regards, Jordi - Original Message - From: Keith Moore [EMAIL PROTECTED] To: Peter Saint-Andre [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 8:12 PM Subject: Re: i18n name badges Proposals for making email addresses fully internationalized were a hot topic in Minneapolis. I'd like to suggest a more modest reform: fully internationalized IETF name badges. IETF 59 might be a fine venue for rolling those out... I'd love to see an Internet-Draft on the topic. For instance, should the badges be able to list multiple versions of a person's name and affiliation? How many versions? That, and it seems appropriate to demonstrate running code. Set up a web form where an attendee can type in his own names and affiliations and have the backend generate a file to be printed out. ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]). ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]).
Re: i18n name badges
On 19-nov-03, at 22:28, JORDI PALET MARTINEZ wrote: It should be RFID, cheaper, and easier, not only for the blue sheets. Wouldn't it be even cheaper if everyone who has a laptop with wireless with them signs in on an electronic version of the blue sheets? This just takes a few hours of fiddling with PHP and saves the secretariat probably 90% of the blue sheet processing.
Re: i18n name badges
Iljitsch van Beijnum wrote: On 19-nov-03, at 22:28, JORDI PALET MARTINEZ wrote: It should be RFID, cheaper, and easier, not only for the blue sheets. Wouldn't it be even cheaper if everyone who has a laptop with wireless with them signs in on an electronic version of the blue sheets? This just takes a few hours of fiddling with PHP and saves the secretariat probably 90% of the blue sheet processing. But would people do it? As it is now, the blue sheet comes around and you sign it; done. If the chair stood up and said, Remember to sign in at ietf.org/bluesheet, people would put it off until it was convenient, and many would forget. If we want to reduce the cost of processing the blue sheets, we could provide each attendee with a sheet of barcode stickers. The bluesheet comes around, you put one of your stickers on it, you pass it on. Then the secretariat needs just one barcode scanner, and can probably get done faster than it takes to do data entry on the current bluesheets. The barcodes would have unique IDs; the secretariat would print up a couple thousand in advance of a meeting and save the unused ones for the next meeting. When someone registered on-site, the registration process would include scanning one of their barcodes, to build the link between barcode and name. A quick search at Amazon shows address labels, 25 sheets of 30, for $10. Give each attendee one sheet; that's 40 cents per person. Less than RFID, we only need one reader, and barcode readers are cheap. Or somebody could hack up software to do barcode recognition on the image of the bluesheet, and then the secretariat can use a flatbed scanner and scan a whole sheet at a time. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |A successful tool is one that was used to do something undreamed| |of by its author. | \/
Re: i18n name badges
There are going to be *at least* three desirable encodings of a person's identity -- the 'natural' encoding in the preferred/native charset of the person's name, some kind of phonetic-ASCII encoding that tells non-natives how to pronounce the name, and the email/idna encoding[s] that folks would use to exchange mail. Folks: it has *not* been decided that there will be a different encoding for email. One such encoding has been proposed; other proposals have been made. This is being actively discussed, and there should be no assumption that the discussion will end with a new encoding. --Paul Hoffman, Director --Internet Mail Consortium
Re: i18n name badges
Peter, PSA Proposals for making email addresses fully internationalized were a hot PSA topic in Minneapolis. I'd like to suggest a more modest reform: fully PSA internationalized IETF name badges. IETF 59 might be a fine venue for PSA rolling those out... I think that enhanced character sets is a perfect topic for having the IETF eat its own dogfood. Just dealing with the details of the name tags might well prove instructive to us, nevermind the basic politeness it offers to attendees. d/ -- Dave Crocker dcrocker-at-brandenburg-dot-com Brandenburg InternetWorking www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253
Re: i18n name badges
--On Wednesday, November 19, 2003 09:03 -0800 Dave Crocker [EMAIL PROTECTED] wrote: Peter, PSA Proposals for making email addresses fully internationalized were a hot PSA topic in Minneapolis. I'd like to suggest a more modest reform: fully PSA internationalized IETF name badges. IETF 59 might be a fine venue for PSA rolling those out... I think that enhanced character sets is a perfect topic for having the IETF eat its own dogfood. Just dealing with the details of the name tags might well prove instructive to us, nevermind the basic politeness it offers to attendees. If we are really going to eat our own dogfood, we should also (or exclusively) print punycode on the badges and then everyone can carry a ToUnicode converter on his or her laptop or PDA :-( john
Re: i18n name badges
There is a better solution. I've seen already IPv6 enabled badges ! We used it in one of the IPv6 Forum conferences ... last June in San Diego. - Original Message - From: John C Klensin [EMAIL PROTECTED] To: Dave Crocker [EMAIL PROTECTED]; Peter Saint-Andre [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 7:07 PM Subject: Re: i18n name badges --On Wednesday, November 19, 2003 09:03 -0800 Dave Crocker [EMAIL PROTECTED] wrote: Peter, PSA Proposals for making email addresses fully internationalized were a hot PSA topic in Minneapolis. I'd like to suggest a more modest reform: fully PSA internationalized IETF name badges. IETF 59 might be a fine venue for PSA rolling those out... I think that enhanced character sets is a perfect topic for having the IETF eat its own dogfood. Just dealing with the details of the name tags might well prove instructive to us, nevermind the basic politeness it offers to attendees. If we are really going to eat our own dogfood, we should also (or exclusively) print punycode on the badges and then everyone can carry a ToUnicode converter on his or her laptop or PDA :-( john ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: i18n name badges
--On Wednesday, November 19, 2003 11:15 -0800 Fred Baker [EMAIL PROTECTED] wrote: At 08:23 AM 11/19/2003, Peter Saint-Andre wrote: Proposals for making email addresses fully internationalized were a hot topic in Minneapolis. I'd like to suggest a more modest reform: fully internationalized IETF name badges. IETF 59 might be a fine venue for rolling those out... No problem, as long as nobody expects anyone in particular to actually be able to *read* the name badges. I don't read Han (simplified or traditional), Korean, Kanji, Cyrillic, Arab (either alphabet) or a variety of other alphabets. I manage with umlauts and such, because I can make a noise and the other person can say yes, that's me, the way you pronounce my name is But I have no clue how to start in a non-ascii-like alphabet, and frankly with tonal languages such as Chinese my western mouth is likely to injure the person's name trying to get it out. Aside: I had a Taiwanese employee once who would periodically give me lessons on how to say her name. It sounded to *me* like I was pronouncing it her way. One can only wonder what she was hearing... Just speaking for myself, one of the things I really like about name badges is being able to determine, upon inspection, what to call the person standing in front of me. BTW, while I understand that many Asians can read each other's writing, I don't think that implies they can read Cyrillic or Arab either. They're in a similar boat, if not the same one. What I would suggest, if we do this, is writing the person's name *twice*: once in their native character set, and once in a form that an english-reader can read. The latter is an established interchange architecture. Fred, this is exactly what I was suggesting, only partially in jest. Native character set, plus punycode, which is much more precise than a transliteration. If we don't like the punycode form, we probably need to think about what we are doing to users in the absence of a serious presentation layer. john
Re: i18n name badges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 JORDI PALET MARTINEZ wrote: | Keith, | | I'm not sure if you are joking, but I think is an excellent idea ... | | A badge communication protocol ... if you start with the draft, I will be happy to contribute ! | bcp? -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/u9QS8Jx8FtbMZncRAu81AJ9E8IxRHf43XOncGDDBwgoMf76QwgCgiKTH w8pdUOOrxFYy2juaXR5YAiM= =CBkj -END PGP SIGNATURE-
Re: i18n name badges (Modified by Iljitsch van Beijnum)
On 19-nov-03, at 18:03, Dave Crocker wrote: I think that enhanced character sets is a perfect topic for having the IETF eat its own dogfood. Just dealing with the details of the name tags might well prove instructive to us, nevermind the basic politeness it offers to attendees. Easy to say for someone with an ASCII-only name... Not butchering the capitalization of my name would be nice, though. van Benum PS. So is this the way to get around spamcontrol ? The instructions aren't very clear.
RE: i18n name badges
Let's keep going. I'd contribute, say, $25, plus write some code towards getting a barcode reader (or, maybe RFID??) for each meeting room that would be used to swipe in and automate the blue sheets. Brian -Original Message- From: JORDI PALET MARTINEZ [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 3:08 PM To: [EMAIL PROTECTED] Subject: Re: i18n name badges Keith, I'm not sure if you are joking, but I think is an excellent idea ... A badge communication protocol ... if you start with the draft, I will be happy to contribute ! Regards, Jordi - Original Message - From: Keith Moore [EMAIL PROTECTED] To: Peter Saint-Andre [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 8:12 PM Subject: Re: i18n name badges Proposals for making email addresses fully internationalized were a hot topic in Minneapolis. I'd like to suggest a more modest reform: fully internationalized IETF name badges. IETF 59 might be a fine venue for rolling those out... I'd love to see an Internet-Draft on the topic. For instance, should the badges be able to list multiple versions of a person's name and affiliation? How many versions? That, and it seems appropriate to demonstrate running code. Set up a web form where an attendee can type in his own names and affiliations and have the backend generate a file to be printed out. ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]).
Re: i18n name badges
It should be RFID, cheaper, and easier, not only for the blue sheets. The badge could be pre-configured with the data from our own IETF registration. The badge will store the names of the people who we have been talking during the week, and data like when, how much time, We can then use an inexpensive reader to get a small database out of it. Someone can complain about privacy issues, but I feel that is the same now when the blue sheet is circulated, or the attendance list is in the web site, right ? It will save a lot of time (money) to all of us, including the IETF secretariat. Regards, Jordi - Original Message - From: Rosen, Brian [EMAIL PROTECTED] To: 'JORDI PALET MARTINEZ' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 10:14 PM Subject: RE: i18n name badges Let's keep going. I'd contribute, say, $25, plus write some code towards getting a barcode reader (or, maybe RFID??) for each meeting room that would be used to swipe in and automate the blue sheets. Brian -Original Message- From: JORDI PALET MARTINEZ [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 3:08 PM To: [EMAIL PROTECTED] Subject: Re: i18n name badges Keith, I'm not sure if you are joking, but I think is an excellent idea ... A badge communication protocol ... if you start with the draft, I will be happy to contribute ! Regards, Jordi - Original Message - From: Keith Moore [EMAIL PROTECTED] To: Peter Saint-Andre [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 8:12 PM Subject: Re: i18n name badges Proposals for making email addresses fully internationalized were a hot topic in Minneapolis. I'd like to suggest a more modest reform: fully internationalized IETF name badges. IETF 59 might be a fine venue for rolling those out... I'd love to see an Internet-Draft on the topic. For instance, should the badges be able to list multiple versions of a person's name and affiliation? How many versions? That, and it seems appropriate to demonstrate running code. Set up a web form where an attendee can type in his own names and affiliations and have the backend generate a file to be printed out. ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]). ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: i18n name badges
If we do this, it should be WE (the IETF engineers) that do it and NOT another thing we request the secretariat to do. We should eat our own dogfood by writing, testing and then GIVING an implementation that is compatible with the current label making system to the secretariat. It's probably not too hard to do, given how the pre-reg badges are produced (I am guessing), but may be much harder for the on-site badges that are made using those little thermal printers. From experience I can tell you that even adding the 3 extra characters we have in Scandinavian can cause all sorts of interesting problems when mixed with different output equipment. Add multi-byte characters and you may see line-printers shutting down and opening their lids indicating paper out or generating spurious form-feeds. OK, so we don't use line printers any more, but you get the idea :-) [If anyone still remembers how to make a line printer attached to an IBM 370 do this by sending just the right sort of code, you get extra points]. The good news is that modern operating systems (ahem) tend to have Unicode and other nice support built-in, but this doesn't necessarily mean that output is a breeze. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj control-L here: On Wed, 19 Nov 2003, John C Klensin wrote: --On Wednesday, November 19, 2003 11:15 -0800 Fred Baker [EMAIL PROTECTED] wrote: At 08:23 AM 11/19/2003, Peter Saint-Andre wrote: Proposals for making email addresses fully internationalized were a hot topic in Minneapolis. I'd like to suggest a more modest reform: fully internationalized IETF name badges. IETF 59 might be a fine venue for rolling those out... No problem, as long as nobody expects anyone in particular to actually be able to *read* the name badges. I don't read Han (simplified or traditional), Korean, Kanji, Cyrillic, Arab (either alphabet) or a variety of other alphabets. I manage with umlauts and such, because I can make a noise and the other person can say yes, that's me, the way you pronounce my name is But I have no clue how to start in a non-ascii-like alphabet, and frankly with tonal languages such as Chinese my western mouth is likely to injure the person's name trying to get it out. Aside: I had a Taiwanese employee once who would periodically give me lessons on how to say her name. It sounded to *me* like I was pronouncing it her way. One can only wonder what she was hearing... Just speaking for myself, one of the things I really like about name badges is being able to determine, upon inspection, what to call the person standing in front of me. BTW, while I understand that many Asians can read each other's writing, I don't think that implies they can read Cyrillic or Arab either. They're in a similar boat, if not the same one. What I would suggest, if we do this, is writing the person's name *twice*: once in their native character set, and once in a form that an english-reader can read. The latter is an established interchange architecture. Fred, this is exactly what I was suggesting, only partially in jest. Native character set, plus punycode, which is much more precise than a transliteration. If we don't like the punycode form, we probably need to think about what we are doing to users in the absence of a serious presentation layer. john
Re: i18n name badges
Someone can complain about privacy issues, but I feel that is the same now whe n the blue sheet is circulated, or the attendance list is in the web site, rig ht ? Count me as one of the complainants. The big problem with RFID is that your identity is exposed at times when you don't want it to be. You can always decline to sign a blue sheet, or you can sign a fake name. As for the attendee list -- I don't recall if the IETF offers the option of not having your name listed; most other conferences I attend do provide that option, and the IETF should as well. --Steve Bellovin, http://www.research.att.com/~smb
Re: i18n name badges
Fred, FB What I would suggest, if we do this, is writing the person's name *twice*: FB once in their native character set, and once in a form that an FB english-reader can read. The latter is an established interchange architecture I believe that was the intention in the proposal. List names in the same way we always have, AND list them in their native form. Whether it would helpful to provide a third form -- the ascii encoding of the native form, as it would be seen in an email address header -- is a separate question. /d -- Dave Crocker dcrocker-at-brandenburg-dot-com Brandenburg InternetWorking www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253
Re: i18n name badges
Proposals for making email addresses fully internationalized were a hot topic in Minneapolis. I'd like to suggest a more modest reform: fully internationalized IETF name badges. IETF 59 might be a fine venue for rolling those out... I'd love to see an Internet-Draft on the topic. For instance, should the badges be able to list multiple versions of a person's name and affiliation? How many versions? That, and it seems appropriate to demonstrate running code. Set up a web form where an attendee can type in his own names and affiliations and have the backend generate a file to be printed out.
Re: i18n name badges
I'm not sure if you are joking, but I think is an excellent idea ... A badge communication protocol ... if you start with the draft, I will be happy to contribute ! I'm working on lots of other things, and somehow I suspect that others are more qualified than I am to get this rolling. The point is that both defining how this should work and writing proof-of-concept code are things that don't need to involve the secretariat. It makes more sense for the secretariat to take this on after we're sure we know what we want and it's been demonstrated to work well, than to impose another vaguely specified burden on a secretariat that is already quite busy. Keith
Re: i18n name badges
On Wed, 19 Nov 2003 14:44:09 PST, Ole J. Jacobsen said: line printers any more, but you get the idea :-) [If anyone still remembers how to make a line printer attached to an IBM 370 do this by sending just the right sort of code, you get extra points]. The IBM 1403 printer (1200 lines per minute, print chain and hammers) could be induced to do that fairly easily by specifying the right CCW (no, you couldn't do with with a Fortran-style column-1-char trick). You would however get extra points for figuring out how to get HASP to put the CCW into the spool file. It was pretty trivial under VM/CMS however http://www.columbia.edu/acis/history/1403.html (1403's could be induced to play music as well). The IBM 3800 (20K lpm laser printer) - now if you managed to get THAT beast to open its lid, that was impressive. http://ukcc.uky.edu/~ukccinfo/ibm3800.html pgp0.pgp Description: PGP signature
Re: i18n name badges
I think having the punycode form have no value on a name badge. Punycode, as it is designed, is meant for machine-to-machine communication. But I like the idea of allowing participation to put their own native names together with their ASCII version on the name badge especially for the next IETF. But... 1. What if the person don't have ASCII only name? (e.g. Patrik Fältström) 2. What if the person have a name which the computer cant be printed? (Maybe it is not in ISO 10646, maybe it is but there is no fonts, maybe the fonts is there but the rendering is wrong?) Since we are on the topic of the name badge, it is possible to somehow tag the family name of the person? (e.g. underline? bold? captialized?) Not everyone follows the Last Name First Name convention. In fact, the concept of First and Last name is quite alien to me. -James Seng Dave Crocker wrote: Fred, FB What I would suggest, if we do this, is writing the person's name *twice*: FB once in their native character set, and once in a form that an FB english-reader can read. The latter is an established interchange architecture I believe that was the intention in the proposal. List names in the same way we always have, AND list them in their native form. Whether it would helpful to provide a third form -- the ascii encoding of the native form, as it would be seen in an email address header -- is a separate question. /d -- Dave Crocker dcrocker-at-brandenburg-dot-com Brandenburg InternetWorking www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253
