home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / protocol / iso / 1453 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  2.7 KB
  1. Path: sparky!uunet!dziuxsolim.rutgers.edu!caip.rutgers.edu!baos
  2. From: baos@caip.rutgers.edu (Bancroft Scott)
  3. Newsgroups: comp.protocols.iso
  4. Subject: Re: Question about the SET construct of ASN.1
  5. Message-ID: <Dec.27.08.59.04.1992.12637@caip.rutgers.edu>
  6. Date: 27 Dec 92 13:59:04 GMT
  7. References: <223791*jpalme@su-kom.dsv.su.se>
  8. Organization: Rutgers Univ., New Brunswick, N.J.
  9. Lines: 48
  10.  
  11. jpalme@dsv.SU.SE (Jacob Palme DSV) writes:
  12.  
  13. >I have a question about the SET construct in ASN.1.
  14.  
  15. >I know that the SET construct allows the agent which encodes in ASN.1
  16. >to put the elements in arbitrary order.
  17. >My question is: Does this mean that the order of the element
  18. >is totally insignificant, and that the construct might be unpacked
  19. >and packet with a different order of the elements during
  20. >transmission?
  21.  
  22. There is no *semantic* significance placed on the order of the
  23. components of the SET.  You can think of this as meaning that the
  24. creator of an ASN.1 specification uses a SET to convey the notion that
  25. the ordering of the components of the SET is arbitrary as far as the
  26. application program is concerned, and that there is no significance to
  27. the ordering, from an abstract point of view.
  28.  
  29. However, when it comes to encoding/decoding the SET, the various
  30. encoding rules of ASN.1 (BER, PER, CER, DER) place differing
  31. requirements on the order in which components of a SET are encoded.
  32. BER imposes no restrictions at all, so the order of the encoded
  33. components is entirely unpredictable ... a testament to the
  34. flexability of BER.  All the other encoding rules of ASN.1 impose
  35. requirements on the order in which components of a SET are encoded,
  36. independent of the order in which they were defined in the ASN.1
  37. specification.
  38.  
  39. >Or can one assume that the order in which the elements were coded
  40. >by the encoding agent will be preserved when the deconding agent
  41. >unpacks the ASN.1 structure?
  42.  
  43. In the case of all ASN.1 encoding rules other than BER, you are
  44. guaranteed that the order in which the elements are encoded is the
  45. same when decoded, since those encoding rules mandate a single way in
  46. in which the components can be encoded.  However, in the case of BER
  47. it is possible for you to encode data in one order, and due to the PDU
  48. passing through a relaying application (which may decode and re-encode
  49. it), the order in which the components were originally encoded differs
  50. upon receipt.
  51.  
  52. To summarize, your application should never make any assumptions about
  53. the order in which components of a SET are encoded.
  54.  
  55. =====================================|========================================
  56. Bancroft Scott                 |        Open Systems Solutions, Inc.
  57. 609-987-9073                 |        Princeton, N.J.
  58. =====================================|========================================
  59.