Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!FTP.COM!jbvb
From: jbvb@FTP.COM (James B. Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Token Ring ARPs
Message-ID: <9104102154.AA29847@ftp.com>
Date: 10 Apr 91 21:54:12 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jbvb@ftp.com
Organization: The Internet
Lines: 29


    You brought up another valid issue: how does an application which
    runs on various media know what the address format is. The right
    answer is that it always expects it in one format. I'm not sure
    what you mean by opaque, the point is that the application wants
    to see the data.

By 'opaque' I mean "uninterpretable, monolithic".  The less applications
have to know about the detailed format of addresses (IP or MAC), the better.
Arbitrary MAC addresses can't be parsed without the context of what sort
of LAN they originated on, so applications that need to know e.g. whether
a specific packet was broadcast or multicast have to have tables of LAN
address formats in any case.
    
    ....
    It would certainly be nice to have the driver hook, but I think the 
    client of the driver could know the format based on the interface type.

If you're going to be passing MAC addresses around at all, even if you
don't parse them, you *really* need to be uniform across all protocols.
Otherwise you'll be in real trouble if a node supports two protocol
stacks, one which canonicalizes the bit order and the other which doesn't,
and you only have a management tool for one stack.  Thus, everyone I've
discussed the issues with to date assumes that the ASI or NDIS drivers
would have to canonicalize the bit order presented at their API in order
to implement this change.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901