gmane.org.w3c.public-iri

IRI working group shutdown

Pete Resnick — 2013-01-18T18:16:29

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

IRI working group shutdown

Pete Resnick — 2013-01-18T19:41:56

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

RE: fate of IRI working group in IETF

JFC Morfin — 2013-01-07T14:29:13

This is a very interesting statement when I confront it to my 
personal field current experience.

The IETF' switch from the better internet to the more market 
palatable internet (Aug 29th) might actually correspond to this. Like 
a change wehad before from ITU to IETF. This time it is from 
internationalization to multilingualization (as a general metaphore 
in many disciplines). It might not mean many new SDOs but a possible 
switch from internationalizing (Unicode, IETF, etc.) to 
multilingualizing entities, actually from localization to subsidiarity.

I personnally locate the change at RFC 5895. The innetwork is stable, 
reliable, etc. the outnetwork is adaptative, at least on a community 
basis. Languages are good examples of existing communities. 
Technologies may also be (ipads, linux, etc). Architures may also be. 
I experiment the concept with the small IUse community slow emergence 
(Intelligent Use system extensions).

jfc

RE: fate of IRI working group in IETF

Larry Masinter — 2013-01-06T18:44:47

John and SM:

The question and your interests presume the lack of interest is in the topic. But this 
is not the case. Rather, There is a lack of interest in working within the IETF
process. 

There ARE people willing to work, in a standards working group, on IRIs and related items.
We have the WHATWG spec:

        http://url.spec.whatwg.org/

If you search http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/ for "URL standard"
And you'll find hundreds of emails about the URL spec.

We have 
                 http://dvcs.w3.org/hg/url/raw-file/default/Overview.html

and searching the mail archive:
http://www.w3.org/Search/Mail/Public/search? hdr-1-name=subject&hdr-1-query=url&type-index=public-webapps
again with hundreds of emails about the URL spec there.

And we have 
             http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#urls
and related bug reports and discussion about that.

I think some people might have a plan for converging these, but I can't find any written description
of the plan.

In summary: your reasoning is interesting, but does not apply to the
current situation.

Larry
--
http://larry.masinter.net

Re: fate of IRI working group in IETF

John C Klensin — 2013-01-06T14:24:55


--On Thursday, January 03, 2013 22:17 -0800 SM <sm< at >resistor.net>
wrote:


There are at least two other hypotheses:

(1) Even though there is general agreement that
internationalization is very important, reasonable people can
disagree about what should be internationalized (or localized)
and how.  Several regularly-repeated discussions are of pieces
of that issue.   For example:

 * What constitutes a "protocol identifier" that should
not be internationalized.  

 * Although it is rarely discussed, it is often been
observed that, when "meaning" is not important, basic
Latin characters are understood by most of the world's
population and can be rendered by most of the world's
devices.  They are, so far, required by most things that
are clearly protocol identifiers (such as URI scheme
names) so that inability to render them is a problem
regardless of what is done about i18n globally.  From
that perspective, allowing other character sets globally
tends to fractionalize the Internet, not unify and
internationalize it.

 * Some activities are inherently local and a matter of
localization, not subjects for i18n.  For example
keyboard mappings are inherently local -- no one serious
has proposed an "internationalized keyboard" with enough
keys and shifts to be able to represent all of Unicode
(or even all abstract letters and digits in Unicode)
without escape conventions.

 * There is often a useful distinction between a thing,
the name by which the thing is called, and mechanisms
that may lead to the thing.  The distinction recently
drawn in the "new URL standard" thread between URL
processing and strings that may lead to URLs is a useful
part of that discussion, but so are the "to map or not"
discussions about strings that could be construed as
IDNs and the issues surrounding whether end users really
use domain names or are (or should be) using search
engines and other "above DNS" or "non-DNS" approaches.

Those are just examples and each involves tradeoffs but, if
someone examines even one of them and concludes that IRIs are
the wrong solution to the problem (or a solution to the wrong
problem), then they can conclude that IRIs are not particularly
important even if i18n is.

(2) As soon as the IRI WG started down the path of saying "these
are protocol identifiers, mostly important for protocols that
have not yet been defined in URL terms" (note that, while I hope
that is a reasonable characterization of a position, I am not
claiming that it is a consensus one or that it represents the
consensus of the active participants in the WG or of the
community), then the importance of IRIs becomes related to
guesses about protocols not yet designed, not the Internet (or,
especially the Web and URLs) as we know it today.

Those three  reasons -- the two above and the issues of time,
personal or business priority among the experts, and "pain
points" that SM and Martin identifies-- are largely independent
of each other but probably have an additive effect in reducing
the number of people who are enthused about IRIs and willing to
spend major energy on them.

best,
    john

Re: fate of IRI working group in IETF

Martin J. Dürst — 2013-01-04T07:44:52

Yes. And because it's important for everybody, everybody can think that 
somebody else will do it, so they don't have to do it. Also, it's 
important to everybody, but except for boundary cases (error processing, 
i18n, bidi) it "just works" and isn't a "major pain point".

Regards,   Martin.

Re: fate of IRI working group in IETF

SM — 2013-01-04T06:17:10

Hi Jiankang,
At 18:35 03-01-2013, Jiankang YAO wrote:

It is difficult to find people with the relevant expertise.  The 
people can be busy.  Saying that the work is important does not change that.

Regards,
-sm

Re: IRI minutes from IETF 85

Martin J. Dürst — 2013-01-04T06:00:16

Hello Peter,

Many thanks for getting these minutes out.

Here are a few nits:

- Towards the very end, there is some text saying "[Items 4-7 not 
covered for lack of time]". I think it would be easier for people not at 
the meeting to put this text immediately after the AGENDA, tweaking it 
e.g. to read as follows: [The actual meeting focused on agenda items 2 
and 3 (discussed together). Items 4-7 were not covered for lack of time.]

- - The bullet items come with two hyphens each (see start of this item 
for an example). That may be an artifact of some conversion. It would 
look better if it were fixed.

Regards,    Martin.

On 2013/01/03 5:29, Peter Saint-Andre wrote:

Re: fate of IRI working group in IETF

Jiankang YAO — 2013-01-04T02:35:43

----- Original Message ----- 
From: "SM" <sm< at >resistor.net>
To: "Larry Masinter" <masinter< at >adobe.com>
Cc: <public-iri< at >w3.org>
Sent: Tuesday, November 13, 2012 6:03 PM
Subject: Re: fate of IRI working group in IETF

it is an important work, but why  do few people paritcipate in this WG?

is it due to that the importance of this work is not recognized by every involved person?

Jiankang Yao
>

IRI minutes from IETF 85

Peter Saint-Andre — 2013-01-02T20:29:47

-----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-----

Re: Future of Internationalized Identifiers

Peter Saint-Andre — 2012-11-13T16:15:48

Hi Martin,

On 11/12/12 4:14 AM, "Martin J. Dürst" wrote:

That all seems reasonable.


Sadly, I concur with you and Larry here.


True. As you know, I've put a lot of work into reaching for a successful
conclusion to the IRI WG (not as much as you and Larry, for sure), and
I'm disappointed that we were not able to to involve more participants
and contributors. As SM notes in his reply to Larry, that seems to be
the way of the world with regard to internationalization (and even
something as fundamental as URIs).


I'm happy to hear it.


Indeed.


Great.


Agreed. One possibility is spinning up a small WG in the IETF
Applications Area dedicated to simplifying and modernizing registration
requirements for a variety of technologies (URIs/IRIs, link relations,
etc.). I think it would be good to work on these updates in a
semi-coordinated fashion.

Peter

Re: fate of IRI working group in IETF

SM — 2012-11-13T10:03:32

Hi Larry,
At 17:49 08-11-2012, Larry Masinter wrote:

Working Groups discussing about internationalization tend to suffer 
from lack of participation.  I listened to the arguments about the 
importance of doing the work.  It doesn't change the fact that there 
isn't any energy to do the work.

Regards,
-sm

Lone % in query parts (was: Re: Clarifying the URL Standard goals)

Martin J. Dürst — 2012-11-13T09:13:46

I don't think http://www.w3.org/?% is a good example, because that page 
doesn't accept query parts at all. A better example would be a page that 
actually depends on a query part.

I just tested with http://www.google.com/?q=% and 
http://www.google.com/?q=%25.

On Opera, I get the same result (a page with "%" in the search box), but 
the difference in the address field stays. When requesting the actual 
search, the difference (% vs. %25) stays if I keep Javascript on. It 
disappears when I switch it off.

On Safari, an input of http://www.google.com/?q=% gets turned into 
http://www.google.com/?q=%25. As confirmed with Wireshark, the query 
leaves the browser as GET /?q=%25 HTTP/1.1. That means that Safari does 
convert the % to a %25.

Chrome behaves more like Opera. I didn't find a way to switch off 
JavaScript (maybe I didn't look long enough), but that part isn't at the 
core of what we are testing here.

Firefox is the same as Opera. IE also seems to be the same or similar.



Did you mean the above tests, or something else?

I'd definitely also like to see some tests on the server side. For 
example, what happens in Apache when it receives "%" vs. "%25"? What 
about other servers, frameworks, and so on.

Regards,   Martin.

Future of Internationalized Identifiers

Martin J. Dürst — 2012-11-12T11:14:32

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.

Meetecho session recording

Meetecho IETF support — 2012-11-09T17:07:23

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< at >meetecho.com.

Cheers,
the Meetecho team

Re: update on URL testing and the W3C's test framework

Julian Reschke — 2012-11-10T11:04:08

 > ...

And we need to be very careful with that. We know for a fact that Webkit 
differs a lot from Firefox and IE, and in some cases FF and IE are more 
conforming than Webkit and apparently get away with that (fragment 
identifier in data URI comes to mind).

Best regards, Julian

fate of IRI working group in IETF

Larry Masinter — 2012-11-09T01:49:02

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

Re: Clarifying the URL Standard goals

Anne van Kesteren — 2012-11-08T11:52:14

On Thu, Nov 8, 2012 at 11:11 AM, "Martin J. Dürst"
<duerst< at >it.aoyama.ac.jp> wrote:

Yeah, coincidence. In fact, I started work in the month before leaving
Opera after hearing about yet another bug report in the URL layer and
realising we did not come far with URLs since 2008.



I do not think it is procedural, but it does not use ABNF:
http://url.spec.whatwg.org/#writing It uses a style we have been using
in WHATWG/W3C land to define how to write things. For
parsing/processing we then use a procedural definition.



I think our main problem will be the concept of "relative schemes" the
URL Standard has. Only if the base URL has such a scheme a relative
reference can be resolved successfully. I'm not really sure how to
bring that any closer to what STD 66 expects to happen. E.g.

base: customscheme://test
input: ?test

results in failure rather than customscheme://test/?test.



I thought that is the way Roy described what is defined in STD 66.



They are not preserved.



You got it right.

I replaced the "invalid flag" with a "fatal error flag" and plan to
introduce the concept of errors. Fatal errors are hopeless (e.g. input
does not have a scheme and there's no base either), errors are about
not matching the string syntax.



Servers appear to not pay much attention to it. http://www.w3.org/?%
is an example. Escaping it to %25 seems dangerous compatibility wise.



Well, we can write the latter in documents encoded as either utf-8 or
utf-16 (but please don't encode your documents as utf-16), because we
know the www.google.com endpoint speaks utf-8. It will still be parsed
into percent-encoded bytes which is somewhat useless and wasteful, but
not a huge problem if we provide API surface to get utf-8 out of it
again.

Whether we want to improve that situation even more is kinda tricky.
On the one hand yes, because it would obviously be cleaner to just
transmit utf-8 rather than the ugly percent-encoded bytes, but on the
other hand a lot of existing infrastructure would have to change. So
much so that it is not entirely clear to me the ROI is worth it.

Meeting materials (was: Re: updated IRI agenda)

Martin J. Dürst — 2012-11-08T10:39:33

That's what happened. It's a bit sad, because although not overly 
impressive, there was actually some progress.

Also, the agenda did not include a link to the meeting materials at
https://datatracker.ietf.org/meeting/85/materials.html#wg-iri
(I'm not blaming Peter, because there are way more links in the Agenda 
than what I'd be able to collect.)

Of the four slide links, I think the Introduction slides and the "Recent 
Bulk Registration Experience" slides 
(http://www.ietf.org/proceedings/85/slides/slides-85-iri-8.pdf) were shown.

I hope that everybody interested can have a quick look at the slides on 
the main draft (draft-ietf-iri-3987bis, 
http://www.ietf.org/proceedings/85/slides/slides-85-iri-6.pdf, 8 pages) 
and the slides on the bidi draft 
(http://www.ietf.org/proceedings/85/slides/slides-85-iri-7.pdf).

Regards,    Martin.

Re: Clarifying the URL Standard goals

Martin J. Dürst — 2012-11-08T10:11:58

Hello Anne,

Many thanks for your email.

[somewhat reordered]

 > (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,

Not only is it worth mentioning, I suspect it may also show a 
symptomatic problem in the area of URI/IRI/URLs: Everybody (including of 
course the browser vendors) thinks it's important, but nobody feels it's 
important enough to spend valuable employee time. Or is it pure 
coincidence that you have time for this work now that you are not 
employed? (Sorry if I'm reading too much into the situation.)

I would also want to take this occasion to thank you again for your 
work. This is something I wish had been happening two or three years 
ago, but we can't change that anymore.

 > 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.)

Even if it's only for the browsers, documenting and confining makes a 
lot of sense.

On 2012/11/08 6:51, Anne van Kesteren wrote:

My understanding is that this is a "procedural" definition, i.e. one 
finds out whether something is an URL by running through a certain 
number of steps (written in pseudocode in the spec).

I think this is something good to have. But some people want a more 
top-down description, for which the syntax in RFC 3986/3987/3987bis 
should be more suited.

So it would be good to do the following:
- Make sure that URL syntax and IRI-reference syntax are aligned.
   (we started working on that)
- Verify that both descriptions are indeed the same
   (this is somewhat more formal than "make sure", but doesn't
    have to be done for every small change)
- Make it explicit that these two are the same by cross-references

If you say "model", it looks more like "URI pieces" than just "URI".
Also, if this is about the DOM, and you say "URI", does this mean that 
when accessing URL parts in the DOM, these (e.g. the path part) are all 
%-escaped? Or are Unicode characters preserved in the DOM? (the later 
would be much better for many usages)

Yes, we just have to agree on some details, and on what descriptions of 
the syntax we provide (and where).

You talk about errors here. Are these strict validity errors? My 
impression was that at least in an earlier version of your spec, there 
was a distinction between "not valid" and something I might call here 
"absolutely hopeless". The former might include spaces and e.g. "\". I'm 
not sure about the later, but maybe something like "www......com" would 
be an example.

Do you still have this (essentially three-level) distinction, or did I 
get that wrong?

What do you mean by "a query with a lone "%" can be the output of the 
parser"? Does that mean that it is sent as such to the server? What do 
servers do with it? Would it hurt to escape it to %25? Or is that done 
in a later stage?

One thing I'm worried is the dependency of the query part on the 
document encoding. In the (very) long term, the Web seems to converge on 
using UTF-8. You are a very vocal proponent of that direction, and I of 
course fully agree. But if we stay with the current spec, we may end up 
that we will have to write http://www.google.com?q=%E6%97%A5%E6%9C%AC 
forever rather than the much more readable (for those who care) 
http://www.google.com?q=日本.

Regards,    Martin.

Re: Marginal codepoints in IRIs/URLs

Anne van Kesteren — 2012-11-08T08:44:54

On Thu, Nov 8, 2012 at 5:16 AM, "Martin J. Dürst"
<duerst< at >it.aoyama.ac.jp> wrote:

No worries!



My current view is that it mostly makes sense to restrict certain code
points in the ASCII range as those are used as delimiters throughout
the ecosystem. HTML/Python use quotation marks, HTTP uses the colon
and whitespace, etc. So by putting the restrictions there, you make it
easy to copy and paste a URL around.



So LEIRIs are an even larger superset of IRIs. "\" seems problematic
as passing that to a URL parser results in it being handled as if it
were a "/". (I suppose we could make the parser handle that via a
flag, or before handing it to the parser you replace "\" with "%5C".)

U+0009, U+000A, and U+000D are pretty much always dropped on the floor
by a URL parser so those would be problematic too.

I am surprised [ and ] are not allowed. mailto:a< at >b?subject=[test]%20
is something I semi-frequently write and where I keep forgetting I
need to escape [ and ] to make it valid (I never had it fail anything
but the validator though).



What would be interesting is affected code points, and expected
results. There's a few cases currently where the URL parser has a hard
fail. E.g. if you resolve "/test" against "about:blank". We could
expand that to include these code points I suppose, but it seems like
a major risk.