Subject: RE: draft-ietf-krb-wg-gss-cb-hash-agility-01.txt

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 5 Apr 2007 00:44:58 -0700

On page 3 of RFC4121, we have the following text:

   The term "little-endian order" is used for brevity to refer to the
   least-significant-octet-first encoding, while the term "big-endian
   order" is for the most-significant-octet-first encoding.

Because this document updates RFC4121, we should be covered here if we
just stick with using the big-endian order idom.

--larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, March 27, 2007 3:25 PM
To: Shawn M Emery
Cc: [email-masked]; [email-masked]; Liqiang(Larry) Zhu;
[email-masked]
Subject: Re: draft-ietf-krb-wg-gss-cb-hash-agility-01.txt

Shawn M Emery wrote:
> 
> Earlier in the document, it defines "big endian order" as "the 
> most-significant-octet-first encoding".
> I should be sufficient. The next revision of the draft will use "big 
> endian order", instead
> of "network-byte order".  I think that this was the only issue so far 
> with revision 1 of the document?

I really want to see the terms "big endian" and "network-byte order"
removed entirely from the document and only an expression like

   most significant octet first

being used.

I think it is a bad idea to use funky and confusing
names where a suitable self-describing term is available.

-Martin

---

From: Marcus Watts <[email-masked]>
Date: Thu, 05 Apr 2007 05:24:02 -0400

"Liqiang(Larry) Zhu" <[email-masked]> sent:
> From: Martin Rex [mailto:[email-masked]]=20
> >=20
> > Earlier in the document, it defines "big endian order" as "the=20
> > I should be sufficient. The next revision of the draft will use "big=20
> > endian order", instead
> > of "network-byte order".  I think that this was the only issue so far=20

If you're aiming to avoid ambiguity, then an octet might mean
8 musicians or 3 bits that can describe 8 states.  Despite this
small problem, it appears commonly in RFCs starting in 1974.

The term "Big endian" has a slightly ancient and somewhat noble history:
it was coined by Swift in 1791, and much later applied to computers by
Cohen in "On Holy Wars and a Plea for Peace" (1981).  "Big-endian" appears
starting with RFC 916 (oct 1984) (which cites Cohen 1981).

"Network Byte Order" first appears in RFC 951 (Sept 1985), to describe
an ordering that was first described in RFC 791 (sept 1981).  The ordering
itself seems to have been used well before that, but as best I can tell
nobody thought it needed explanation before then.  RFC 791 appendix B
does have a nice description complete with pictures.

It may be advantageous to use the same terms everybody else
does.  According to my (admittedly crude) counts,
	X	appears about 	Y	times in various RFC's:
"network byte order"		655
"big endian"			280
"most significant octet" 	192
The amount of explanation in RFCs for what these terms mean vary.  Many
more recent RFC authors apparently believe "network byte order" is a
suitable, obvious, non-ambiguous, and sufficient term.

RFC 1392 (and its successor, RFC 1983) define "octet" and "big-endian",
but not "network byte order".

					-Marcus Watts

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Apr 2007 11:57:53 -0500

I'm with Larry here.  RFCs 1964 and 4121 used 'little-endian' and
'big-endian', so it seems natural that any updates to them should stick
to terminology that was in use in those RFCs.

Marcus' analysis of the RFC series' use of these and other terms, and of
the history of some of these terms is fascinating.  Thanks for taking
the time to look at that.

Finally, RFC4121 actually has a paragraph, that this I-D repeats,
defining big- and little-endian:

which should be more than sufficient...

...unless we take Marcus' note about 'octet' being confusing seriously,
in which case we'll have to use 'byte' or else add a definition of
'octet' :)

So, count me as being in favor of leaving draft-ietf-krb-wg-gss-cb-
hash-agility-01.txt alone on this matter.

Have we spilled enough bandwidth on this topic now?

Of course, this tangent was worth it, since IEN137 is worth reading and
re-reading every so often...

Nico
--

---

From: Marcus Watts <[email-masked]>
Date: Thu, 05 Apr 2007 15:03:53 -0400

At the risk of spilling more ascii ink:
Nicolas Williams <[email-masked]> writes:
...
> in which case we'll have to use 'byte' or else add a definition of
...
A few RFC's say "8 bit octet".  RFC 4042 promotes the use of "9 bit nonets"
in a hysterical attempt to convince the reader that 36-bit computing is
merely on hiatus.

...
> re-reading every so often...

I'm amazed Cohen failed to point out that arabic numbers were
originally written in little-endian order, and still are in many
parts of the world.

					-Marcus Watts

---

From: Brian Tung <[email-masked]>
Date: Thu, 5 Apr 2007 13:07:33 -0700

> originally written in little-endian order, and still are in many

I saw a German manuscript from the first half of the 20th century, in
which seven-and-a-half was written as "Â½7"--that is, the 1/2 first,
and then the 7.  Is that still common in Germany?

-- 
Brian Tung <[email-masked]>
USC Information Sciences Institute