W3C home > Mailing lists > Public > public-ietf-w3c@w3.org > January 2012

Re: minutes: W3C/IETF liaison call 2011-11-29

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Wed, 04 Jan 2012 17:10:24 +0900
Message-ID: <4F040970.1020108@it.aoyama.ac.jp>
To: Thomas Roessler <tlr@w3.org>
CC: public-ietf-w3c@w3.org, Richard Ishida <ishida@w3.org>


On 2011/12/23 4:09, Thomas Roessler wrote:
> Below, the minutes from the last liaison all.  Apologies for the lateness.

all -> call ?


> --
> Thomas Roessler, W3C<tlr@w3.org>   (@roessler)


> * IRI/URL discussion
>
> - TPAC discussions:
>
> Discussion with i18n core WG at W3C; Mike Smith volunteered to be
> point at W3C during TPAC. The right people from both sides are
> participating in these discussions, including coordination with i18n
> Core WG and IRI WG chairs. Folks who are involved have good handle on
> what's in scope for parsing document. Discussion between StPeter and
> Hixie - there's strawman text in HTML spec; didn't see strawman as
> complete in any fashion; hopes somebody else will take over. That
> "somebody else" may be Adam. Talk with Mike to figure out what needs
> to go into this document. There's also another URL parsing spec that
> might get folded in. Placeholder text currently in HTML5 spec to be
> pulled into separate document within HTML WG, likely including content
> from http://tools.ietf.org/html/draft-abarth-url-01 and perhaps also
> http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html
>
> - any news from Taipei?
>
> Discussion about getting RFC 3987 (core IRI) and RFC 4395
> (registration) further along and finished up. Always challenge; hope
> to set up call with chair(s), to bang out further issues. Scope
> overlap? Concerns about what an IRI is, and what problem space gets
> addressed where?
>
> Klensin: Should IRI spec make changes to basic URI syntax?

The IRI WG charter currently explicitly excludes this.

> IRI
> appropriate basis to build localization solutions on?

It's unclear what "localization solutions" are, but I see IRIs as 
essentially orthogonal to "localization solutions", or as an enabler. 
But I'm sure there are ways to use IRIs for localization that are bad ideas.

Let's look at an example. Wikipedia decided to have URIs of the form 
http://<language code>.wikipedia.org/wiki/<keyword> for their articles. 
They also decided to use keywords in the respective languages. What IRIs 
make possible is to use an IRI such as
    http://ja.wikipedia.org/wiki/集合論 (1)
(for a keyword of 集合論 (set theory)) in the same way as an URI such as
    http://en.wikipedia.org/wiki/Set_theory (2)
in English, rather than to have to use
    http://ja.wikipedia.org/wiki/%E9%9B%86%E5%90%88%E8%AB%96 (3)

(3) is clearly unreadable for everyone, but (1) is readable for those 
who can read it, and can read the document it points to.

Whether or not it is a good idea to use keywords in URIs/IRIs, and 
whether or not it is a good idea to use non-ASCII keywords, should be 
the choice of Wikipedia and others. This is similar to other choices 
when organizing resources and exposing them as URIs/IRIs.


> Need to look at
> an internationalization model that's different from the "it's a URI
> that has some stuff in it etc etc".

I'm not sure what "has some stuff in it" refers to. If somebody has an 
"internationalization model" for IRIs/URIs, please write it up as an 
Internet draft, so that the IRI WG can have a look at it and decide 
whether to adopt it or not.


> PLH will bring IRI minutes from Taipei to Interaction Domain's
> attention; revisit at next meeting in some more detail.
>
> JCK: The key issue here is whether we can, procedurally, keep the
> various IRI bits marching forward without an in-depth review of where
> it fits with "grown-up i18n"

What's "grown-up i18n"? Any examples of "grown-up i18n"?


> and, if doing that, leaves us in a
> i18n/l10n hole we can't easily get out of. One of the things that
> happened (technically, but symptomatically of the procedural issue) in
> Taipei was a Larry Masinter- Dave Thaler discussion, with me adding
> examples, demonstrating that we really don't understand IRI ->  URI
> domain name translation that would work both unambiguously and
> consistently.

The confusion during the meeting was mostly a result of not everybody 
being on the same page with respect to background reading.

There are indeed problems with IRI->URI domain name translation, but 
they are due to different choices for i18n in different implementations 
at lower levels of the infrastructure (DNS,...). The issues are well 
documented in http://tools.ietf.org/html/rfc6055.


> If we don't have a normative translation / parsing
> definition for something as seemingly-simple as domain names, a
> normative reference from HTML5 to something that uncertain is bad
> news.

For HTML5, there's actually no problem. A browser implementer hopefully 
knows what underlying technology they use for resolving reg-names.


> JCK suggests that one workaround would be to remove the normative
> reference to IRI in the HTML5 spec and retain only the URI one. If we
> do that, then IRI remains (at least normatively) a presentation issue
> as/until things are sorted out and gets it out of the HTML5 critical
> path.

Well, but that would contradict current implementations. HTML5 
implementations resolve IRIs such as
http://ja.wikipedia.org/wiki/集合論 in a@href and other locations, since 
ages (even if Wikipedia itself doesn't use them directly in their source).


Regards,    Martin.
Received on Wednesday, 4 January 2012 08:11:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 4 January 2012 08:11:04 GMT