rfc2608.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,407 行 · 第 1/5 页

   Non-standard attribute names SHOULD begin with "x-", because no
   standard attribute name will ever have those initial characters.

   An attribute list is a string encoding of the attributes of a
   service.  The following ABNF [11] grammar defines attribute lists:

   attr-list = attribute / attribute `,' attr-list
   attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag
   attr-val-list = attr-val / attr-val `,' attr-val-list
   attr-tag = 1*safe-tag
   attr-val = intval / strval / boolval / opaque
   intval = [-]1*DIGIT
   strval = 1*safe-val
   boolval = "true" / "false"
   opaque = "\FF" 1*escape-val
   safe-val = ; Any character except reserved.
   safe-tag = ; Any character except reserved, star and bad-tag.
   reserved = `(' / `)' / `,' / `\' / `!'  / `<' / `=' / `>' / `~' / CTL
   escape-val = `\' HEXDIG HEXDIG
   bad-tag = CR / LF / HTAB / `_'
    star = `*'

   The <attr-list>, if present, MUST be scanned prior to evaluation for
   all occurrences of the escape character `\'.  Reserved characters
   MUST be escaped (other characters MUST NOT be escaped).  All escaped
   characters must be restored to their value before attempting string
   matching.  For Opaque values, escaped characters are not converted -
   they are interpreted as bytes.

      Boolean      Strings which have the form "true" or "false" can
                   only take one value and may only be compared with
                   '='.  Booleans are case insensitive when compared.

      Integer      Strings which take the form [-] 1*<digit> and fall
                   in the range "-2147483648" to "2147483647" are
                   considered to be Integers.  These are compared using
                   integer comparison.

      String       All other Strings are matched using strict lexical
                   ordering (see Section 6.4).

      Opaque       Opaque values are sequences of bytes.  These are
                   distinguished from Strings since they begin with
                   the sequence "\FF".  This, unescaped, is an illegal
                   UTF-8 encoding, indicating that what follows is a
                   sequence of bytes expressed in escape notation which
                   constitute the binary value.  For example, a '0' byte
                   is encoded "\FF\00".



Guttman, et al.             Standards Track                    [Page 11]

RFC 2608         Service Location Protocol, Version 2          June 1999


   A string which contains escaped values other than from the reserved
   set of characters is illegal.  If such a string is included in an
   <attr-list>, <tag-list> or search filter, the SA or DA which receives
   it MUST return a PARSE_ERROR to the message.

   A keyword has only an <attr-tag>, and no values.  Attributes can have
   one or multiple values.  All values are expressed as strings.

   When values have been advertised by a SA or are registered in a DA,
   they can take on implicit typing rules for matching incoming
   requests.

   Stored values must be consistent, i.e., x=4,true,sue,\ff\00\00 is
   disallowed.  A DA or SA receiving such an <attr-list> MUST return an
   INVALID_REGISTRATION error.

6. Required Features

   This section defines the minimal implementation requirements for SAs
   and UAs as well as their interaction with DAs.  A DA is not required
   for SLP to function, but if it is present, the UA and SA MUST
   interact with it as defined below.

   A minimal implementation may consist of either a UA or SA or both.
   The only required features of a UA are that it can issue SrvRqsts
   according to the rules below and interpret DAAdverts, SAAdverts and
   SrvRply messages.  The UA MUST issue requests to DAs as they are
   discovered.  An SA MUST reply to appropriate SrvRqsts with SrvRply or
   SAAdvert messages.  The SA MUST also register with DAs as they are
   discovered.

   UAs perform discovery by issuing Service Request messages.  SrvRqst
   messages are issued, using UDP, following these prioritized rules:

    1. A UA issues a request to a DA which it has been configured with
       by DHCP.

    2. A UA issues requests to DAs which it has been statically
       configured with.

    3. UA uses multicast/convergence SrvRqsts to discover DAs, then uses
       that set of DAs.  A UA that does not know of any DAs SHOULD retry
       DA discovery, increasing the waiting interval between subsequent
       attempts exponentially (doubling the wait interval each time.)
       The recommended minimum waiting interval is CONFIG_DA_FIND
       seconds.





Guttman, et al.             Standards Track                    [Page 12]

RFC 2608         Service Location Protocol, Version 2          June 1999


    4. A UA with no knowledge of DAs sends requests using multicast
       convergence to SAs.  SAs unicast replies to UAs according to the
       multicast convergence algorithm.

   UAs and SAs are configured with a list of scopes to use according to
   these prioritized rules:

    1. With DHCP.

    2. With static configuration.  The static configuration may be
       explicitly set to NO SCOPE for UAs, if the User Selectable Scope
       model is used.  See section 11.2.

    3. In the absence of configuration, the agent's scope is "DEFAULT".

   A UA MUST issue requests with one or more of the scopes it has been
   configured to use.

   A UA which has been statically configured with NO SCOPE LIST will use
   DA or SA discovery to determine its scope list dynamically.  In this
   case it uses an empty scope list to discover DAs and possibly SAs.
   Then it uses the scope list it obtains from DAAdverts and possibly
   SAAdverts in subsequent requests.

   The SA MUST register all its services with any DA it discovers, if
   the DA advertises any of the scopes it has been configured with.  A
   SA obtains information about DAs as a UA does.  In addition, the SA
   MUST listen for multicast unsolicited DAAdverts.  The SA registers by
   sending SrvReg messages to DAs, which reply with SrvReg messages to
   indicate success.  SAs register in ALL the scopes they were
   configured to use.

6.1. Use of Ports, UDP, and Multicast

   DAs MUST accept unicast requests and multicast directory agent
   discovery service requests (for the service type "service:directory-
   agent").

   SAs MUST accept multicast requests and unicast requests both.  The SA
   can distinguish between them by whether the REQUEST MCAST flag is set
   in the SLP Message header.

   The Service Location Protocol uses multicast for discovering DAs and
   for issuing requests to SAs by default.

   The reserved listening port for SLP is 427.  This is the destination
   port for all SLP messages.  SLP messages MAY be transmitted on an
   ephemeral port.  Replies and acknowledgements are sent to the port



Guttman, et al.             Standards Track                    [Page 13]

RFC 2608         Service Location Protocol, Version 2          June 1999


   from which the request was issued.  The default maximum transmission
   unit for UDP messages is 1400 bytes excluding UDP and other headers.

   If a SLP message does not fit into a UDP datagram it MUST be
   truncated to fit, and the OVERFLOW flag is set in the reply message.
   A UA which receives a truncated message MAY open a TCP connection
   (see section 6.2) with the DA or SA and retransmit the request, using
   the same XID. It MAY also attempt to make use of the truncated reply
   or reformulate a more restrictive request which will result in a
   smaller reply.

   SLP Requests messages are multicast to The Administratively Scoped
   SLP Multicast [17] address, which is 239.255.255.253.  The default
   TTL to use for multicast is 255.

   In isolated networks, broadcasts will work in place of multicast.  To
   that end, SAs SHOULD and DAs MUST listen for broadcast Service
   Location messages at port 427.  This allows UAs which do not support
   multicast the use of Service Location on isolated networks.

   Setting multicast TTL to less than 255 (the default) limits the range
   of SLP discovery in a network, and localizes service information in
   the network.

6.2. Use of TCP

   A SrvReg or SrvDeReg may be too large to fit into a datagram.  To
   send such large SLP messages, a TCP (unicast) connection MUST be
   established.

   To avoid the need to implement TCP, one MUST insure that:

    -  UAs never issue requests larger than the Path MTU. SAs can omit
       TCP support only if they never have to receive unicast requests
       longer than the path MTU.

    -  UAs can accept replies with the 'OVERFLOW' flag set, and make use
       of the first result included, or reformulate the request.

    -  Ensure that a SA can send a SrvRply, SrvReg, or SrvDeReg in
       a single datagram.  This means limiting the size of URLs,
       the number of attributes and the number of authenticators
       transmitted.

   DAs MUST be able to respond to UDP and TCP requests, as well as
   multicast DA Discovery SrvRqsts.  SAs MUST be able to respond to TCP
   unless the SA will NEVER receive a request or send a reply which will
   exceed a datagram in size (e.g., some embedded systems).



Guttman, et al.             Standards Track                    [Page 14]

RFC 2608         Service Location Protocol, Version 2          June 1999


   A TCP connection MAY be used for a single SLP transaction, or for
   multiple transactions.  Since there are length fields in the message
   headers, SLP Agents can send multiple requests along a connection and
   read the return stream for acknowledgments and replies.

   The initiating agent SHOULD close the TCP connection.  The DA SHOULD
   wait at least CONFIG_CLOSE_CONN seconds before closing an idle
   connection.  DAs and SAs SHOULD close an idle TCP connection after
   CONFIG_CLOSE_CONN seconds to ensure robust operation, even when the
   initiating agent neglects to close it.  See Section 13 for timing
   rules.

6.3. Retransmission of SLP messages

   Requests which fail to elicit a response are retransmitted.  The
   initial retransmission occurs after a CONFIG_RETRY wait period.
   Retransmissions MUST be made with exponentially increasing wait
   intervals (doubling the wait each time).  This applies to unicast as
   well as multicast SLP requests.

   Unicast requests to a DA or SA should be retransmitted until either a
   response (which might be an error) has been obtained, or for
   CONFIG_RETRY_MAX seconds.

   Multicast requests SHOULD be reissued over CONFIG_MC_MAX seconds
   until a result has been obtained.  UAs need only wait till they
   obtain the first reply which matches their request.  That is,
   retransmission is not required if the requesting agent is prepared to
   use the 'first reply' instead of 'as many replies as possible within
   a bounded time interval.'

   When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast,
   they contain a <PRList> of previous responders.  Initially the
   <PRList> is empty.  When these requests are unicast, the <PRList> is
   always empty.

   Any DA or SA which sees its address in the <PRList> MUST NOT respond
   to the request.

   The message SHOULD be retransmitted until the <PRList> causes no
   further responses to be elicited or the previous responder list and
   the request will not fit into a single datagram or until
   CONFIG_MC_MAX seconds elapse.

   UAs which retransmit a request use the same XID. This allows a DA or
   SA to cache its reply to the original request and then send it again,
   should a duplicate request arrive.  This cached information should
   only be held very briefly.  XIDs SHOULD be randomly chosen to avoid



Guttman, et al.             Standards Track                    [Page 15]

RFC 2608         Service Location Protocol, Version 2          June 1999