Subject: [idn] new list of wg documents and next steps

From: Marc Blanchet <[email-masked]>
Date: Thu, 19 Jul 2001 12:03:07 -0400

Hi,
	As stated previously, July 14th was the deadline for showing core of 
interest for wg documents. The wg web page (http://www.i-d-n.net#docpool) 
now contains the list of documents that showed core of interest (7 people 
supporting). The IETF secretariat has been requested to change the status 
of the other documents to be non-wg documents, so they will not be shown on 
the IETF idn wg web page 
(http://www.ietf.org/html.charters/idn-charter.html).  But the wg web page 
(http://www.i-d-n.net) will keep track of all documents related to idn. Any 
new document that shows core of interest will be added to the list of the 
wg documents.

This process is to help reaching concensus, there is no implicit judgement 
on the value of the documents.

The list of wg documents is now:
  draft-ietf-idn-requirements-08.txt
  draft-ietf-idn-idna-02.txt
  draft-ietf-idn-nameprep-03.txt
  draft-ietf-idn-dude-02.txt
  draft-ietf-idn-aceid-02.txt
  draft-ietf-idn-jpchar-01.txt
  draft-ietf-idn-ace-eval-jp-00.txt
  draft-ietf-idn-mace-01.txt
  draft-ietf-idn-uname-01.txt
  draft-ietf-idn-tsconv-00.txt
  draft-ietf-idn-udns-02.txt
  draft-costello-idn-amc-ace-z-00.txt

Note that the focus of this process is for documents that would be 
eventually pushed as standard track documents (i.e. protocol 
documents).  Informational documents do not need to be in that list for now 
to be considered (for example, the requirements documents will be subject 
to a final wg last call).

We can try, with some approximation, to categorize the wg documents in the 
following categories:

a) Matching
  draft-ietf-idn-nameprep-03.txt
  draft-ietf-idn-jpchar-01.txt
  draft-ietf-idn-tsconv-00.txt

b) Encoding
  draft-ietf-idn-dude-02.txt
  draft-ietf-idn-mace-01.txt
  draft-costello-idn-amc-ace-z-00.txt

c) Protocol
  draft-ietf-idn-idna-02.txt
  draft-ietf-idn-uname-01.txt
  draft-ietf-idn-udns-02.txt

d) Informational (no action to be taken for now)
  draft-ietf-idn-aceid-02.txt
  draft-ietf-idn-ace-eval-jp-00.txt

e) Informational (going to RFC informational)
  draft-ietf-idn-requirements-08.txt

The authors of documents in each category (as well as authors of the other 
documents not listed here) should discuss about converging to one document 
or to agree on one proposal.  Deadline is August 3th with a document that 
would be discussed during the idn wg meeting in London.  Marc Blanchet is 
happy to provide a majordomo specific mailing list to help the groups reach 
concensus, just drop me an email.

We hope to have wg concensus on the main topics during the London meeting.

James & Marc.

PS. I haven't updated the i-d-n web page with all the  internet-drafts sent 
recently. Should be done by tomorrow.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 19 Jul 2001 13:29:55 -0400

Marc,

draft-ietf-idn-requirements-08.txt, statement of scope, contains this:

	It is recommended that solutions not necessarily be within
	the DNS itself, but could be a layer interjected between the
	application and the DNS.

While this may be the most popular point of view, it isn't appropriate
to place a recommendation prior to completion of requirements gathering.

I've mentioned this before, but the editors haven't made any change or
comment.

I'd like to know if there is working group consensus on the inclusion of
any recommendation in a working group requirements draft. It seems novel
to me.

Eric

---

From: David Hopwood <[email-masked]>
Date: Thu, 19 Jul 2001 23:07:04 +0100

-----BEGIN PGP SIGNED MESSAGE-----

> to place a recommendation prior to completion of requirements gathering.

I agree entirely. The following would be reasonable:

          Part of the solution may be to interject a layer between the
          application and the DNS, either in addition to or instead of
          making changes to DNS protocols.

but AFAICS, there is no concensus for the statement as currently written.
It is also ambiguous, since it depends on whether resolvers are considered
to be "within the DNS itself". The choice of whether part of the resolver
functionality is in-process or implemented by the OS, say, is an
implementation detail, not a fundamental part of *any* of the proposals.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip