IRI minutes from IETF 85

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

Received on Wednesday, 2 January 2013 20:30:17 UTC