draft minutes from IETF 83

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've finally had a chance to listen to the audio recording from the
IRI WG session in Paris (posting of the audio was delayed and the
Friday sessions appeared only this week). Please review these draft
minutes so that we can post final minutes before the meeting materials
deadline on April 27 (two days from now). Thanks!

Peter, as co-chair

###

Internationalized Resource Identifiers WG (iri)
Minutes for IETF 83, Paris, France

AGENDA:

11:20-11:25 -- Intro, Agenda Bashing, WG Status
11:25-11:40 -- 3987bis
11:40-11:55 -- Bidi Guidelines
11:55-12:05 -- Test Cases
12:05-12:10 -- IRI Comparison
12:10-12:20 -- Open Mic, Next Steps

DRAMATIS PERSONAE:

DT = Dave Thaler
JK = John Klensin
JR = Julian Reschke
LM = Larry Masinter
MD = Martin Duerst
PR = Pete Resnick (Responsible AD)
PS = Peter Saint-Andre (co-chair)
TD = Ted Hardie
TH = Tony Hansen
TR = Thomas Roessler

MINUTES:

[note: see slides for general content, notes mostly cover discussion]

11:22 Meeting Begins

Administrivia
Jabber Relay: Dave Thaler
Minute Taker: none
No agenda bashing

11:26 3987bis (Martin Duerst)


LM: we had various editor calls and have posted to the list
LM: have people been tracking the posts?
LM: are you OK with our resolutions?
(general head-nodding)

open issues...

#14:
MD: reviews desired to make sure everything has been addressed
LM: involved some rewriting

#47:
PS: people seemed OK with the results of discussion in Quebec City
LM: I think we just ran out of time

#85:
LM: this is a lot of work, would appreciate help
PS: I think this is pretty straightforward

#93:
LM: this is another wording issue, it would be helpful for someone to
    take a fresh look
PS: this might be slightly more significant since it's about the
    normativity of the text

MD: I think these are not big issues

#119, #120, #110 - editorial, not difficult

MD: I would appreciate feedback regarding representation of non-ASCII
    characters in IETF documents
PS: where would you like feedback, rfc-interest?
MD: if about this document specifically, use public-iri, if not then
    use rfc-interest

MD: reviews needed, particularly on Section 5 and Section 7
PS: we did reach out to the i18n-core group at the W3C
MD: yes, but we need more input within the WG too

11:36 Bidi Guidelines (Martin Duerst)

PS: I'd just like to note that Adil Allawi has joined as editor so
    hopefully we will start making good progress

open issues...

#118:
MD: Adil proposed text, no concerns expressed on the list

#116:
MD: Adil proposed text, no concerns expressed on the list

#28:
no discussion

#25: adapt rules for bidi components to those in IDNA2008?
MD: this is serious work, so help is needed here!

#121:
DT: I don't understand one point here: why do we need IRI detection
    logic?  This is a display issue, not how it is stored in memory,
    and it seems that the IRI detection logic would operate on how it
    is stored in memory, not on the display.
MD: This has to happen before it hits the display.
PR: Let me try to answer this in a different way. In a standard right
    to left text editor, the string would appear as shown in Martin's
    first example on slide 9. To the extent that you want it to appear
    differently, you need to detect that it is an IRI before you
    display it, because otherwise it will be presented as it is in a
    standard RTL text editor.
MD: You are almost correct. If you type http:// it appears as we are
    used to, but if you type an RTL character then it gets turned
    around.
PR: As a matter of fact it looks exactly as in your first example on
    slide 9, except that it moves around as you are typing.
DT: Yes.
LM: Petition for a new Unicode character that stands for "http://"?
PS: And there's one for "mailto:" and "ftp:" and so on?
PR: In effect you can do that already, but you still need that special
    logic to determine that this is an IRI.
LM: With respect to requirements, are people thinking about IRIs, or
    some condensed format?
DT, channeling JK from the Jabber room: There are conventions in some
    of the CJK environments for just that. What we need is a pair of
    Unicode characters that mean "start of IRI" and "end of IRI".
TD: Perhaps an example from Chinese is helpful: there are contexts
    where text is displayed up-to-down and right-to-left. We don't
    expect to be able to specify up-to-down in the IRI itself. That's
    a presentation issue. I think there are parts here where we want to
    say what the identifier is, and then say that there might be other
    parts that say how to present that. We might want to do that in a
    standardized way through some kind of marker, but without that I
    think we have to say that your presentation software needs to meet
    your strong preference, end of story.
LM: It would be very helpful to see more examples on these issues.
DT, channeling JK from the Jabber room: The "lets solve the problem by
    not displaying "http://"" at all theory runs smack-on into the
    recent discussions about encouraging more https. But, yes, making
    another layer that does presentation may be the right model, but
    then there is a question as to whether IRIs add or reduce value.
PS: Ted, could ask you a clarifying question? What I heard from you
    was: "we don't have a document about up-to-down issues", so are
    you saying that the bidi issue is purely presentational?
MD: There are certain parallels between vertical and horizontal, but
    there are strong differences also. One is that in vertical, you
    don't mix directions as you do in right to left vs. left to right.
PS: OK.
MD: Please review slides 9 and 10, and post to the mailing list.
MD: Procedurally, we need to decide how normative the text ought to be
    (how many instances of SHOULD/MUST to include).
MD: With regard to examples, the right-to-left text can be difficult to
    show in documents.

12:06 Test Cases (Peter Saint-Andre on behalf of Chris Weber)

PS: We need more input and need to reach out to implementers. There
    might be some overlap with the IRI processing document and work
    happening at the W3C.
LM: I would ask Thomas Roessler about whether to keep that in our
    charter as a WG item.
PS: It is not in our charter now because that work is being done at
    the W3C.
LM: Well, it is in our charter to coodinate.
TR: At the W3C plenary last November, we agreed that the processing
    spec would be done at the W3C. Mike Smith agreed to help with
    editing. It is currently in scope for the rechartering of the
    WebApps WG and is needed for the HTML5 work. That makes the timing
    our problem at the W3C, which I think is a good thing.
LM: There are issues in our tracker on the processing spec. I'm
    reluctant to drop those issues until there's a place for them to go.
TR: I think it would be appropriate to raise that with the WebApps WG
    after the rechartering.

12:10 Comparison Document (Larry Masinter)

LM: We've done a bit of work on this and have closed some issues. My
    thought is that we might be able to review the comparison document
    in concert with the PRECIS WG.
PS: The PRECIS WG is working on things for other protocols, to replace
    stringprep for LDAP and XMPP and so forth. There are similarities
    here, and also to Dave Thaler's document about identifier
    comparison.
DT: The next version of the identifier comparison document could
    reference 3987bis instead of 3987.
LM: Actually I'm looking for a co-editor.
DT: I'd be willing to do that.
LM: This document provides advice regarding what to think about when
    comparing IRIs.
DT: A comparison ladder.
LM: I'm not sure that it's a ladder. There may not be an absolutely
    preferred order for the equivalence elements.
DT: I'd strongly prefer to keep it as a ladder, i.e., to impose some
    order, as RFC 3987 implied.
LM: Actually that came from 3986. So there's a question as to whether
    this document needs to update 3986.
DT: For example, canonicalization is one way to get to equivalence,
    but not the only way.
LM: We'll include you on the editor calls.

12:17 Discussion Time

PS: Tony or someone else, would you like to talk about 4395bis?
LM: I think we had some open issues. The main question is when will be
    ready to last call the documents.
PS: I think we'll need a few more calls among the editors.

JR: I'd like to remind the WG about the web+ prefix for URI schemes.
    There have been change proposals (one of them mine) to remove that
    text, another that takes out the registration of the prefix but
    leaves everything else in the text. I would appreciate some help.
    If we think that defining a prefix for URI schemes is a bad idea,
    we need to make that clear.
TH: There are other registries that have prefixes defined.
JR: Even if we agreed that this is a good idea, this is the right place
    to talk about it, not the HTML WG at the W3C.
TH: Is there a proposal from the liaison for us to add this?
LM: I think this is the IRI WG, not the URI/URL WG.
TR: The operative word is "open issue".
JR: This is the IRI WG, but it is working on the registration document.
MN: I would be concerned if the WG were to lie down on this issue.

PS: Thanks for the feedback, we will have some further editor calls and
    hopefully get these documents into Working Group Last Call before
    the Vancouver meeting.

12:23 Meeting Adjourns

###

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+YVIsACgkQNL8k5A2w/vxa9QCcDhfOsGYk+TquVL03gDWEdEro
sCkAoLLz0Se6tdKiv5F9HXcqjq/OQlFI
=H838
-----END PGP SIGNATURE-----

Received on Wednesday, 25 April 2012 19:47:03 UTC