Subject: Re: [Ltru] Ticket #37: AD Issue #4: delete last sentence in Section 2.2.9

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 18 May 2009 18:53:49 +0900

For the record, as a technical contributor, I agree with others that the 
sentence in question should be removed (as it already has been).

I also don't understand Addison when he writes
"Therefore, it is useful to have some documentation explaining why this 
ABNF is better."
We didn't delete the reason, the mention of the errors in the previous
ABNF is still there.

Regards,    Martin.

On 2009/04/29 13:42, Phillips, Addison wrote:
> The AD points out:
>
> --
> AD review issue #4 - for details see
> http://www.ietf.org/mail-archive/web/ltru/current/msg12399.html
>
> 4). In Section 2.2.9:
>
>      Note well: although the 'Language-Tag' production appearing in this
>      document is functionally equivalent to the one in [RFC4646], it has
>      been changed to prevent certain errors in well-formedness arising
>      from the old 'grandfathered' production. This version of the ABNF is
>      RECOMMENDED as a replacement for the older version.
>
> (nit) I suggest deleting the last sentence, as it doesn't provide any
> useful information to a reader (as the WG wants
> draft-ietf-ltru-4646bis-21bis.txt to replace RFC 4646, it is clear that
> the WG believes that the new ABNF is better). Also I don't think it uses
> RFC 2119 keyword properly.
> --
>
> I think this is not necessary. We have had, as a user community, a long-standing problem with stale references to BCP 47. We want to help ensure that implementers and standardizers use the right ABNF. It is well-known that many implementers rely excessively or even exclusively on the ABNF to determine "what is right". Therefore, it is useful to have some documentation explaining why this ABNF is better.
>
> Proposed resolution: no change
>
> Addison Phillips
> Globalization Architect -- Lab126
>
> Internationalization is not a feature.
> It is an architecture.
>
>
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 18 May 2009 07:52:03 -0700

(as editor)

Uh.......

Am I supposed to delete the sentence or not? I can't tell if my proposed resolution was accepted or not.

Addison

Addison Phillips

> -----Original Message-----
> From: "Martin J. Dürst" [mailto:[email-masked]]
> Sent: Monday, May 18, 2009 2:54 AM
> To: Phillips, Addison
> Cc: LTRU Working Group
> Subject: Re: [Ltru] Ticket #37: AD Issue #4: delete last sentence
> in Section 2.2.9
> 
> > I think this is not necessary. We have had, as a user community,
> a long-standing problem with stale references to BCP 47. We want to
> help ensure that implementers and standardizers use the right ABNF.
> It is well-known that many implementers rely excessively or even
> exclusively on the ABNF to determine "what is right". Therefore, it
> is useful to have some documentation explaining why this ABNF is
> better.
> >

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 18 May 2009 12:26:10 -0700

Hi -

The resolution is recorded in the tracker
http://trac.tools.ietf.org/wg/ltru/trac/ticket/37
Delete the sentence reading "This version of the
ABNF is RECOMMENDED as a replacement for the older version."

Randy

----- Original Message ----- 
> From: "Phillips, Addison" <[email-masked]>
> To: "Martin J. Dürst" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Monday, May 18, 2009 7:52 AM
> Subject: Re: [Ltru] Ticket #37: AD Issue #4: delete last sentence in Section 2.2.9
>
> (as editor)
>
> Uh.......
>

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 18 May 2009 12:24:40 -0700

This is done.

Addison

Addison Phillips

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randy Presuhn
> Sent: Monday, May 18, 2009 12:26 PM
> To: LTRU Working Group
> > > "Therefore, it is useful to have some documentation explaining
> why
> > > this
> > > ABNF is better."
> > > >      Note well: although the 'Language-Tag' production
> appearing
> > > in this
> > > >      document is functionally equivalent to the one in
> [RFC4646],
> > > it has
> > > >      been changed to prevent certain errors in well-
> formedness
> > > arising
> > > >      from the old 'grandfathered' production. This version of
> the
> > > ABNF is
> > > > (nit) I suggest deleting the last sentence, as it doesn't
> provide
> > > any
> > > > the WG believes that the new ABNF is better). Also I don't
> think
> > > it uses