Re: Grammatical corrections to the headers and boilerplate text

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yes, but that isn't the worst problem.   I made a
deliberately-dumb suggestion in the hope of making a point, but
obviously failed.   Let me try once more...

Conventions, consistently applied, are usually a good thing,
even when establishing them involve arbitrary choices.  The IETF
community ought to understand that because ultimately many or
most of our protocol standards, and certainly our focus on
interoperability, are just such conventions, defined to make the
Internet work better (or work at all).  

I appreciate Ole's examples and the implicit question of where
one draws the line.  In other capacities, I enjoy and learn from
debates about "correct" and "not correct" (the article Christian
cited at
https://www.theonion.com/4-copy-editors-killed-in-ongoing-ap-style-chicago-manu-1819574341
) is very much part of that discussion even though some of us
who dislike the Chicago Manual dislike the AP one even more), as
are places where Gowers says things that some reasonable people
believe Fowler would have found quite surprising), but the
important examples that justify having a single style norm and
sticking with it are actually different.  Several examples
follow with the understanding that this is not a comprehensive
list, but one that I hope will be sufficient that we don't have
to have several days of people adding others (and my thanks to
those who suggested some of these in private or on-list notes):

 * Is "1,000" one thousand, or is the comma a radix
	separator, making the string have a value of one?
 * Is "one billion" 10^9 or 10^12?  Or is exponential
	notation better expressed as 10**9 or 10**12 (a question
	that has nothing to do with British-American
	distinctions)?
 * Do "mbps", "Mbps", "mBps", and "MBPS" describe the
	same unit?  If not, which ones are around an order of
	magnitude different from the others?   Note this isn't
	an American-British distinction either.
 * If I am trying to search an RFC to find a discussion
	of ways of showing emphasis, do I use "color" or
	"colour" in the search string?  Or, borrowing from the
	LUCID discussion, if I'm trying to search for an
	important city in Switzerland, do I search for "Zurich"
	or "Zuerich" (or actually spell it correctly, as
	Zürich)? 

I note that the latter example is not an American-British
English distinction but is still something that a comprehensive
style guide might want to pin down.  We should remember that, as
we move toward fancy RFC formats and non-ASCII text, that third
choice becomes possible and, while grep, emacs, and their clones
have powerful regular expression functionality, it may not be
quick to use.  That functionality is typically not present in
"find" functions in web browsers or PDF readers, making a
further argument for one set of conventions.

We cannot solve all of these problems, but should not make more
for ourselves by encouraging different style choices or, worse,
by allowing choices that are inconsistent within a given
document.

Bottom line: one language, one style manual, and one dictionary
to be used to settle spelling arguments.  That there be only one
of each is far more important than which one is chosen.   In
particular, I don't like the Chicago Manual, especially more
recent editions, and argued against that choice when it was
made.  I lost and, while I complain about it periodically, I
work with it.  Similarly, although RFC 7322 doesn't say so, my
recollection is that the RFC Editor tends to prefer
Merriam-Webster dictionaries, notably the _Collegiate_ (about as
"American English" as they come).  I don't, largely because
their dictionaries have moved at bit too much away from notions
of authority and toward statistically-common usage for my taste.
But, in the interest of consistent conventions, I live with it.

We can fantasize about the RFC Editor being able to work with
several different choices of English, Style Manuals, etc., but
those fantasies would ultimately make the RFC Series less useful
and would almost certainly increase costs and/or the length of
time it takes to get a document through the system in the
process.

However, the particular issue that started this discussion is
actually part of a different problem.  For IETF-stream
documents, the document editor is typically acting on behalf of
a WG or the IETF more broadly.   If anyone comes later to a set
of document authors or editors and says "you illiterate fools",
a reasonable response is "don't blame me, the WG signed off".
That is not the case for independent submissions, where there is
no such community effort and, both in appearance and reality,
the author really is responsible for 100% of the text, at least
until we start attaching explicit disclaimers about where some
of the text comes from.  The question there is whether, if the
rest of the document is written in American English (and
accepted by the RFC Editor as such) whether the author has the
right to insist that all of the document be consistent with
American English rules and conventions (independent of what
might or might not be valid in other places).  Where the
boilerplate is concerned, is to reasonable to either insist that
it be in American English or that it contain an explicit
disclaimer that the author is not responsible in any way for
that text?

best,
   john



--On Tuesday, February 13, 2018 20:27 -0800 Ole Jacobsen
<olejacobsen@xxxxxx> wrote:

> 
> So long as you don't extend the logic to common British
> usage which is weird enough for things like "Apple have
> announced" and "England have won the World Cup," but
> please spare us from "I am stood in front of..." and
> "We were sat there for 3 hours."

> On Wed, 14 Feb 2018, Lloyd Wood wrote:
> 
>> Just to reply en masse to the concerned Americans in my
>> mailbox:
>> 
>> Plurals are not a singular noun.
>> Still correct, still grammatical.
>> 
>> If I'm comparing two lions with one wallaby, 'The lions are
>> not a wallaby" is a valid statement.
>> 
>> "Oranges are not the only fruit"
>> 
>> 
>> https://en.wikipedia.org/wiki/Oranges_Are_Not_the_Only_Fruit
>> 
>> We have this grammatical usage in literature...
>> 
>> everything else is blah blah blah bikeshedding.
>> 
>> https://en.wiktionary.org/wiki/bikeshedding
>>  
>> Lloyd Wood lloyd.wood@xxxxxxxxxxx http://about.me/lloydwood 
>> 
>> 
>> 
>> ________________________________
>> From: John C Klensin <john-ietf@xxxxxxx>
>> To: Joe Abley <jabley@xxxxxxxxxxx>; Stewart Bryant
>> <stewart.bryant@xxxxxxxxx>  Cc: ietf@xxxxxxxx
>> Sent: Wednesday, 14 February 2018, 7:47
>> Subject: Re: Grammatical corrections to the headers and
>> boilerplate text
>> 
>> 
>> 
>> 
>> --On Tuesday, February 13, 2018 13:50 -0500 Joe Abley
>> <jabley@xxxxxxxxxxx> wrote:
>> 
>> 
>> > On 13 Feb 2018, at 03:37, Stewart Bryant
>> > <stewart.bryant@xxxxxxxxx> wrote:
>> > 
>> >> This may be a US vs UK English thing, but I agree with
>> >> LLoyd, the original seems quite correct to me.
>> > 
>> > I agree. The replacement text also seems fine, though. I
>> > guess the new text is more correct, if we're measuring
>> > correctness by proportion of the audience that is happy
>> > with it.
>> 
>> I suggest a slightly different measure, which is tied to a
>> long tradition of the normative publication language of the
>> RFC Series being, explicitly, American English.  That was,
>> IIR, much more strongly reflected in some of the informal
>> documents used after RFC 2223 and before 7322, but 7322
>> reflects it as a preference for American spelling (Section
>> 3.1) and the Chicago Manual of Style (Section 1).  The latter
>> is definitely a reference on American English, arguably the
>> most extreme of them (and, at least IMO, getting more so in
>> recent years).
>> 
>> Now, while RFC 7322 is not explicit about it, although it is
>> implied in the spelling discussion in Section 3.1, there is
>> also a long tradition of allowing authors to do things in
>> whatever way they like as long as the language is
>> recognizably English and the document is consistent
>> throughout.   So, let me suggest two theories:
>> 
>> (1) Following American English and the Chicago Manual of
>> Style, the current boilerplate construction is simply wrong,
>> partially because the presence or absence of negation changes
>> nothing in American English about subject-verb-predicate
>> matching of number, and the proposed new text is correct.
>> 
>> (2) Following the consistency rule, if the rest of an RFC is
>> written consistently in American English (either because the
>> author wrote it that way or because the Production Center
>> corrected it), then the boilerplate should also be consistent
>> with  American English.   Same conclusion: the proposed new
>> text is correct.
>> 
>> However, the second theory suggests a different option which,
>> if someone wants to advocate (and presumably do the work), I
>> would personally support if the RFC Editor had no objections.
>> That would be to allow instructions to the RFC Editor and,
>> presumably, a directive to XML2RFC, to specify the author's
>> preferred English style.  If that directive specified
>> "American" (presumably the default, at least for historical
>> reasons) then the boilerplate would be shifted to match that
>> preference.  If it specified "British", then that preference
>> would be followed and the boilerplate would read as Lloyd and
>> Stewart have suggested (with other parts of the boilerplate
>> being made consistent).
>> 
>> I do have two cautions about that plan, but they are just
>> cautions.  First, there is a slippery slope due to the many
>> versions of English out there.  I'm happy with the American
>> versus British dichotomy, but, as someone who has never been a
>> huge fan of the Chicago manual, I can imagine an argument for
>> different styles of grammatical hair-splitting based on
>> regional or dialect preferences.   Probably we don't want to
>> go there, but other opinions may reasonably differ.   Second,
>> some of the other boilerplate (not affected by the current
>> discussion but possibly affected if we start doing wholesale
>> revisions to conform to, e.g., Gowers or Fowler) could run
>> into a problem with assumptions that the legalese assumes US
>> law.  IANAL and have no idea whether changes there would
>> create any normative problems, but have often been told that
>> an important principle in any litigation is not to start out
>> by irritating the relevant judge, including by appearing
>> illiterate to a judge that is sensitive to such issues.    So
>> be careful what you wish for.
>> 
>> best,
>>     john
>> 
>> 








[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]