Re: [idn] Future of the requirements document

["Soobok Lee" <[e-mail]>]

----- Original Message -----
From: "Erik Nordmark" <[e-mail]>

> I yet haven't seen an email explaining how the WG would *use* a requirements
> document moving forward given that the document
> hasn't been used as a reference when analysing proposals so far.
> (The requirements in the document have been used but not by actually
> referring to the document.)


Erik,

I would suggest one *usage* of IDN requirement document.

It's well known that the enclosed IDN requirement items are not fully satified by current set of IDNA protocol drafts. It's too
early to drop the requirements document , because we haven't finishef reviewing and assessing future final versions of those drafts,
some of which are still under revision .

If some requirements are turn out to be practically unsatisfiable at last,
those final protocol drafts should clearly describe  what requirements they cannot
satify  based on those requirement document  and  should wait judgements
from IESG  on whether those consequences are neglectable or not.

Writing another new shorter requirements document, intentionally avoiding the following hot-debated yet-unsatisfied requirement
issues, looks poor and is unlikely to succeed. No one would like to go to this path. It is not a "path".

Regards,

Soobok Lee
==========

[11] The protocol should handle with care new revisions of the CCS.
Undefined codepoints should not be allowed unless a new revision of
the protocol can handle it. Protocol revisions should be tagged.


[23] If other canonicalization is done, it MUST be done before the
domain name is resolved. Further, the canonicalization MUST be easily
upgradable as new languages and writing systems are added.

[24] Any conversion (case, ligature folding, punctuation folding, etc)
from what the user enters into a client to what the client asks for
resolution MUST be done identically on any request from any client.


http://www.ietf.org/internet-drafts/draft-ietf-idn-requirements-09.txt



----- Original Message -----
From: "James Seng/Personal" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Wednesday, October 03, 2001 1:56 PM
Subject: [idn] Request to advance "Requirements of Internationalized Domain


> Names"
> Date: Wed, 3 Oct 2001 09:04:35 +0800
> Sender: [e-mail]
> Precedence: bulk
>
> Erik & Thomas,
>
> The chairs of the International Domain Names Working Group, on the
> behalf of the working group, request that the following document be
> published as a Informational RFC:
>
> Title : Requirements of Internationalized Domain Names
> Author(s) : Z. Wenzel, J. Seng
> Filena    me : draft-ietf-idn-requirements-08.txt
> Pages : 8
> Date : 22-Jun-01
>
> A working group last call was conducted on 13th Feb 2001. "-08" on 22th
> Jun 2001 was produced in responsed to the comments made and subsequence
> discussion. The wg agreed in the London IETF meeting to advance this
> document.
>
> James Seng / Marc Blanchet
> IDN Working Group Co-chairs
>
>

----- Original Message -----
From: "John C Klensin" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, December 11, 2001 12:47 AM
Subject: [idn] Future of the requirements document


> As one of the people who (reluctantly) advised the co-chairs to
> drop this, let me clarify my position at least...
>
> * Requirements documents are good.
>
> * Requirements documents that are either seriously
> ambiguous are not so good.
>
> * When there is a requirements document, protocol
> documents that don't satisfy those requirements are
> really, really bad.
>
> Now, our current situation, as I see it, is:
>
> (i) The WG is long overdue for getting results out.  We need to
> finish and wind it down.  Things that block moving forward had
> best be really, really, important.
>
> (ii) If there is a requirements document in the queue that
> doesn't appear consistent with the protocol documents, it is
> unlikely that the latter will move forward before the differences
> are resolved.  That is called "more delay".
>
> (iii) The current requirements draft has some writing problems
> and dangling references, some technical problems, contains some
> requirements statements that the current proposed protocols don't
> satisfy.   And we (the co-chairs, the technical advisors, the
> ADs) don't believe there is real WG consensus around the current
> document (silence or nods from people who haven't read it
> carefully don't count).   Fixing it would take significant time
> and energy.  The experience of the past two years leads us to
> believe that the energy isn't present, even if we were willing to
> invest the time (and delay with WG).
>
> On the other hand, one of the most important values of a
> requirements document is that it provides a foundation for, and a
> record of, a statement about the problem the WG tried to solve.
> Having that seems quite important to us, but we think that
> writing it and getting consensus on it would likely be a much
> quicker process than cleaning up the requirements piece and
> getting consensus on it.
>
> That is, again, subject to discussion.  But I'd hope that those
> who advocate keeping/ fixing the requirements doc explain why it
> is important enough to keep the WG in operation --and hold up the
> protocol documents-- for what I think would be many extra months.
>
>       john
>
>