Message-Id: <6.2.1.2.2.20050714231220.04555040@mail.afrac.org>
Date: Thu, 14 Jul 2005 23:22:26 +0200
To: "Randy Presuhn" <randy_presuhn@mindspring.com>,
	"LTRU Working Group" <ltru@ietf.org>
From: r&d afrac <rd@afrac.org>
In-Reply-To: <00a501c588a7$425f8780$7f1afea9@oemcomputer>
References: <F8ACB1B494D9734783AAB114D0CE68FE0684B0C9@RED-MSG-52.redmond.corp.microsoft.com>
	<6.2.1.2.2.20050714140510.04536780@mail.afrac.org>
	<00a501c588a7$425f8780$7f1afea9@oemcomputer>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Subject: [Ltru] Compatibilities
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Dear Randy,
I am extremely sorry, but I do not think the post below does not seem 
compatible, at least with a co-chair hat.

At 21:07 14/07/2005, Randy Presuhn wrote:
>The resolution of issues like #945 and #949 indicates that the WG places 
>at least
>some value on compatibility, and the comments indicate that there is 
>strong interest
>in ensuring that existing code will be able to syntactically cope with new 
>tags.

This is an opinion. It underlines that the consensus is on "at least some 
value on compatibility". This I agree, but not on a new "compatibility". 
That the consensus is a "strong interest".

>    *Compatibility.* All RFC 3066 language tags  (including those in the
>    IANA registry)  remain valid in this specification.  The changes in
>    this document represent additional constraints on language tags.
>    That is, in no case is the syntax more permissive and processors
>    based on the RFC 3066 ABNF (such as those described in [XMLSchema])
>    will be able to process the tags described by this document.  In
>    addition, this document defines language tags in such as way as to
>    ensure future compatibility.

May I remind this is a last call. And that due to the indications above 
there must be a consensus on adoption of this. And the silence is not support.

>Please indicate whether you agree or disagree with this goal.  A check
>with http://tools.ietf.org/wg/ltru/draft-ietf-ltru-registry/ shows that this
>material has been around for a while, modulo wordsmithing.

The lack of analysis of the Charter did not permit to evidence that the 
problem of RFC 3066 was the lack of organised flexibility. Adding rigidity 
is not appropriate. The RFC 3066 existing rigidity is a problem which is by 
nature as old as RFC 3066.

The real difficulty will be to have the IESG impose the text of a "Best 
Common Practices" against used running code and existing published and 
documented usage (http://rfc3066.org)
jfc




>Randy, ltru co-chair
>
> > From: "r&d afrac" <rd@afrac.org>
> > To: "Peter Constable" <petercon@microsoft.com>; "LTRU Working Group" 
> <ltru@ietf.org>
> > Sent: Thursday, July 14, 2005 5:28 AM
> > Subject: [Ltru] Last call: Private UseTags
> >
>
> > At 01:53 14/07/2005, Peter Constable wrote:
> > >The use of Alpha and AlphaNum, which JFC considers a discriminatory
> > >limitation,
> >
> > I think there may be a confusion here in my typing. I consider what is
> > discriminatory (and also absurd) the limitation of Alphanums to 8 bytes in
> > x-tags.
> >
> > >is nothing of the sort, and cannot be changed unless
> > >backward compatibility is to be abandoned.
> >
> > I fully support the logic presented by F. Charles that this backward
> > compatibility with something which never existed (since future x-tags are
> > by nature ... future) is absurd. This is a good documentation of the
> > religious opposition of this Draft to future and innovation.
> >
> > >Since there was consensus
> > >from the outset that backward compatibility must be maintained,
> >
> > Please reference the URL of this consensus. I make it a last call issue
> > that such a backward "compatiblity" when non necessary is not to be 
> introduced.
> >
> > >and
> > >since it was clear from the last call back in December that backward
> > >compatibility with protocols that consume RFC 3066 is essential,
> >
> > 1. as someone put it against me: December Last Call is over.
> > 2. I was I think one of the most active during that Xmas Call....
> >
> > >then I
> > >think this is not open to reconsideration, and therefore this proposed
> > >text cannot be accepted.
> >
> > "I think" is not a consensus. "I think myself" is not either. Only "we
> > think" makes one.
> > I do not know if a text cannot be accepted due to your opinion. But I know
> > that no one will think there a consensus against running code....
> >
> > >Thus, I think this issue can remain closed.
> >
> > If you mean the whole Draft, I think it could. But this would not change
> > that the current work in many areas need a framework. I do not oppose a
> > grasroots one, but I think that an adherence of IETF to that process would
> > be of interest.
> > jfc
>
>
>
>
>_______________________________________________
>Ltru mailing list
>Ltru@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru