rfc1698.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,543 行 · 第 1/5 页


RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


        First side disconnects transport connection on receiving the
        reply

   To close connection abruptly but also send application data

        Send the message defined in 6.7, which is Session ABORT
        carrying Presentation U-ABORT [ARU] carry ACSE U-ABORT [ABRT]
        carrying application data (delivery not guaranteed)

        On receiving Session ABORT, disconnect transport

   To close connection abruptly

     -  Either send the message defined in 6.8, which is Session ABORT
        carrying nothing;

        Or, just disconnect at transport level

   A group I application is assumed (by definition) not to send data on
   the establishment and release exchanges, a group II application will.

   It would be possible to use the abort-with-data facility with a group
   I to send a (possibly non-standardised) error message for diagnostic
   purposes.

   A special rule is used if a release collision occurs (i.e., FINISH+P-
   RELEASE+RLRQ received after sending the same): the side that
   initiated the original upper-layer connection waits and the other
   side replies with the DISCONNECT etc.

4.2 Which OSI fields are used

   There are a number of fields (parameters) in the pdus involved. These
   can be categorised by what is needed to support applications (of a
   particular Group) in general - a field may  be "useful", "send-only",
   "fixed", "fixed with default", "internal" or "not important". Even
   those that are not important may be received from another
   implementation, but since the application has no use for them, they
   can be ignored. If an implementation is intended to support only a
   particular application, it may be able to downgrade the "useful" to
   "not important".

   The text below describes the processing that is required for each
   category and which fields are in each category.

   "Useful" - when sending, an implementation of general use should be
   able to set any (legal) value of these fields (via the upper
   interface from the application or via some configuration or lookup



Furniss                                                        [Page 12]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


   mechanism) and SHOULD pass received values for the Calling values to
   the application (for specific applications, these fields may be
   either required or unnecessary.)

    AARQ:

      Called application-process title
      Called application-entity qualifier
      Calling application-process title
      Calling application-entity qualifier

   "Send-only" - to interwork, the implementation must be able to set
   any value of these, but can ignore any received value. Both are octet
   strings.

      Presentation selector (up to 4 octets, limited by CULR-1)
      Session selector (up to 16 octets, limited by base standard)

   "Fixed" (constant for all applications)

      abstract and transfer syntax identifiers for presentation context
      for ACSE Version numbers - 2 for session, 1 for Presentation
      and ACSE

   "Fixed with default" - the value is specific to the application. For
   non-ASN.1 abstract syntaxes (group I or group II only) applications,
   the anonymous values assigned by the OIW minimal OSI profile [CULR-3]
   can be used. The CULR-3 default application context can be used where
   a proper context name is neither available nor needed.

      Application context
                       CULR-3  default is {1 0 11188 3 3}
      Abstract syntax identifier for application data
                       CULR-3 anonymous name is {1 0 11188 3 1 1}
      Transfer syntax identifier for application data
                       CULR-3 anonymous name is {1 0 11188 3 2 1}

   "Internal" - an arbitrary value can be sent; a received value must be
   stored for use in sending.

      Presentation context identifiers for ACSE and the application
      data (always odd integers)

   "Not important" - for interworking, any legal received value for the
   other fields must be received (i.e., the pdu is parsed successfully),
   but can then be ignored. There is no requirement (in this cookbook)
   to check the existence, value or internal format of these fields.




Furniss                                                        [Page 13]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


      All other fields (which includes a large number of session
      fields)

4.3 Encoding methods and length fields

   Both Session and ASN.1/BER [ISO8824, ISO8825] use a type-length-value
   structure for their encodings, but different ones. Presentation
   protocol and ACSE protocol use the ASN.1/BER encoding and
   consequently a Presentation PDU containing an ACSE PDU can be
   constructed or parsed as if it were a single structure.

   All the protocols contain pdu fields with a compound structure. If
   one of these is being ignored it may be necessary (for BER, not
   session) to determine the lengths of its components to find the
   length of the ignored field.

   Many of the lengths in the specification below will vary, dependent
   on the values of the fields.

4.3.1 Session items

   The type field of a session item is always a single octet.

   For session items, given a particular length, there is no
   flexibility:

      If the length is less than 255, represent as one octet

      If the length is greater, represent as three octets, first is
      0xFF, next two are the length, high-order octet first.

   (Some "real" implementations are known to use the second encoding in
   all cases. This is wrong, but should only concern conformance
   testers.)

4.3.2 ASN.1/BER items (Presentation and ACSE)

   The type field for ASN.1-BER is the tag. Although it is possible for
   large tags (>30) to be multi-octet, there are no large tags in the
   protocols involved in this memo. Bit 6 (0x20) of the tag octet is 1
   if the item is constructed (i.e., the value is itself one or more
   ASN.1 BER items) or 0 if it is primitive.

   There is considerable flexibility, at senders option, in how lengths
   are represented in BER. There are three forms: short, long and
   indefinite.

      Short (usable only if the length is less than 127) : one octet



Furniss                                                        [Page 14]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


      Long (usable for *any* length) : first octet has the top bit set,
      the rest is a count of how many octets are holding the length
      value; that many subsequent octets hold the length. A long length
      may use more than the minimum number of octets (so 0x8400000001
      is a valid representation of length 1)

      Indefinite (usable only for the length of a compound field) : the
      single octet is 0x80, then one or more items (their tag-length-
      values) and finally two octets of 0x00 (equivalent to tag and
      length of zero).

   To be able to interwork generally, an implementation must be able to
   handle any of these forms when receiving.

   The encodings specified in the octet sequences below use indefinite
   length for all constructed items with a few exceptions. This slightly
   increases the number of octets sent, but means that the length of a
   varying field (e.g., user data, or a varying object identifier)
   affects only the length of the item itself, and not the enclosing
   lengths. It is thus possible to use the octet sequences as templates
   interspersed by the varying fields.

   It is important to note that this choice of indefinite (which is
   equivalent to the "Canonical Encoding Rules" variant of BER) applies
   only to the Presentation and ACSE protocols themselves. It does not
   apply to ASN.1/BER encoded application data. The processing required
   of application data may suggest alternative "best" options.

4.4 BER Encoding of values for primitive datatypes

   The following ASN.1 primitive datatypes are used in the thinosi
   stack.

   Integers are encoded in twos-complement, high-order first. Unlike
   lengths, they must be encoded in the minimum number of octets (no
   leading 00 padding).

   Object Identifiers have a rather peculiar, but compressed encoding:

      Combine the first two integers of the OID into one element by
      multiplying the first (always 0, 1 or 2) by 40, and add the
      second.

      Each element (that one, and each subsequent integer in the OID
      taken on its own), is a taken as a binary number and divided into
      7-bit "bytes". This is apportioned into bits 1-7 of the minimum
      number of octets. Bit 8 is one for all octets of the sequence
      except the last. (This means that elements of less than 127 are



Furniss                                                        [Page 15]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


      single octet integers.)

   Printable Strings - as if in ISO 646 (ASCII)

   OCTET STRING - just put the octets there

4.5 Unnecessary constructed encodings

   BER allows the sender to break some items (such as OCTET STRINGS,
   character strings) into several pieces (i.e., as constructed
   encoding) or send them as primitive. CULR-1 requires that this is
   only done to one level. The pieces of both OCTET STRING and character
   string are tagged as if they were OCTET STRING - they have the tag
   04. This memo does not include any of these optional constructions,
   but they may be received in interworking.

5.  Notation

   The constructs are shown in their tag - length - value form. All
   numbers are in hexadecimal. Comments are preceded by a '-' character.
   Multiple '-' mean the comment is more than just information.

   The tag column contains one of:

      single fixed octets.

      * in the tag field indicates one or more pdu fields (possibly
      constructed) that may be received but are not sent. If received
      they can be ignored.

      ! indicates the tag is defined elsewhere.

      .  is a place holder for the column.

      ? preceding the tag value indicates that the field is not always
      present - the comment will explain.

   The length column contains one of

      explicit value

      Ls - a length according to session rules which depends on the
      total size of the value (usually constructed)

      La - a length according to BER rules

      . is a placeholder




Furniss                                                        [Page 16]

RFC 1698             ThinOSI Upper-Layers Cookbook          October 1994


      yy is exactly one octet (i.e., one hex digit per y) holding part
      of the length

   The value column contains one of

      the hex value

      xxxxxx - value of varying length (sometimes constructed)

      {n - (n = number) the start of a constructed value

      n - (n=number) the end of the constructed value with the
      corresponding number. (The number is sometimes omitted on the
      innermost nest of construction)

      yy - as part of a value - a variable value, each y represents one
      hex digit

      ? a value, possibly constructed that may be received but is not
      sent. It may be ignored if received

   Note that all presentation lengths may be received in one of the
   alternative forms. All constructed lengths are shown in indefinite
   form. If a received length is definite, the corresponding end item
   (which will be shown here as 00 00 }n)  will become  . . }n.