Re: Written (and oral) format of NSAPs

[Francis Dupont <[e-mail]>]

I agree with Richard and Marcel proposals. Today there is a document with
an external (i.e. for human beings) representation of NSAPs: the draft RFC
draft-ietf-noop-tools-03.txt:

>         7.  OSI HOST.txt format
>         ...
>         OSI applications may use another file name for  osi  address
>         information.   NSAP addresses in any osi address information
>         MUST use the format below.
>         ...
>         Format of osi hosts file:
>
>         <NSAP Address> <name1> <name2> ...<name>
>
>
>         The NSAP Address should be in the following format:
>
>                 <first octet>.<2nd octet 3rd octet>.<4th octet 5 octet>.
>                 ..... <18th octet> <19th octet> .<20th octet>
>
>
>
>         comments on the above format:
>
>         The NSAP octets should be expressed in hexidecimal. The dots
>         are  aids  to  help  read  the NSAP address, and MUST NOT be
>         required for an NSAP address  parsing.  However,  each  NSAP
>         address  file MUST be able to have the ability to handle the
>         insertion of dots.  The location of the inserted dots within
>         an NSAP address MUST NOT have any significance other than to
>         make the address easier to read.
>
>
>         An example of this use in the GOSIP format is:
>
>                 47.0005.80ff.ff00.0000.0001.0001.0a0b.0c0d.0204.00
>
>         An example of this format in ANSI format is:
>
>                 39.480f.8000.0500.0000.0001.0001.0a0b.0c0d.0204.00
>
>         This value quickly shows the AFI and the NSEL octets on either end.
>
>         <name1> <name2> <name> - Indicates a sequence of name associated with
>         this nsap address.

Of course the draft RFC draft-manning-dns-nsap-03.txt on NSAP DNS RRs uses
the same *external* representation...

[e-mail]