rfc1698.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,543 行 · 第 1/5 页

3.1 The concepts of abstract and transfer syntax

   OSI includes the concepts of "abstract syntax" and "transfer syntax".
   These are terms for the content (abstract syntax) and format "on-
   the-line" (transfer syntax) of the protocol elements. The combination
   of an abstract syntax and transfer syntax is called a presentation
   context.

   Application protocols devised explicitly under OSI auspices have used
   ASN.1 for the definition of the abstract syntax, and nearly all use
   the Basic Encoding Rules applied to the ASN.1 to define the transfer
   syntax. However, there is no such requirement in OSI in general or in
   OSI Presentation, and still less is there any requirement to change
   the representation of existing application protocols to ASN.1 (for
   their definition) or BER (for their transmission). It is not
   generally realised (even in OSI circles) that all communicating
   applications, in all environments, are using some form of these,
   although under different names and without the explicit
   identification that the OSI Presentation provides. OSI separates the
   identification of the content and format of the data from the
   addressing.

   Formal specifications of non-OSI application protocols (such as
   TELNET, FTP, X Windows System) generally do not use ASN.1, but will
   invariably be found to define abstract and transfer syntaxes.  For a



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


   less formalised protocol used between similar systems, the abstract
   syntax may be defined simply in programming language structures, and
   the transfer syntax determined by how some compiler represents this
   in memory.

   The OSI Presentation protocol requires that "names" be assigned to
   the abstract and transfer syntaxes of the application data that is
   carried.  The names are always object identifiers ("oid"): globally
   unique names assigned hierarchically. Presentation supports the
   negotiation of a transfer syntax for a particular abstract syntax -
   several can be offered and one selected.

   This transfer syntax negotiation facility may be especially useful
   for non-ASN.1 syntaxes where there is more than one representation
   available (perhaps differing in byte-ordering or character code). In
   such a case, on the connection establishment, all of the transfer
   syntaxes supported by the initiator are offered, and any one of these
   accepted by the responder, at its own choice. If the two systems
   share some "native" format they can negotiate that, avoiding
   transformation into and out of a more general format that is used for
   interworking with unlike systems. The same applies to an ASN.1-
   defined abstract syntax, but in practice non-BER encodings of ASN.1
   are rare.

3.2 Use of presentation context by cookbook applications

   An application protocol not originally specified with OSI
   Presentation in mind (a "migrant" protocol) will not normally need to
   identify the abstract and transfer syntaxes being used - they are
   known by some other means (effectively inferred from the addressing).
   A generic (anonymous, if you like) name for both syntaxes can be used
   and [CULR-3] defines object identifiers for "anonymous" abstract and
   transfer syntax names (currently called "default", but this is
   expected to change).

   In some cases object identifier names will be assigned for the
   syntaxes of a migrant application protocol. If these exist, they
   should be used.  However, since the processing required will be the
   same, it will be legitimate to offer both the generic and specific
   names, with the responder accepting the specific (if it knew it) and
   the generic if the specific were not known - this will provide a
   migration option if names are assigned to the syntaxes after
   implementations are deployed using the generic names.

   For abstract syntaxes defined in ASN.1 object identifier names will
   have been assigned to the abstract syntax with the specification.
   This name MUST be used to identify the abstract syntax. The transfer
   syntax will most often be the Basic Encoding Rules (BER) object id,



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


   but alternatives (e.g., Packed Encoding Rules) are possible.

   For group III and group IV applications, specific object identifier
   names must be used for all the abstract and transfer syntaxes. If
   these names are not assigned with the specification (e.g., if the
   specification not in ASN.1) they can be assigned by whoever needs
   them - ideally the "owner" of the syntax specification.

3.3 Processing Presentation-context-definition-list

   In Presentation context negotiation on connection establishment the
   initiator sends a list (the presentation context definition list) of
   the abstract syntaxes it intends to use, each with a list of transfer
   syntaxes. Each presentation context also has an integer identifier.
   To build the reply, a responder has to examine this list and work out
   which of the offered presentation contexts will be accepted and which
   (single) transfer syntax for each. The responder sends back the reply
   field, the Presentation-context-definition-result-list, in the accept
   message. The result list contains the same number of result items as
   the definition-list proposed presentation-contexts. They are matched
   by position, not by the identifiers (which are not present in the
   result- list). An acceptance also includes the transfer syntax
   accepted (as there can be several offered). This can be copied from
   the definition list.

   For the group I, group II and group III cases,  only the ACSE and one
   application-data P-context will be used and all other contexts
   rejected. For the group IV case, several presentation contexts will
   be accepted.

   However, even for group I applications there may be synonyms for an
   application-data Presentation-context. Unknown synonyms are rejected.
   The reply shown in 6.2 includes a rejection (It can therefore not be
   the reply to the connection request shown in 6.1, since that has only
   two items in the definition list.)

   In all cases, the connection responder must identify and keep the
   presentation context identifiers (called pcid's here) for all the
   accepted presentation contexts. These are integers (odd integers, in
   this case). CULR-1 limits them to no greater than 32767, but they
   will usually be <= 255 (so taking up one octet).

   A presentation context is sometimes used (i.e., data is sent using
   it) before the negotiation is complete. As will be seen in section 6,
   in these cases, the transfer syntax name sometimes appears with the
   integer identifier.





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


3.4 Application context

   The Association Control Service Element also exchanges the name
   (another Object Identifier) of the application context, which
   identifies what the communication is all about, again independently
   of the naming and addressing.  As for the syntaxes, although some
   name must be present in the protocol, a generic name can be used for
   applications that do not have a specific name assigned. (This will
   almost certainly be a group I application - if a specific name is
   assigned, it must be used.) The only negotiation allowed is that the
   reply may be different from that sent by the initiator. CULR-3
   provides a generic application context name (i.e., assigns an object
   identifier).

3.5 APtitles and AEqualifiers

   In addition to the addressing constructs (transport address and
   possibly session and presentation selectors), the communicating
   application entities have names - Application-Entity titles
   (AEtitle).  These are carried by ACSE as two fields -the
   Application-process titles (APtitle) and the Application-entity
   qualifier (AEqualifier). The AEtitle is compound, and the APtitle
   consists of all but the last element, which is the AEqualifier. (This
   explanation can be run backwards). There are two non-equivalent
   forms. AP-titles and AE-titles can be Directory Name or an Object
   Identifier. AE-qualifiers can be Relative Distinguished Name (RDN) or
   an integer - the forms must match, since the AE-qualifier is the last
   component of the AP-title. In practice, the Directory form is likely
   to be the only one seen for a while.

   Use of the these names is rather variable. This cookbook proposes
   that implementations should be able to handle any value for the
   partner's names, and set (as initiator) its own names. This is
   primarily to facilitate OSI:non-OSI relaying (e.g., X/osi:X/tcp),
   allowing the names of the end-system to be carried to the relay,
   where they can be converted into hostnames, and the lower-layer
   address determined. OSI assumes that name-to-address lookup is
   possible (via the Directory or other means), but does not assume
   address-to-name will work. Thus the calling AE-title is needed if the
   responder is to know who the initiator is. However, most protocols
   work perfectly well without these names being included.

   As for their encoding, a RDN will almost always be a single attribute
   value assertion, with the attribute defined either by the Directory
   standard [ISO9594 = X.500], or in [Internet/Cosine Schema] [RFC1274].
   Using the notation defined below, the encoding of an RDN using a
   Directory-defined standard attribute is:




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


   31  80  {1         - RDN, [SET OF]
   30  80  {2         - AttributeValueAssertion, [SEQUENCE]
   06  03  5504yy     -- OID identifying an attribute named in
                      -- the Directory standard
                      -- which one is determined by yy
   13  La  xxxxxx     -- [Printable string]
                      -- could be T61 string, with tag 14
   00  00  }2         - end of AVA
   00  00  }1         - end of RDN

   The most likely attributes for an RDN have the following hex values
   for yy.

        CommonName               03
        Country                  06
        Locality                 07
        State/Province           08
        Organisation             0A
        OrganisationUnit         0B

   For non-Directory attributes, the object id name must be substituted
   (thus changing the immediately preceding length)

   If there are multiple attribute value assertions in the RDN, the
   group between {2 and 2} is repeated (with different attributes).
   Order is not significant.

   The encoding of a [Directory] Name for the AP-titles is the RDNs
   (high- order first) within

   30  80  {1        - [SEQUENCE] Name
    -- put the RDN encodings here
   00  00  }1

   An Object Identifier AP-title is encoded as a primitive (see below),
   with the "universal" tag for an object identifier, which is 6. The
   integer AE-qualifier uses the universal tag for an integer, which is
   2.

4.  What has to be sent and received

4.1 Sequence of OSI protocol data units used

   OSI defines its facilities in terms of services but these are
   abstract constructs (they do not have to correspond to procedure
   calls) - the significant thing is the transmission of the resulting
   protocol data unit (PDU). The PDU at each layer carries (as user
   data) the PDU of the layer above. The different layers follow



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


   different conventions for naming the pdus. This section gives an
   overview of the sequence of PDUs exchanged - the details of these are
   given in section 6.

   The requirements of the application are to create a connection
   (strictly an association for the application-layer in OSI, but called
   a connection here), to send and receive data and to close the
   connection.  The PDUs used are thus:

   To create connection:

        First create transport-level connection

        Initiator sends the message defined in 6.1, which is Session
        CONNECT carrying Presentation CONNECT request [CP] carrying
        ACSE A-ASSOCIATE request [AARQ] optionally carrying application
        data.

        Responder replies with the message defined in 6.2, which is
        Session ACCEPT carrying Presentation CONNECT response [CPA]
        carrying ACSE response [AARE] optionally carrying application
        data.

     -  If the responder rejects the attempt, the reply will be Session
        REJECT. This is defined in 6.3, where the REJECT carries no
        user data. A received REJECT may carry Presentation, ACSE and
        application data, although 6.3 shows only how to reject at
        Session level..

   To send/receive data on an connection

        send the message defined in 6.4, which is an empty Session
        GIVE-TOKEN followed by Session S-DATA carrying Presentation P-
        DATA [TD] containing the application data (The GIVE-TOKEN is
        just two octets required by Session for some backwards
        compatibility.)

   To close connection gracefully

        One side sends the message defined in 6.5, which is Session
        FINISH carrying P-RELEASE request carrying A-RELEASE request
        [RLRQ] optionally carrying application data (This side may now
        receive, but not send data.)

        The other side replies with the message defined in 6.6, which
        is Session DISCONNECT carrying P-RELEASE response carrying A-
        RELEASE response [RLRE] optionally carrying application data




Furniss                                                        [Page 11]