Minutes for the IRI Working Group, IETF 77
March 10, 2010

Meeting Chair:  Ted Hardie
Working Group Chairs:  Ted Hardie, Marc Blanchet (Incoming)
Area Directors: Alexey Melnikoff, Peter St. Andre (Incoming)

Alexey announced that Marc Blanchet would be joining the group as
co-chair and that a chair from the W3C community is also being sought.
He also noted that the working group will be under Peter St. Andre
within the APPs area division of responsibilities.  The group also
noted that an additional editor for the update to RFC 4395 would be
welcome.

Julian Reshke presented the proposed doc editing mechanics in use
within several other APPs area WG's: using the IETF Tools' team trace
system for issue tracking.  No document edits unless there is a
related issue in the tracker, which has been noted to the list.  See

http://trac.tools.ietf.org/wg/iri/trac/report/1

For the tracker itself. An aside during this period noted that the W3C
has begun a BiDi mailing list, which may be of interest to the group:

http://lists.w3.org/Archives/Public/public-i18n-bidi/

Action Item: Chairs to verify on-list that the working group will use
the tracker to handle a workflow that looks like "Issue opened,
Discussion, Edit, Issue closed".

The group then briefly reviewed the primary changes from RFC 3987 and
the current draft; the chief difference being that IRIs will become
protocol elements, rather than a presentation form which must be
transformed into a URI in order to be a protocol element.

The group then discussed a series of tickets currently within the
tracker.  The full log of discussion is available at:
http://www.ietf.org/jabber/logs/iri/2010-03-26.txt.

Action Item: Pete Resnick and Patrik Fältström to review the current
IDNABIS-related text in the document.

Action Item: Chairs to identify an editor and milestone for the BCP
currently in the charter without a milestone.  This will allow the
current draft to remove language on IRI comparison, which is currently
copy-pasted from RFC 3986.

Among the items discussed is whether the goal of avoiding
scheme-specific parsing; this may be unavoidable in certain
situations, but needs careful additional thought.  For example, if all
authority sections must be punycoded because DNS-derived authorities
will be, is this too big a restriction on new schemes?