Remove reference to 4690 from charter

[Mark Davis]

My problem with 4690 is that parts of it are either misleading or incorrect,
and that the rationale is already much better as a statement of the issues.
There has been substantial progress in terms of understanding of the issues,
on all sides, since 4690 appeared.

Your wording seems to imply that what RFC4690 identifies as problems are all
really problems, which I disagree with. I could live with it if your wording
was more along the lines that RFC4690 was an earlier attempt at identifying
the problems, and some of the material there may be relevant to the charter.

But this all opens up controversies that I think we've moved past, so it is
far better to just delete the reference to 4690.

Mark

On Tue, Mar 18, 2008 at 11:23 AM, Lisa Dusseault <ldusseault at commerce.net>
wrote:

>
> I don't think there will be any problem informatively referencing
> RFC4690 in the documents, and expect people to read it.   It
> definitely informs the work of the WG even if the WG doesn't adopt
> every goal wholesale.
>
> If people are still split over this issue, we can try putting it back
> in the charter and wordsmithing the reference there:
>
> "RFC4690 informs this work, although the WG is not expected to solve
> all the problems and address all of the issues that RFC4690 identifies."
>
> Stephane?
>
> Lisa
>
> On Mar 17, 2008, at 5:35 PM, John C Klensin wrote:
>
> >
> >
> > --On Monday, 17 March, 2008 13:13 -0700 Paul Hoffman
> > <phoffman at imc.org> wrote:
> >
> >> Lisa said:
> >>
> >>> Here are the TODOs on the charter from the meeting:
> >>>  - Consensus to remove reference to 4690 from charter
> >>
> >> I agree with this move. RFC 4690 did many things at once, and
> >> it is not clear that we intend to do every one of those things
> >> in this WG.
> >
> > I have no objection to removing the 4690 reference from the
> > charter. However, no charter draft that I have seen says "solve
> > all of the problems and address all of the issues that 4690
> > identified" and I'm a little concerned about this level of
> > micro-tuning of the charter (whether by removing things or
> > specifying additional ones).
> >
> > Especially because IDNA is a client-side protocol in which it is
> > difficult to test for conformance on the wire, it is, IMO,
> > important that the output of this effort identify _why_ things
> > are being done and, in essence, why people should conform to the
> > standard.   To the extent to which 4690 provides that rationale
> > for some of the provisions, it is probably better to have
> > informative references to it than to need to replicate all of
> > the text.  I hope that remains an acceptable option and that we
> > can avoid a model in which people are expected to do things just
> > because the IETF says so.  The latter has not worked well with
> > IDNA2003; I see no reason to believe it will work any better
> > going forward.
> >
> >     john
> >
> >
> > _______________________________________________
> > Idna-update mailing list
> > Idna-update at alvestrand.no
> > http://www.alvestrand.no/mailman/listinfo/idna-update
> >
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>



-- 
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080318/39779838/attachment-0001.html