Re: IRI minutes from IETF 85

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:
> -----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 Friday, 4 January 2013 06:01:06 UTC