http://blog.gmane.org/gmane.org.w3c.public-iri hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.org.w3c.public-iri/2122 <pre>As we discussed in Atlanta, despite the Herculean efforts of the document editors (with kudos and appreciation to Martin Dürst and Larry Masinter especially), the IRI work has not had sufficient energy and participation from enough of the relevant interested parties and therefore has not been progressing in the IETF in a way that is likely to produce documents and come to consensus. After consultation with the rest of the IESG and the IAB, I am shutting down the working group. As reflected in the Atlanta meeting minutes, although there are some risks associated with stopping the work (in particular, that we might end up with forked efforts that need to be reconciled in the future), it is clear that more progress will be made by encouraging and contributing to the other work that is underway rather than continuing the IRI WG as it stands. I thank you all for your participation and efforts. You should see the shutdown notice shortly. We will leave the mailing list open for any future discussion</pre> Pete Resnick 2013-01-18T18:16:29 http://comments.gmane.org/gmane.org.w3c.public-iri/2121 <pre>As we discussed in Atlanta, despite the Herculean efforts of the document editors (with kudos and appreciation to Martin Dürst and Larry Masinter especially), the IRI work has not had sufficient energy and participation from enough of the relevant interested parties and therefore has not been progressing in the IETF in a way that is likely to produce documents and come to consensus. After consultation with the rest of the IESG and the IAB, I am shutting down the working group. As reflected in the Atlanta meeting minutes, although there are some risks associated with stopping the work (in particular, that we might end up with forked efforts that need to be reconciled in the future), it is clear that more progress will be made by encouraging and contributing to the other work that is underway rather than continuing the IRI WG as it stands. I thank you all for your participation and efforts. You should see the shutdown notice shortly. We will leave the mailing list open for any future discussion</pre> Pete Resnick 2013-01-18T19:41:56 http://comments.gmane.org/gmane.org.w3c.public-iri/2113 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris and I have finally generated meeting minutes for the IRI WG session in Atlanta. My apologies for having personally caused such a significant delay in posting them. Your comments and corrections are welcome. Peter ### Internationalized Resource Identifiers WG (iri) Minutes for IETF 85, Atlanta Date: Tuesday, November 6, 2012 Time: 17:00-18:30 Eastern Standard Time / 22:00-23:30 UTC Place: Hilton Atlanta, Room 209 AGENDA: 1. 17:00-17:05 Intro (chairs) 2. 17:05-17:15 URI/IRI/URL thread among IETF/W3C/WHATWG (Larry Masinter) 3. 17:15-17:30 Future direction (chairs / AD) 4. 17:30-17:50 Core IRI Definition (Larry Masinter, Martin Duerst) https://datatracker.ietf.org/doc/draft-ietf-iri-3987bis/ 5. 17:50-18:05 Bidirectional Guidelines (Martin Duerst) https://datatracker.ietf.org/doc/draft-ietf-iri-bidi-guidelines/ 6. 18:05-18:15 IRI Comparison (Larry Masinter) https://datatracker.ietf.org/doc/draft-ietf-iri-comparison/ 7. 18:15-18:25 URI/IRI Re</pre> Peter Saint-Andre 2013-01-02T20:29:47 http://comments.gmane.org/gmane.org.w3c.public-iri/2109 <pre>Like others, I'd like to express my personal view of the future of internationalized identifiers. At the start of internationalization, it was very clear that content had to come first. Fortunately, today, it's easy to write a Web page or an email in almost any languages one wishes. Identifiers were a next area of concern. In some contexts, e.g. file names, users now take them for granted. On any OS, it would be a big hassle if a user had to cook up a romanized or translated name for a document just because the OS was ASCII-only. I can say that from my own experience; working in Japan, I get lots of job-related documents with non-ASCII names, and create some myself. This lets me feel the need for internationalized identifiers every day. In the IETF, there has also been a lot of work. Internationalized Domain Names have come a long way since I put out the first proposal in 1996. Email Address Internationalization (EAI) went through an experimental phase and is now very close to completing Propo</pre> Martin J. Dürst 2012-11-12T11:14:32 http://comments.gmane.org/gmane.org.w3c.public-iri/2108 <pre>Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team&lt; at &gt;meetecho.com. Cheers, the Meetecho team </pre> Meetecho IETF support 2012-11-09T17:07:23 http://comments.gmane.org/gmane.org.w3c.public-iri/2106 <pre>During the last week and this, there were a number of discussions about the various efforts around the IRI specification and conflicts (or potential conflicts, or relationships) between the IETF RFCs 3986, 3987, 4395, and IETF IRI wg drafts for 3987bis, comparison, registration, bidi, the W3C HTML working group documents which currently refer to them, http://url.spec.whatwg.org in WHATWG, and the planned W3C WebApps working group URL spec which is planned to produce a stable copy of the WHATWG spec.dd I thought I'd would state my personal opinions, for the record, not as an official statement from anyone (Adobe, W3C, IETF, ...), but just in case I might have been misquoted (or misspoke):e Background: * I have been disappointed by the lack of participation, energy, document reviews in the IETF IRI working group; a working group which doesn't have significant active participation and document review should be shut (rather than trying to maintain the illusion of progress) * there are significant parts </pre> Larry Masinter 2012-11-09T01:49:02 http://comments.gmane.org/gmane.org.w3c.public-iri/2098 <pre>I listened to the audio recording of the meeting and I feel my emails have been largely misunderstood. I thought I would try again. As far as the interests of the IETF seem to go, this is what http://url.spec.whatwg.org/ attempts to do: * Define the string syntax for URLs (IRI-references, if you wish). * Define parsing the string syntax into a model (IRI-references -&gt; URI, if you wish). * Define serializing the model back into a string syntax. The string syntax seems non-controversial. The parsing seems controversial, but the plan is to add an option there to only parse conforming string syntax and bail on the first error. (Going past the first error is useful for e.g. browsers / search engines / wget so they can interoperate with content, but also for URL validators that want to highlight more than one error in the URL.) The model is currently only documented as a function of the parsing algorithm. My plan was to align implementations on parsing first before documenting what model that implied. I al</pre> Anne van Kesteren 2012-11-07T21:51:46 http://comments.gmane.org/gmane.org.w3c.public-iri/2095 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Based on discussion with our Area Director, I have updated the agenda so that we cover the "URL" topic and future path topic first. It would not surprise me if those discussions run over the allotted time, so be prepared for the possibility that we will not get to some of the later agenda items. Agenda bashing on the list or in real time this evening is of course welcome. http://www.ietf.org/proceedings/85/agenda/agenda-85-iri Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCZTeIACgkQNL8k5A2w/vy4awCfXHp5HS+fbKFdPSXRW1qhnksR 4rgAn2n1om/th6ouVvZLx+x0noeHhAx+ =huJe -----END PGP SIGNATURE----- </pre> Peter Saint-Andre 2012-11-06T17:50:26 http://comments.gmane.org/gmane.org.w3c.public-iri/2087 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've uploaded an updated agenda, including more detailed logistics and such. https://datatracker.ietf.org/meeting/85/agenda/iri/ Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCQQ2UACgkQNL8k5A2w/vz5sACfWlKNsufOHNTK83cYTEeYqRni W8sAnAtBuOtPxvQPBTRvtsRnVgrO7hIt =W97F -----END PGP SIGNATURE----- </pre> Peter Saint-Andre 2012-10-30T21:15:17 http://comments.gmane.org/gmane.org.w3c.public-iri/2086 <pre>Here is a proposed (rough) agenda for the IRI WG session (Tuesday, November 6) at IETF 85. Please bash the agenda on the list so that we can upload the final agenda by the deadline next Monday. Note: all times are local (Eastern Standard Time). ### 17:00-17:05 Intro, Logistics, Agenda Bashing (chairs) 17:05-17:25 draft-ietf-iri-3987bis (Larry Masinter, Martin Duerst) 17:25-17:40 draft-ietf-iri-bidi-guidelines (Martin Duerst) 17:40-17:50 draft-ietf-iri-comparison (Larry Masinter) 17:50-18:00 draft-ietf-iri-4395bis-irireg (Larry Masinter) 18:00-18:05 recent bulk registration experience (Dave Thaler) 18:05-18:15 URI/IRI/URL discussion with IETF/W3C/WHATWG (Larry Masinter) 18:15-18:30 Future direction of IRI WG (chairs) ### Peter </pre> Peter Saint-Andre 2012-10-24T22:26:10 http://comments.gmane.org/gmane.org.w3c.public-iri/2085 <pre>Dave and IANA followed the documented process. I apologize that http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg-04 expired June 16, should have been updated last IETF meeting. I think we might want to change the IANA recommendations to make the registry more useful and easier to navigate. Please suggest updates to the 4395bis in the tracker if they're not already there, and we can discuss/update the document at the IETF meeting. </pre> Larry Masinter 2012-10-24T20:30:56 http://comments.gmane.org/gmane.org.w3c.public-iri/2069 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There's been quite a bit of IRI-related activity of late. If you have definite ideas about a topic or document you would like to discuss during the IRI WG session at IETF 85 (preferably focused on the kind of open issues that require WG interaction to move forward), please post to this list in the next few days so that Chris Weber and I can generate a draft agenda. Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCEqpYACgkQNL8k5A2w/vxclwCgosxu1CYeFHoGQqdNhszAzDG/ es8An3TJaWI9Mb/jzJzadEHvdZSlzWsy =+47t -----END PGP SIGNATURE----- </pre> Peter Saint-Andre 2012-10-22T02:08:22 http://comments.gmane.org/gmane.org.w3c.public-iri/2062 <pre>For "test the web forward" I want to start gathering/generating reftests. I *think* the test framework is based on the Mozilla framework https://developer.mozilla.org/en-US/docs/Creating_reftest-based_unit_tests The tests I'm starting with are http://web.lookout.net/2012/03/unicode-normalization-in-urls.html http://lists.w3.org/Archives/Public/public-html/2010Feb/0255.html generated from http://greenbytes.de/tech/webdav/urldecomp.xml https://bugzilla.mozilla.org/show_bug.cgi?id=479520 and http://annevankesteren.nl/2012/09/idna There are also some BIDI examples in http://tools.ietf.org/html/draft-ietf-iri-bidi-guidelines once we get that far. Anyone know of any other existing IRI/URI/URL/LEIRI tests? For tests that push DNS we might need some other test framework (including an DNS server which will accept requests &lt;anything&gt;.site.com where anything is an arbitrary string, and send request with Host header) so that I can test the IDNA conversion bits. </pre> Larry Masinter 2012-10-20T08:08:45 http://comments.gmane.org/gmane.org.w3c.public-iri/2054 <pre>#133: What to do about query part in URI-&gt;IRI mapping Draft -12 does not mention the special case of the query part in URI-&gt;IRI mapping. I have put in some text (to appear in new draft) that optionally allows percent-escaping to remain in the query part for http:/https:. Do we need more details for this optionality? Should this be mandatory? I personally don't want it to be mandatory because in the future, when (almost) everything is UTF-8, unescaping will just be fine. </pre> iri issue tracker 2012-10-20T04:59:34 http://comments.gmane.org/gmane.org.w3c.public-iri/2050 <pre>#132: Allow non-spacing marks at end of components This is split out from http://trac.tools.ietf.org/wg/iri/trac/ticket/25. As well documented at http://tools.ietf.org/html/rfc5893#section-4.1 (Dhivehi) and http://tools.ietf.org/html/rfc5893#section-4.2 (Yiddish), this is useful in practice. Also, it's benign because non-spacing marks just behave in unison with their base characters in the bidi algorithm. So this is a non-brainer. </pre> iri issue tracker 2012-10-16T07:19:34 http://comments.gmane.org/gmane.org.w3c.public-iri/2047 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am assuming that we will want to hold a meeting or the IRI WG at IETF 85 in Atlanta. I shall request a meeting slot of 90 minutes before the deadline today. As co-chair I would like to find out which of our document editors will be able to attend in person or remotely during the week of November 4th. Also please post to the list with topics to be discussed or issues to be solved at the meeting. It would be great if we could use the upcoming meeting as motivation for making significant progress on our specifications. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBOHNIACgkQNL8k5A2w/vxaOQCg5g8Jl3EXHFfQNMMoj62iqU/3 THQAoMSljzVqgcGf69FF2zGY8Z8bqToA =x3s8 -----END PGP SIGNATURE----- </pre> Peter Saint-Andre 2012-09-10T17:01:06 http://comments.gmane.org/gmane.org.w3c.public-iri/2045 <pre>Hello IETF IRI WG, I'm writing on behalf of the W3C Internationalization Working Group. I was tasked [1] with letting you know that the WG recently [2] reviewed the SRI draft [3] proposal. The working group felt that: (1) we think this is an idea in search of a problem. SRI addresses the problem of encoding parts by putting the URI into an XML format. But this format is not consistent with existing markup or interaction practices. It doesn't fix the problem of presenting international characters on the "side of the bus/written on napkin" and it doesn't deal with address bars. (2) we don't know what this solves that IRI does not solve (3) we continue to support IRI and wish it were done: we believe that, although there are a few nettlesome problems such as with bidi, it is possible to complete this work and move forward Regards, Addison [1] http://www.w3.org/International/track/actions/140 [2] http://www.w3.org/2012/07/18-i18n-minutes.html [3] http://tools.ietf.org/html/draft-klensin-ir</pre> Phillips, Addison 2012-07-31T22:18:49 http://comments.gmane.org/gmane.org.w3c.public-iri/2043 <pre>IRIs are widely deployed and referenced; RFC 3987 is referenced by 42 RFCs http://www.arkko.com/tools/allstats/citations-rfc3987.html and many W3C specs: https://www.google.com/search?q=3987+rfc+site%3Awww.w3.org%2FTR at least some of which use IRIs or something like them as protocol elements. The problem is that we have at least 3 different classes RFC 3987-compatible &lt; LEIRI compatible (used in XML) &lt; browser-compatible (used in HTML and other browser implementations). HTML5 allows use of document character set for query parameters, and a wide variety of characters not valid in LEIRI, but of course allows RFC 3987 compatible. LEIRI allows RFC 3987 but also spaces. The question is whether any of the protocols that allow IRIs really need to maintain RFC 3987 compatibility, or would want to be compatible with browsers. I think "web applications" (i.e., things built with the HTML javascript-engine) want to be compatible with browsers. </pre> Larry Masinter 2012-07-30T18:05:45 http://comments.gmane.org/gmane.org.w3c.public-iri/2039 <pre>Folks, because neither Chris nor I can travel to Vancouver for IETF 84 and we have been unable to figure out how to run an in-person meeting without the chairs present, I have reluctantly concluded that we will need to cancel our scheduled session for the IRI WG at IETF 84. However, that doesn't mean we can't make further progress toward completing our deliverables (e.g., I know that Larry and Martin will meet virtually tomorrow to work through open issues on 3987bis). In particular, if working group participants who will be in Vancouver wish to meet informally to discuss topics related to IRIs, I would certainly not discourage them! Peter, as chair </pre> Peter Saint-Andre 2012-07-23T20:01:52 http://comments.gmane.org/gmane.org.w3c.public-iri/2035 <pre>#131: Using document charset causes interoperability problems As reported by Dave Thaler... URIs and/or IRIs can appear in many contexts. In normal text in an email message, or in a PDF file or Word doc or whatever else. Allowing it to vary complicates frameworks considerably since now the doc charset has to be passed from whatever extracts the URI from the document (HTML or otherwise) and whatever else needs to know the interpretation (normalizer code, comparison code, whatever). Various API frameworks already have various sorts of "Uri" classes that take in a URI-like string and let you do things like get the URI form or the IRI form, or various components or whatever. This means the constructor needs to change since you cannot correctly interpret an IRI(bis) without knowing the document charset. I'm not yet convinced that's a change worth making. Currently everything assumes UTF-8. With this change, we'll get random behavior until everything is updated, which is a state worse </pre> iri issue tracker 2012-07-19T22:04:09 http://comments.gmane.org/gmane.org.w3c.public-iri/2028 <pre>Dear IRI WG, Just before the Internet Draft final submission cut-off, I have submitted a new version of draft-ietf-iri-3987bis-12.txt. The main change this time is that there are now versions with non-ASCII characters. This is very helpful for examples, and also quite nice for peoples' names. I don't have non-ASCII equivalents for everybody's name, in particular in the Acknowledgements section, so please send me any you know. There are not many other changes. The most notable ones are that I removed the mention of "Draft Standard" (because that just doesn't exist anymore), and that there is a change in wording removing the word "origin" (issue #128). Peter, we may be able to close issue #128 (it's your choice both as the person who raised it and as a chair). But we need some new issue(s?) to cover the questions that Dave brought up re. query parts. The 'pure' US-ASCII text version is at http://tools.ietf.org/id/draft-ietf-iri-3987bis-12.txt, the HTMLized US-ASCII version at http://tools.ietf.o</pre> Martin J. Dürst 2012-07-17T10:54:17 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.org.w3c.public-iri