Re: [idn] Future of the requirements document

[Erik Nordmark <Erik.Nordmark@eng.sun.com>]

> 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.

It's also believed that the set of solutions that satisfy the requirements
document in its current form is the null set.
If that is indeed the case there should be no suprise that IDNA, just
like any other proposal, can't satisfy all of them.

*If* the requirements document indeed captured the minimum requirements
and there were multiple fully worked out proposals then the document could be
useful as a guide in selecting between the proposals.
But given that the requirement document doesn't appear to (correctly) capture
the minimum requirements it would seem like this approach assumes that the
WG would spend time first on correcting the requirements document then
looking around for additional fully specified proposals.
This would not be fast process.

Thus assuming we all actually want to see an IDN solution soon it seems
to make a lot more sense to drop the requirement document.
The WG last call, IETF last call, and IESG review can then focus on 
more basic questions like:
1. Does the proposed protocol work?
2. Can it be introduced in some incremental fashion?
3. Can it deal with the future?

> 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".

Note that John and the chairs did not suggest a shorter requirements document
but instead a document which describes the problem the WG set out to solve
(and presumably something about the believed constraints for solving the
problem).

If it happens to be that the requirements document, even after resolving
the hotly debated issues you are alluding to, ends up so strict that there
still does not exist a solution, what would we have accomplished?

   Erik