http://permalink.gmane.org/gmane.ietf.idnabis hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.idnabis/7355 <pre>Greetings again. The websec WG is in WG Last Call for draft-ietf-websec-strict-transport-sec, an interesting document that is likely to be widely deployed in web browsers and servers. There are a few places in the document that touch (slam?) into IDNA 2003 and IDNA 2008, so I thought this list should pay attention now rather than later. In specific, please see section 8 (just the beginning), section 9, and section 13. The WG LC ends April 9. Please send any comments to the websec WG mailing list, not here. Thanks! --Paul Hoffman </pre> Paul Hoffman 2012-03-21T01:09:50 http://permalink.gmane.org/gmane.ietf.idnabis/7354 <pre>https://wiki.mozilla.org/IDN_Display_Algorithm has a few questions. There is a new proposed version of #39; it would be useful to get feedback as to whether it answers the questions you have (if not, we need to propose additional language for the upcoming Unicode meeting). http://www.unicode.org/review/pri209/ ------------------------------ Mark &lt;https://plus.google.com/114199149796022210033&gt; * * *— Il meglio è l’inimico del bene —* ** On Tue, Mar 20, 2012 at 08:46, Gervase Markham &lt;gerv&lt; at &gt;mozilla.org&gt; wrote: _______________________________________________ Idna-update mailing list Idna-update&lt; at &gt;alvestrand.no http://www.alvestrand.no/mailman/listinfo/idna-update </pre> Mark Davis ☕ 2012-03-20T17:06:30 http://permalink.gmane.org/gmane.ietf.idnabis/7353 <pre>Members of this list may be interested to know that the first cut of a patch to implement UTR#39 "Moderately Restrictive" and "Highly Restrictive", as interpreted here: https://wiki.mozilla.org/IDN_Display_Algorithm has been written for Firefox. This algorithm would be used for TLDs which are not on our existing whitelist. You can follow along in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=722299 and can find builds to try out here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smontagu&lt; at &gt;mozilla.com-b7a042eb454e/ Feedback very much welcomed, particularly on what to do about those bits of UTR#36 which our engineer considered too underspecified to implement, as noted in comment #16. Gerv </pre> Gervase Markham 2012-03-20T15:46:11 http://permalink.gmane.org/gmane.ietf.idnabis/7352 <pre> I strongly agree, and would go farther: I think it would be a bad idea for registries to blindly import tables from other registries. But registries are not the only people who may be interested in the variant relationships in a registry. For instance, the anti-abuse community might reasonably want to use those tables as the basis for constructing policies for what domains ought to be expected to be delegated. The anti-abuse community might want to use those tables to detect opportunities for phishing, and to try to produce mitigation strategies. The corollary to using registry policy as the source of sane IDN deployment is that clients need to be able to know what those policies are, and to test actual network behaviour against the policy. In the absence of such tests, the registry policies aren't enough. The only way that applications are going to be able to integrate the expected policies in their applications is if the policies can be expressed in a machine-readable way. If they can't be, then I </pre> Andrew Sullivan 2012-03-14T18:39:38 http://permalink.gmane.org/gmane.ietf.idnabis/7351 <pre>Ram, Agreed. Indeed, we quite deliberately made absolutely no attempt to define a machine-readable format when the idea of these tables was introduced. One reason was that we saw no chance of getting consensus on a format, partially for the reasons Ram identifies. But the more important reason was that we didn't want to encourage anyone to casually import a table without studying it and, indeed, having enough script (and language?) expertise around to be sure that they understood it. I think many of us can remember the degree of upset and concern that arose when one registry decided to allow a script that they didn't understand well because they knew that a language that used the script was used in that country. It is not clear whether importing a table that was equally poorly understood who make that situation worse, but it seems to me it would be very unlikely to make it better. Jaap's recollection is correct and a machine-readable form would be useful in some cases. However, the risk of mindless</pre> John C Klensin 2012-03-14T17:34:50 http://permalink.gmane.org/gmane.ietf.idnabis/7350 <pre>Kim, I am not certain registries would want to use an automated/machine-readable mechanism for importing tables from other registry IDN implementations. Implementations vary widely from one registry to another, each IDN implementation often requires hand-verification of allowed code points combined with business policies. Let’s try an example: CDNC regularly publishes and updates the set of valid codepoints in the Han script, along with contextual and variant generation rules/guidelines. Publishing those set of rules in this rich format would be useful; however, registries will still need to manually verify both the codepoints and the rules for variant generation, and create business rules for allocation and delegation of applied for strings. Feels like a nice to have, not a must have. -Ram --------------------------------------------------------------------------------- Ram Mohan (o) +1.215.706.5700 x103 (m) +1.215.431.0958 (f) +1.215.706.5701 rmohan&lt; at &gt;afilias.info | Skype: gliderpilot30 </pre> Ram Mohan 2012-03-14T14:45:58 http://permalink.gmane.org/gmane.ietf.idnabis/7349 <pre> Noted. jfc </pre> JFC Morfin 2012-03-13T02:07:27 http://permalink.gmane.org/gmane.ietf.idnabis/7348 <pre>I don't see a relationship between the proposed XML behavior and JFC's ideas. Nor am I interested in JFC's ML stuff, sorry. -Shawn -----Original Message----- From: idna-update-bounces&lt; at &gt;alvestrand.no [mailto:idna-update-bounces&lt; at &gt;alvestrand.no] On Behalf Of JFC Morfin Sent: Monday, March 12, 2012 10:31 AM To: Gervase Markham; J-F C. Morfin Cc: Shawn Steele; iutf&lt; at &gt;iutf.org; Kim Davies; idna-update&lt; at &gt;alvestrand.no; James Mitchell; iucg&lt; at &gt;ietf.org; vip&lt; at &gt;icann.org Subject: Re: Draft on IDN Tables in XML At 17:16 12/03/2012, Gervase Markham wrote: Lead users. As you do not want to listen and talk to them, some grassroots people have decided the safest was to reconsider the whole user architecture, back to the IUI and ML-DNS. They probably are not on the same wave lengths as both of you? Don't ask me. My personnal focus here is only the IUI and ML-DNS architectural, documentation and safe testing framework; and to try to keep some liaison with the Internet stratum. This is juste because the "Internet+" stratum is nec</pre> Shawn Steele 2012-03-12T18:28:16 http://permalink.gmane.org/gmane.ietf.idnabis/7347 <pre>IMO IDN can be implemented as it is. There are the problems around multiple variations of names (not just eszett/ss, but also o-umlaut/oe, etc), but I see that as something to be solved on the DNS side. Also I'd like to see DNS handle UTF-8 to lessen some of the challenges around punycode, but that's about it. There are interesting management problems and decisions for zone admins to address, and presumably tools that they want to help, but that's pretty restricted to each zone. For the proposed XML structure, I don't see it being useful on the client side. I'm also uncertain how interesting it is on the registrar side. Either a TLD sells me the name I want, or they don't. Once I have my name, I can manage my zone as I'd like, so these rules only apply to each administrator. The cases when I need to share this information with others seems rare-ish to me, but I'm not someone who deals with this normally. I need to explain to a registrant why I won't register their preferred domain, or the names tha</pre> Shawn Steele 2012-03-12T18:22:15 http://permalink.gmane.org/gmane.ietf.idnabis/7346 <pre> Lead users. As you do not want to listen and talk to them, some grassroots people have decided the safest was to reconsider the whole user architecture, back to the IUI and ML-DNS. They probably are not on the same wave lengths as both of you? Don't ask me. My personnal focus here is only the IUI and ML-DNS architectural, documentation and safe testing framework; and to try to keep some liaison with the Internet stratum. This is juste because the "Internet+" stratum is necessary multiservice menu synergy and access, to multilinguistic support, and to my interest in the Intersem. I therefore only listen to the requests and investigate how the IUI could address them when the project matches my interest. I will know better once my I_Ds are finalized, a PLUS software architecture adopted, and some first prototyping achieved. Then IUI "slots" (smart local operating tasks) from projects will be experimented. Only by then we will know which projects have actually gone through and what they bring. Y</pre> JFC Morfin 2012-03-12T17:30:51 http://permalink.gmane.org/gmane.ietf.idnabis/7345 <pre> Shawn, representing Microsoft, asked this question, which I presume suggests that Microsoft isn't sure what this data is for. I, representing Mozilla, echo his question. Which browser makers have asked for this data? Gerv </pre> Gervase Markham 2012-03-12T16:16:39 http://permalink.gmane.org/gmane.ietf.idnabis/7344 <pre> On 12 mar 2012, at 08:09, Kim Davies wrote: The reason I ask is because on the epp mailing list in IETF there is an ongoing discussion where the registries and registrars completely disagree on how the validation of a string is to happen, and who has the responsibility to implement it. So, this is another stick that someone poked into the ant hill. paf _______________________________________________ Idna-update mailing list Idna-update&lt; at &gt;alvestrand.no http://www.alvestrand.no/mailman/listinfo/idna-update </pre> Patrik Fältström 2012-03-12T14:26:42 http://permalink.gmane.org/gmane.ietf.idnabis/7343 <pre> On Mar 12, 2012, at 7:52 AM, Patrik Fältström wrote: On 12 mar 2012, at 07:22, Kim Davies wrote: The target is really registries Not registrars? I'm not aware of any registrars today that use IDN tables in their business logic. They could use them to filter out known-bad labels before they start an EPP transaction, and to generate variant sets for registries that do not do their own variant handling, so I agree they could be another potential user. kim _______________________________________________ Idna-update mailing list Idna-update&lt; at &gt;alvestrand.no http://www.alvestrand.no/mailman/listinfo/idna-update </pre> Kim Davies 2012-03-12T14:09:49 http://permalink.gmane.org/gmane.ietf.idnabis/7342 <pre> On 12 mar 2012, at 07:22, Kim Davies wrote: Not registrars? paf _______________________________________________ Idna-update mailing list Idna-update&lt; at &gt;alvestrand.no http://www.alvestrand.no/mailman/listinfo/idna-update </pre> Patrik Fältström 2012-03-12T13:52:31 http://permalink.gmane.org/gmane.ietf.idnabis/7341 <pre>Hi Jaap, On Mar 12, 2012, at 3:34 AM, Jaap Akkerhuis wrote: As far as I know, the idea of the tables have always been to provide a public central place where the registries could list which characters they support and which they don't in their registrer plolicies. It is an "for your information only" registry and meant for human consumption. And Kim, do correct me if this isn't the case anymore. It is certainly correct that the notion of tables is to publicly share registry policy as it relates to code points that are accepted for registration. I think, however, it is a bit beyond merely informational, as a key driver in publishing them has been to allow sharing and re-use by other registries. Having a machine readable format that allows the tables to be imported and repurposed aids this greatly. One of the reasons I feel this is a good initiative is an increasing number of tables appear to be published as PDF files with various contextual rules described in paragraphs of normative text. It would be nic</pre> Kim Davies 2012-03-12T13:23:31 http://permalink.gmane.org/gmane.ietf.idnabis/7340 <pre>Hi Shawn, On Mar 11, 2012, at 8:13 PM, Shawn Steele wrote: So, as a 3rd party, I'm not sure how this information is very helpful to me? I mean, it'd tell me what the registry hoped to do for it's zone, but that may or may not match the DNS entries. I can discover valid domains by querying the DNS itself, I don't need to access the list. I can see how this information might be helpful for tools that help people manage their zones, however any tools that talked to themselves wouldn't necessarily need this format (though it'd help to be able to import/export the data this way, and maybe interoperate better with other tools). I guess what I'm getting at is: What kinds of applications are expected to consume this data? What's the target? The target is really registries, albeit potentially registries at multiple levels of the DNS — not just TLD registries. While other software like end-user applications consume the data, I am not sure what the benefit would be. Once it is in a DNS zone, it is a domain n</pre> Kim Davies 2012-03-12T13:22:17 http://permalink.gmane.org/gmane.ietf.idnabis/7339 <pre> Is it possible to add the relation type for each variant like is it exactly similar or partially? Also, what about the registry rules? Some registries impose more restriction on the IDNA protocol is it possible to add a tag the describe them? As far as I know, the idea of the tables have always been to provide a public central place where the registries could list which characters they support and which they don't in their registrer plolicies. It is an "for your information only" registry and meant for human consumption. And Kim, do correct me if this isn't the case anymore. jaap </pre> Jaap Akkerhuis 2012-03-12T09:34:03 http://permalink.gmane.org/gmane.ietf.idnabis/7338 <pre>Hello, Is it possible to add the relation type for each variant like is it exactly similar or partially? Also, what about the registry rules? Some registries impose more restriction on the IDNA protocol is it possible to add a tag the describe them? AbdulRahman, -----Original Message----- From: idna-update-bounces&lt; at &gt;alvestrand.no [mailto:idna-update-bounces&lt; at &gt;alvestrand.no] On Behalf Of Dillon, Chris Sent: 5/Mar/2012 3:23 PM To: Kim Davies; vip&lt; at &gt;icann.org; idna-update&lt; at &gt;alvestrand.no Subject: RE: Draft on IDN Tables in XML Dear colleagues, I have been reading this correspondence with Chinese in mind and would like to raise some questions. This is a case where there are two major forms of a script (Simplified Chinese used, for example in mainland China and Singapore) and Traditional Chinese, used elsewhere. Many characters are the same everywhere but a subset of characters have been abbreviated in the case of Simplified Chinese. There is an additional complication in the form of a small number of characters </pre> Abdulrahman I. ALGhadir 2012-03-12T06:30:20 http://permalink.gmane.org/gmane.ietf.idnabis/7337 <pre> Shawn, The browsers want to use them. To validate the IDNs. This is why we need to get them synced. jfc </pre> J-F C. Morfin 2012-03-12T03:07:06 http://permalink.gmane.org/gmane.ietf.idnabis/7336 <pre> That's I guess what I was getting at. Eventually someone's going to change their mind on what's appropriate. They can then grandfather in existing ones or figure out how to deprecate them, but, at that time, it seems the actual DNS entries won't match the file here. Additionally there could be errors. Presumably the DNS records are authoratative, however if they don't match it could confuse consumers. So, as a 3rd party, I'm not sure how this information is very helpful to me? I mean, it'd tell me what the registry hoped to do for it's zone, but that may or may not match the DNS entries. I can discover valid domains by querying the DNS itself, I don't need to access the list. I can see how this information might be helpful for tools that help people manage their zones, however any tools that talked to themselves wouldn't necessarily need this format (though it'd help to be able to import/export the data this way, and maybe interoperate better with other tools). I guess what I'm getting at is: What </pre> Shawn Steele 2012-03-12T02:13:10 http://permalink.gmane.org/gmane.ietf.idnabis/7335 <pre> Dear Shawn, the need for synchronized multilinguistic (on languages) and polylinguistic (same data in different language) is a general need that can only be currently addressed in an opendata context by a registry or DDDS international system, or by an extended DDDS mutually operated architecture. It would be interesting to know what Microsoft, Google, and others would have to propose. I would be interested in working on a joint exploratory draft on this issue which is universal and not limited to the Internet. This could be part of the JTC1/SG32/WG2 effort, or a totally separate project. It should permit contributions by everyone to be kept synchronized within a registrant defined TTL and to be freely accessed for validity check of table versions and updates. Best jfc </pre> JFC Morfin 2012-03-11T02:29:33 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.idnabis