Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!ucbvax!info-vax
From: info-vax@ucbvax.ARPA
Newsgroups: fa.info-vax
Subject: Re: 3 Protocol Query
Message-ID: <6506@ucbvax.ARPA>
Date: Thu, 25-Apr-85 13:45:31 EST
Article-I.D.: ucbvax.6506
Posted: Thu Apr 25 13:45:31 1985
Date-Received: Fri, 26-Apr-85 09:04:58 EST
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 29

From: dual!fortune!redwood!rpw3@BERKELEY (Rob Warnock)

+---------------
| From: Jeffrey R. Del Papa <DP@MIT-MC>
| ...ether address and a 2 byte type code. under the new 802.3, you have
| the 12 bytes of address, followed by two bytes of length information.
| there is a type field somewhere, but it means all the protocols will have
| to have the transport layer changed, and it isn't possible to run both
| protocols on the same wire. so much for standards ....  | | 	jeff
+---------------

Note that at least for Xerox-registered Ethernet frame types, there is
no conflict between values in "Ethernet" type fields and "IEEE 802.3"
length fields -- the range of values is disjoint. That is, all of the
official Xerox types have values which are illegal (out of range) 802.3
types. Xerox has registered all of the legal 802.3 "length field" values
(46-1500) as "types", so XNS drivers will not complain about 802.3 packets
(and indeed may be able to handle them as "private" types). Thus, as long
as 802.3 controllers do not barf too badly when receiving "bad" length fields,
XNS and 802.3 can easily share a single cable. (However, this may not be
true for various Berkeley types, such as "trailers". I haven't checked.)


Rob Warnock
Systems Architecture Consultant

UUCP:	{ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD:	(415)572-2607
USPS:	510 Trinidad Lane, Foster City, CA  94404