+1
From: mark.edward.davis at gmail.com
[mailto:mark.edward.davis at gmail.com] On Behalf Of Mark Davis
Sent: Thursday, June 11, 2009 11:21 AM
To: Phillips, Addison
Cc: Peter Constable; Martin J. Dürst; Kent Karlsson; LTRU Working Group
Subject: Re: [Ltru] Issue #61: Problem with MAY in 3.5 on Description
errata(Apps #13)
I have no objections to the
change. In some future version we can fix the goofy use of "frowned upon by the community".
Mark
On Thu, Jun 11, 2009 at 10:32, Phillips, Addison <addison at amazon.com> wrote:
Lacking clear guidance, I am
following Martin’s consensus determination that we should converge on a version
of the text that is “clearer than the original, but doesn’t change its
meaning”. I have therefore replaced this paragraph:
--
While the 'Description' field itself is not guaranteed to be stable and
errata corrections MAY be undertaken from time to time, attempts to provide
translations or transcriptions of entries in the registry itself will probably
be frowned upon by the community or rejected outright, as changes of this
nature have an impact on the provisions in Section 3.4 (Stability of IANA Registry Entries).
--
With the following, adapted
from Martin’s proposal, but aping as closely as possible the original wording:
--
<t>The 'Description'
field itself is not guaranteed to be stable and MAY be modified via the
registration process. Errata
corrections or clarifications
of intent are most typical.
Attempts to provide translations
or transcriptions of entries
in the registry itself will
probably be frowned upon by the community or
rejected outright, as changes
of this nature have an impact on the
provisions in <xref
target="ianastability"></xref>.</t>
--
Addison Phillips
Globalization Architect --
Lab126
Internationalization is not a
feature.
It is an architecture.
From: Peter Constable [mailto:petercon at microsoft.com]
Sent: Thursday, June 11, 2009 7:05 AM
To: Mark Davis; Martin J. Dürst
Cc: Phillips, Addison; Kent Karlsson; LTRU Working Group
Subject: RE: [Ltru] Issue #61: Problem with MAY in 3.5 on Description
errata(Apps #13)
Mark, please see my reply to
Randy.
From: mark.edward.davis at gmail.com
[mailto:mark.edward.davis at gmail.com]
On Behalf Of Mark Davis
Sent: Thursday, June 11, 2009 6:56 AM
To: Martin J. Dürst
Cc: Phillips, Addison; Peter Constable; Kent Karlsson; LTRU Working
Group
Subject: Re: [Ltru] Issue #61: Problem with MAY in 3.5 on Description
errata(Apps #13)
I don't think yours is any improvement on the
old text, so if that is the only choice, I vote to leave as is.
Mark
On Wed, Jun 10, 2009 at 20:21, "Martin J. Dürst" <duerst at it.aoyama.ac.jp>
wrote:
[hats on]
I declare consensus on the fact that we do not want to remove the MAY,
but are considering the clarification of the text. Please help converging on a
version of the text that is clearer than the original, but doesn't change its
meaning.
[Randy, this doesn't close this issue yet]
Please say whether you are okay with the new text proposed at the end of this mail.
On 2009/06/11 1:35, Mark Davis wrote:
Although going in the right direction, I don't think it quite hits the mark,
since it is still talking about "the community", which is not defined
and
has no other status in the document. It also gives no sense of who is doing
what. I have suggested language below, plus the other formulations for
comparison.
Mark:
The Description field MAY be modified, and is thus not guaranteed to be
stable. However, modifications are discouraged because of the negative
impact on the provisions in Section 3.4 (Stability of IANA Registry
Entries). Therefore the Language Subtag Reviewer SHOULD accept only
modifications for errata corrections or required clarifications of intent,
and SHOULD NOT accept translations or transcriptions of entries in the
registry.
This text introduces two new shoulds where we only had a MAY, unrelated to
the comment. This is clearly inappropriate at this stage of the process.
OLD
While the 'Description' field itself is not guaranteed to be
stable
and errata corrections MAY be undertaken from time to time,
attempts
to provide translations or transcriptions of entries in the
registry
itself will probably be frowned upon by the community or rejected
outright, as changes of this nature have an impact on the
provisions
in Section 3.4.
Peter:
The Description field MAY be modified. Modifications for errata corrections
or clarifications of intent might be considered acceptable by the community,
but attempts to provide translations or transcriptions of entries in the
registry itself will probably be frowned upon by the community or rejected
outright, as changes of this nature have an impact on the provisions in
Section 3.4 (Stability of IANA Registry Entries). Note that, since
modifications are possible, the Description field is not guaranteed to be
stable.
I agree with Mark that 'community' isn't well defined. But it was in our
original text, so we can leave it in. However, Peter's text doubles it. I
propose removing the first one. I also re-added the quotes to 'Description',
split a sentence, removed " or clarifications of intent" (well
intended, but not in the original text), and changed the 'might' to 'are'
("errata might be acceptable" sounds as if some errata are not
acceptable, which I would have difficulties understanding). The new text I'm
proposing is:
NEW text:
The 'Description' field MAY be modified. Modifications for errata corrections
or clarifications of intent are considered acceptable. However, attempts to
provide translations or transcriptions of entries in the registry itself will
probably be frowned upon by the community or rejected outright, as changes of
this nature have an impact on the provisions in Section 3.4. Note that, since
modifications are possible, the Description field is not guaranteed to be
stable.
Please say whether you are okay with the new text or want some additional
changes. If you propose additional changes, please include your full new text
after motivating the changes. If you propose changes, please try to stay as
close as possible to the text and intent of the original text.
Regards, Martin.
--
|