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 discussions. pr </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 discussions. pr </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 Registration (Larry Masinter) https://datatracker.ietf.org/doc/draft-ietf-iri-4395bis-irireg/ 8. 18:25-18:30 Recent Bulk Registration Experience (Dave Thaler) MINUTES: 1. Chair intro (Peter Saint-Andre) 2. URI/IRI/URL thread among IETF/W3C/WHATWG (Larry Masinter) + 3. Future direction (chairs / AD) Larry Masinter: - - summarizing a 20 year journey - - we now have a working group that isn't doing much work, especially from implementing community - - background of various groups working on URL across IETF, W3C, and WHATWG - we see much divergence Philippe Le Hegaret (W3C) - - Section 2.6 of HTML5 talks about URLs and work is continuing there Larry Masinter: - - proposal to combine RFC3986 with 3987 - - 20 years after the term URI was created, the term URL is still dominating and in widespread use Leslie Daigle: - - where would that leave documentation in the rest of the world, such as HTML5 work? Larry Masinter: - - we would have a spec that could easily be referenced from other documents Dave Thaler: - - Windows recently implemented some of the rules from 3987 Martin Duerst (in the jabber room): - - Larry's plan is to start lots of work, but let's think of a way to get there with less work Larry Masinter: - - I think the problem is a lack of workers, and I'm not willing to continue work on the separate spec John Klensin: - - merging this stuff would leave us with the worst aspects - - sounds like we are considering shutting down the IRI WG if no one will do the work Ted Hardie: - - talking about interfaces - - URI were protocol elements, IRIs were presentational elements - - but that didn't work because people wanted IRIs in protocol - - WHATWG seems to be doing something else - - we don't have versions so we ought to change the name - - problem is that we don't have clarity of the APIs Julian Reschke (in the jabber room): - - would we be in a better place if 3987 was written as an extension of 3986? Roy Fielding: - - the answer to that is no and I have no intention to change 3986 - - what the WHATWG is doing is a good thing but irrelevent for the goals of 3987 - - the APIs and goals of general URI or IRI interfaces are different from those of Web browser implementers - - I've always considered IRIs to be a display framework Pete Resnick (Area Director): - - what I heard from Larry is that WG does not have energy to produce the spec Ted mentioned, which will lead to WHATWG doing IRI work - - are folks here OK with that bifurcation? Roy Fielding: - - regardless of what IRI WG decides, that work will happen in WHATWG anyway, we can't control that - - Roy disagrees with WHATWG's approach that 5 protocol implementations will dictate what the rest of the Internet should do Dave Crocker: - - from what I'm hearing here, this WG seems to be done Martin Duerst (in the jabber room): = only thing the WHATWG has criticized of 3987 is that browsers use a variant of relative resolution Larry: - - I walked in thinking that there was not critical mass, so closing down the WG makes sense; the only other option is to recharter to do the work (perhaps slightly different work) in a different way Jeff Hodges: - - maybe if they (WHATWG) used a different name for URLs it wouldn't be so confusing Larry Masinter: - - the problem is that everyone calls it URL, whereas URI/IRI is a very specific syntax definition Julian Reschke (in the jabber room): - - zero chance of getting people to use another term Joe Hildebrand: - - I agree with Larry that it's appropriate to shut down the WG, although that's disappointing Larry Masinter: - - the WG has some work items that still need to get done, such as updating the registration procedures Ted Hardie: - - the name doesn't really matter, but the rules do matter - - if WHATWG changes the rules, then we need to update 3986 to provide a pointer to a new URL definition - - I'm concerned that people used "URL" to mean 3986 Larry Masinter: - - there's a fuzzy mention of "URL" and there are contexts where the syntax is restricted (e.g., space-delimited list of URLs) Ted Hardie: - - I think we agree that in the contexts we're dealing with, if you don't have a way to communicate that context then writing a spec defining handling of URLs in the HTML context as if it applies to all contexts will be problematic Larry Masinter: - - what's been changing my thinking is the registered protocol handler discussion at WHATWG Ted Hardie: - - how do you know if there's a registered protocol handler? Larry Masinter: - - you don't Ted Hardie: - - so instead of erroring as in 3986 processing, something is done to "fix it", but you don't know whether the ultimate context actually wants that processing Martin Duerst: - - Being compatible with the Web is a good idea. But if you follow URI/IRI specs, you are 99.9% compatible with the Web (probably more). Browsers are a very specific kind of application, they have a very high pressure on (bugwards) compatibility. If I write e.g. a Web spider, I don't have to care about non-valid URIs/IRIs, I can just take the valid ones and will be fine. John Klensin: - - that WG is looking at things only in a web context - - the problem is that if the receiver has a different context, things in between can mess things up - - either IRI is really a presentation layer on top of URIs, or it is a protocol "thing" on its own - - I don't know where that leads, other than to deprecating 3987 Peter Saint-Andre: - - which would certainly involve closing this WG John Klensin: - - and I would happily work on an Internet-Draft to do that Roy Fielding: - - error-handling is the sore point for WHATWG, who wants clear error-handling steps - - there's a fundamental disconnect here Joe Hildebrand: - - if WHATWG would define URL handling in the context of HTML browsers alone, that would be fine - - but I don't think that can happen, so we either need to reinvigorate this work or let someone else define the syntax Larry Masinter: - - I am going to channel for the WHATWG... - you have an erroneous definition of what is really error handling - everyone wants to be compatible with how the browsers handle things - there aren't any examples of applications that don't want to be compatible with browsers (Atom or anyone else) Roy Fielding: - - Apache doesn't care what the browser thinks Larry Masinter: - - HTTP servers do not speak URLs in the same way as browsers, they speak a restricted syntax of URIs Roy Fielding: - - it's not possible to be incompatible with something that accepts all strings - - that doesn't mean that, say, a virus checker is not relevant for Internet standards Larry Masinter: - - I think the argument is that we need one place to define things - - if there's a need for a restricted syntax that is widely supported, define it in the core spec - - if there is restricted syntax but not as universal, that can be elsewere Ted O'Connor (in the jabber room): - - Processing URLs already depends on the scheme. We just want to write that down somewhere referenceable. Ted Hardie: - - apparently there's a strong preference in the WHATWG to put everything in one spec; I think there's a stylistic difference here - - more critically, the difference in rules and the handling of protocol elements is markedly different in their spec and ours Roy Fielding: - - the notion that processing depends on scheme is not quite correct - - the 'file' scheme is an outlier here - - but just because 'file' is bizarre doesn't make the rest of URI space scheme-specific Ted Hardie: - - Roy is right Julian Reschke (in the jabber room): - - if we were able to fix 'file' we'd be in a much better position Larry Masinter: - - there's no point in continuing to do this work if there is no one willing to implement it Andrew Sullivan: - - I hear everyone saying that this is really important but no one will implement it or nobody cares - - if we believe that, we shouldn't do the work Larry Masinter: - - there are implementers, but they aren't in the room Roy Fielding: - - I think there's willingness to do real work here, but I don't think it would be accepted by the WHATWG Andrew Sullivan: - - if people don't want to invest the time and energy, then that tells me that people don't care about the work Philippe Le Hegaret (W3C): - - my goal is that these "willful violations" will either be retained and justified, or cleared up, based on testing Pete Resnick (Area Director): - - some history of the past several weeks of discussion among all the relevant parties... - - today I'm hearing that the WHATWG effort is not actually making IRIs into protocol elements - they are doing processing, not pre-processing, in the web context - - I'm coming to the conclusion that we can continue to chat with the WHATWG about how they want to interact with the IETF, but that might not be relevant to how we do our work here - - If WHATWG "forks", that might be OK for the contexts they are addressing (naming issues aside) Mark Nottingham: - - if I need to normatively reference this WHATWG construct in an IETF document, how do I do that? Pete Resnick: - - we do have ways of doing that, and I'm not worried about that case yet Pete Resnick: - - I'm not hearing a lot of energy to do work on the IRI work that this WG was chartered to do - - I'm looking for a reason to *not* close down this WG, but cannot find one - - asking for people to explain why this WG should not be shut down Larry Masinter: - - we have a registry of schemes, and Mark Nottingham: - - might move 4395bis to APPSAWG for registration work to continue Dave Thaler: - - I'd recommend closing the WG and moving the registration work elsewhere (AD-sponsored or another WG) John Klensin: - - if registration work didn't have IRI baggage, it might happen more quickly Martin Duerst: - - RFC 3987 was done in as an individual submission. That might work for RFC 3987bis, too. Ted Hardie: - - there are reasons why we might want to deprecate 3987, because it's not actually what people needed John Klensin: - - agreed and I'd be willing to work on that Larry Masinter: - - there are something like 40 normative references to 3987 Julian Reschke: - - I still think we should replace 3987 with something that is much simpler, by simply extending the valid URI characters Pete Resnick: - - in either case, I don't think this WG would do that John Klensin: - - simply extending the valid URI characters involves significant internationalization problems Ted Hardie: - - one reason there was a registration document here, is we thought every registration request would need to say whether it wanted to do ASCII-only or internationalized protocol elements - - then 3987bis or 4395bis would need to describe how to do that - - simply shutting down the WG leaves too much dangling state Pete Resnick: - - I don't know that the work you just described fits the charter as written - - do we recharter or charter something new? procedurally it doesn't make a difference John Klensin: - - sometimes some breathing space is valuable - - chartering or rechartering would require energy Peter Saint-Andre: - - there's an assumption there that a WG would be needed - - but going through the process would help us figure that out John Klensin: - - defining a hybrid of a hybrid is looking for trouble Larry Masinter: - - some of the work might be usefully salvaged (comparison, bidi) - - I'm willing to help with that Pete Resnick: - - the salvage issue doesn't necessarily mean a WG is the right approach - - I'm going to take this as input and will wait until after we talk with IAB and IESG on Friday about how to proceed - - my current inclination is that we shut down and figure out how to deal with the work that needs to be salvaged, then go through a fresh thinking-process for chartering new work if people feel that is needed Peter Saint-Andre: - - and part of that is the registration work (4395bis) Pete Resnick: - - that could plausibly be done elsewhere or folded into new work [Items 4-7 not covered for lack of time] 8. Recent Bulk Registration Experience (Dave Thaler) - - 4395 experiment looked at protocol registrations - - bulk registered 76 schemes - - the process worked surprisingly well END ### -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDkmLsACgkQNL8k5A2w/vwVwgCgtPZ9yT393MrZoX1IJVsCOv4i uDoAoPXvf9wh6y4vL5qHxOK1Bmyr6W55 =qXts -----END PGP SIGNATURE----- </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 Proposed Standards. Other technologies such as XMPP use non-ASCII identifiers, too. With stringprep and precis, the IETF has also done a lot of work in the area of equivalence of internationalized identifiers. For URIs and IDNs, internationalization is available via ACE (ASCII-compatible encoding). This addresses low-level backwards-compatibility issues (e.g. HTTP 1.1). But the user obviously wants to see räksmörgås, and is annoyed by xn--rksmrgs-5wao1o or r%C3%A4ksm%C3%B6rg%C3%A5s. EAI and XMPP take this a step further, they just use UTF-8. For EAI, this is amazing because for the longest time, there was only the mantra "email will always stay 7-bit". So things move, even if not at a very fast pace. And my prediction is that they will continue to move. Users prefer to see what they can read. Implementers prefer UTF-8 rather than a charset zoo. If a new protocol or format (in the IETF or elsewhere) is UTF-8 only, there is not much of a point to transfer URIs or IDNs in ACE form. But neither are these just presentation elements, or just something that needs pre-processing. Based on this background: * I support closing the IETF IRI WG. Most of the work on IRIs (from ca. 1995 to 2009) was done without a WG. A WG is not a precondition for work to get done, and not a way to make work magically faster. * Some time after RFC 3987 was published, I started to update it (http://tools.ietf.org/html/draft-duerst-iri-bis-00) to take into account errata and feedback from implementers. I plan to continue this work. * I will continue to support Anne in his work on the WHATWG URL spec. In particular, documenting browser bugwards-compatibility and getting the browsers to align their implementations in this area is very important, and very hard. * There are other implementations than browsers and other technologies than HTML and its surroundings. Browsers have very peculiar market pressures on bugwards compatibility that fortunately don't apply in the same way to other implementations. Also, other implementations are processing URIs/IRIs/URLs in other ways than browsers. I plan to work to make sure these needs are covered, too, in whatever form that may take. * I hope that we can find a good way to proceed with RFC 4395bis (registration), and am willing to contribute. There is a lot of good stuff in there registration-wise and internationalization-wise. Of the four WG specs, it is the one with the most open issues, but probably the one which can be moved forward most quickly. Regards, Martin. </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 of the Internet infrastructure (including most of HTTP protocol-based servers proxies gateways) which use RFC 3986 as is, and do not want or need IRIs or a broader definition * most of the implementors of browsers are interested in following and giving feedback on http://url.spec.whatwg.org . Given this background: * I support closing IETF IRI working group and discontinuing work on its documents. If for some reason it remains open, or others wish to continue work in IETF on these specs as independent submissions, please remove me as editor. * I support encouraging Anne van Kesteren to continue working on http://url.spec.whatwg.org * I support the plan that the WebApps working group will produce a derivative work which is a stable edition suitable for reference by a stable document such as the W3C HTML standard (having stable documentation for critical system interfaces is necessary for many procurement contracts). * I encourage Anne and others to continue to work on the URL spec, testing and test cases, and considering including more of the useful work done in the current IRI working group documents. * If and when a stable URL document is produced (via WebApps WG) I will encourage an IETF RFC to "close off" the IRI standards track by obsoleting RFC 3987 with a reference to the W3C stable URL specification (if feasibile). * While liaison between IETF and W3C is good, I wish others had taken a more proactive approach to resolving the apparent organizational conflicts, including the WHATWG perspective. There are a few other issues caught between the organizations (the "willful violations"), and I hope that a calmer more principled approach can be taken. Questions? Comments? Larry -- http://larry.masinter.net </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 already indicated how this model is incompatible with URI. E.g. a query with a lone "%" can be the output of the parser, but is definitely not an URI. (This is why "fixup" is the wrong way to look at this algorithm I think.) Serializing seems non-controversial. (I am not sure if it is worth mentioning, but I am doing this work largely by myself and thus far unpaid. Although browser vendors have indicated they appreciate what I am doing, I am not representing any of them, and I definitely care about software other than browsers. My experience is that what browsers do leaks throughout the ecosystem and I rather have it documented and confined what is leaked than everyone having to reverse engineer each other in a race to the bottom.) </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-iri-sri-00 Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N WG) Internationalization is not a feature. It is an architecture. </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 than today in my view. Example: http://www.sw.it.aoyama.ac.jp/non-existent?é If the charset were iso-8859-1 then under RFC 3987 as I understand it, this would become: http://www.sw.it.aoyama.ac.jp/non-existent?%C3%83%C2%A9 In other words, you have to convert iso-8859-1 to UTF-8 and then pct- encode the UTF-8. But as I understand 3987bis it would become: http://www.sw.it.aoyama.ac.jp/non-existent?%C3%A9 which would then be passed around via various APIs and protocols that would not pass the charset along with it. As such it would be interpreted by the receiving code as pct-encoded UTF-8: http://www.sw.it.aoyama.ac.jp/non-existent?é which of course it isn't. As such, we should make the RFC 3987 behavior (UTF-8, NOT the doc charset) required for everything that doesn't explicitly pass the charset along with the URI. </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.org/html/draft-ietf-iri-3987bis-12. But you should look at one of the versions that contain Unicode, either the text version at http://www.sw.it.aoyama.ac.jp/2012/pub/draft-ietf-iri-3987bis-12.utf8.txt, the HTML version at http://www.sw.it.aoyama.ac.jp/2012/pub/draft-ietf-iri-3987bis-12.html, or the PDF version at http://tools.ietf.org/pdf/draft-ietf-iri-3987bis-12.pdf. A diff for the US-ASCII version can be found at http://tools.ietf.org/rfcdiff?url2=draft-ietf-iri-3987bis-12.txt. A diff for the UTF-8 version can be found at http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-iri-3987bis-11.txt&amp;url2=http://www.sw.it.aoyama.ac.jp/2012/pub/draft-ietf-iri-3987bis-12.utf8.txt. (you may have to tell your browser that you want the result to be interpreted as UTF-8). A diff between the US-ASCII and the UTF-8 version of draft -12 can be found at http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-iri-3987bis-11.txt&amp;url2=http://www.sw.it.aoyama.ac.jp/2012/pub/draft-ietf-iri-3987bis-12.utf8.txt. -------- Original Message -------- Subject: I-D Action: draft-ietf-iri-3987bis-12.txt Resent-Date: Mon, 16 Jul 2012 12:37:54 +0000 Resent-From: public-iri&lt; at &gt;w3.org Date: Mon, 16 Jul 2012 05:36:37 -0700 From: internet-drafts&lt; at &gt;ietf.org To: i-d-announce&lt; at &gt;ietf.org CC: public-iri&lt; at &gt;w3.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Resource Identifiers Working Group of the IETF. Title : Internationalized Resource Identifiers (IRIs) Author(s) : Martin J. Duerst Michel Suignard Larry Masinter Filename : draft-ietf-iri-3987bis-12.txt Pages : 40 Date : 2012-07-16 Abstract: This document defines the Internationalized Resource Identifier (IRI) protocol element, as an extension of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). Grammar and processing rules are given for IRIs and related syntactic forms. Defining IRI as a new protocol element (rather than updating or extending the definition of URI) allows independent orderly transitions: protocols and languages that use URIs must explicitly choose to allow IRIs. Guidelines are provided for the use and deployment of IRIs and related protocol elements when revising protocols, formats, and software components that currently deal only with URIs. This document is part of a set of documents intended to replace RFC 3987. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-iri-3987bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-iri-3987bis-12 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-iri-3987bis-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </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