Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!RHINO.NCSL.NIST.GOV!tebbutt
From: tebbutt@RHINO.NCSL.NIST.GOV (John Tebbutt)
Newsgroups: comp.protocols.iso.dev-environ
Subject: Encoding RFC1006 Addresses
Message-ID: <9001171721.AA07180@rhino.ncsl.nist.gov>
Date: 17 Jan 90 17:21:24 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: National Institute of Standards and Technology (NIST)
Lines: 35

Dr. Rose,

First, many thanks for your explanation of interim network address
encodings.

Second :
 
>Thus, if "interim network addresses" are in use, you can
>algorithmically determine which community is being referenced...
 
Does ISODE do this ? In particular, can I, as an application process,
treat an interim encoded network address *exactly* as if it were a
legitimate OSI NSAP address, and load the ISODE struct NSAPaddr
accordingly ? Does ISODE check the value of the OSI NSAP to determine
what kind of network service is required ?  Or does the user need to
parse the interim encoded address in order to properly load the struct
NSAPaddr of the Presentation Address structure ? If the latter is the
case, does ISODE provide routines for parsing and encoding the interim
form ?
 
Third : On reading the ISODE 5.0 Manual, I thought for a moment that
the naddress "normalization" routine, na2norm(), would provide the
answer to my second point (above). Having read it, I am not so sure (!).
What kind of naddress should na2norm() be applied to, and what kind
of naddress does it return ?  The implication is that it should be
applied to addresses containing interim address encodings (presumably
carried as regular OSI NSAPs), to convert them to `"real" OSI
addresses' - I thought the interim encoded addresses WERE the "real"
OSI addresses !
 
 
        Thanks in anticipation,


                John Tebbutt, NIST