draft-guttman-svrloc-rfc2608bis-03.txt

来自「Pegasus is an open-source implementation」· 文本 代码 · 共 791 行 · 第 1/3 页

   Any DA or SA that sees its address in the PR List SHOULD NOT respond
   to the request. PR Lists MUST NOT be used with unicast requests.

   A multicast request message with a PR List SHOULD be retransmitted
   until either: a) no further responses are elicited, b) the PR List
   and the request will not fit into a single datagram, or: c)
   CONFIG_MC_MAX seconds have elapsed.

   A syntax error in a PR List results in a PARSE_ERROR, and the
   response is suppressed because PR Lists are only be used with
   multicast requests.

4.3.4 Service Type

   The Service Type is a string parameter in SrvRqst and SrvReg
   messages. The syntax of the Service Type is:

      service-type       = generic-uri-scheme / service-scheme
      generic-uri-scheme = ALPHA *( alpha / digit / '+' / '-' / '.' )
      service-scheme     = "service:" type ['.' na ] [':' type ]
      type               = 1*(alpha / digit / '+' / '-' )
      na                 = 1*(alpha / digit / '+' / '-' )
                          ; The naming authority field SHOULD have the
                          ; form described in [vendorext]

   Service Types MUST match with case insensitive string comparison.

   WARNING! SPECIAL CASE:  If the "service:" scheme [RFC2609] is used,
   special matching rules apply.

   A service type string which begins with "service:" is followed by
   either one or two "type" fields.

   The first type field after the "service:" scheme MAY have a naming
   authority string associated with it.  If so, the type is considered
   unique.  Example: "service:a" does not match "service:a.93439".  This
   naming authority field allows for vendor extension and is NOT
   RECOMMENDED. [vendorext] The default Naming Authority is IANA. A
   Service Type that is registered with IANA MUST NOT contain a Naming
   Authority string.

   A service type string beginning with "service:" followed by one type
   field will match service type strings of that form, whether they have
   one or two type fields which follow.  Example: "service:a" matches
   "service:a" and "service:a:b".  And: "service:a.1234" matches
   "service:a.1234:b" but it does not match "service:a:b".



Guttman & Kempf         Expires: 3 February 2003               [Page 10]

Internet Draft               SLPv2 Revision                  August 2002


   A syntax error in a Service Type name MUST result in the return of a
   PARSE ERROR to the sending agent, if the request was unicast.

4.3.5 Scope List

   With two exceptions, all requests, service advertisement
   registrations, and service advertisement deregistrations MUST contain
   a Scope List.  SLP messages that fail to contain a Scope list or that
   contain a Scope List having no Scopes for which the receiving agent
   is configured MUST BE either dropped, if the request was multicast,
   or result in a SCOPE_NOT_SUPPORTED error in reply, if the request was
   unicast.

   The two exceptions are SrvRqsts for the DA Service Type and for the
   SA Service Type. These MAY be transmitted without a Scope List if the
   transmitting agent is interested in obtaining a list of all
   configured Scopes supported by the replying DA or SA.

   Scope Lists in SLPv2 are a comma delimited list of scope strings.
   Scope strings have reserved characters which must be expressed as
   escape values if they are to be included in the scope name.

      reserved   = '(' / ')' / ',' / '\' / '!'  / '<' / '=' / '>' /
                  '~' /CTL / ';' / '*' / '+'
      escape-val = '\' HEXDIG HEXDIG

   For example the scope name "ou=sales,o=examplecorp" would have to be
   represented "ou\3Dsales\2Co\3Dexamplecorp" to escape the "=" and ","
   characters in the name.

   If a syntax error in a Scope List or Scope name is encountered, the
   receiving agent MUST return a PARSE ERROR if the request was unicast.

   The default value for the Scope List is the Scope name "DEFAULT".
   Scope configuration rules are described in Section 8.0.

4.3.6 Attribute List

   A service advertisement is often accompanied by Attributes.  A UA
   formulates a service query containing Attributes in order to select
   particular service advertisements.

   A Service Type MAY specify allowable Attributes through a defined
   service template [RFC2609]. The allowable Attributes for such a
   service are defined in the service template. Services that are
   advertised according to a standard template SHOULD register all
   service Attributes required by the standard template. If no service
   template is available for a Service Type, then any Attributes are
   allowed. Support for service templates is optional.

   An Attribute List is a string encoding of the Attributes for a


Guttman & Kempf         Expires: 3 February 2003               [Page 11]

Internet Draft               SLPv2 Revision                  August 2002


   service advertisement.  The following grammar defines the Attribute
   list syntax:

      attr-list  = attribute / attribute ',' attr-list
      attribute  = '(' attr-tag '=' val-list ')' / attr-tag
      val-list   = attr-val / attr-val ',' val-list
      attr-tag   = 1*safe-tag / nonstd-tag
      nonstd-tag = "x-" enum '-' 1*safe-tag
      enum       = 1*DIGIT
                     ; The <enum> field corresponds to an Enterprise
                     ; Number registered with IANA. [IANA] Using this
                     ; prefix avoids collisions in interpretation of
                     ; nonstandard attribute name.
      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, '*' and bad-tag.
      reserved   = '(' / ')' / ',' / '\' / '!'  / '<' / '=' / '>' / '~' / CTL
      escape-val = '\' HEXDIG HEXDIG
      bad-tag    = CR / LF / HTAB / '_'

   An Attribute List MUST be scanned prior to evaluation for all
   occurrences of the escape character '\'.  Reserved characters MUST be
   escaped while other characters MAY be escaped.  All escaped
   characters MUST be restored to their value before attempting string
   matching.  Escaped Opaque values are converted into bytes, not into
   characters.

   The following list contains more detail on the various types of
   Attributes:

      Boolean      A Boolean Attribute MUST have a value list that is
                   one of the Boolean constants "true" or "false". A
                   Boolean value list MUST only have a single value and
                   MUST only be compared with '='.  As with all
                   strings, the Boolean constants are case insensitive.

      Integer      An Integer Attribute MUST have a value list
                   consisting of Integer constants. Integer constants
                   MUST be strings that take the form [-] 1*DIGIT and
                   fall in the range "-2147483648" to "2147483647",
                   that is, the range of 32 bit signed integers.
                   Integer values MUST be compared using integer
                   comparison.

      Opaque       An Opaque Attribute MUST have a value list
                   consisting of opaque values. Opaque values are
                   sequences of bytes.  These MUST be distinguished


Guttman & Kempf         Expires: 3 February 2003               [Page 12]

Internet Draft               SLPv2 Revision                  August 2002


                   from strings since they begin with the sequence
                   "\FF".  Unescaping this sequence results in an
                   illegal UTF-8 encoding, indicating that what follows
                   is a sequence of escaped bytes and not a UTF-8
                   string.  For example, a '0' byte is encoded
                   "\FF\00" and "\ff\00\00\30\39" is a
                   bigendian representation of 12345.  Opaque values
                   MUST only be compared with '='.

      String       All other string values are String type. String
                   values MUST be matched using strict lexical
                   ordering.   Example of string values with
                   escaped characters: "Hello\0a" (Hello with
                   a newline) and "\48\65\6c\6c\6f\0a"
                   (the same string, entirely escaped).  To
                   include reserved characters as string data
                   they must be escaped.  Example "a,b" is "a\40b".
                   Illegal UTF-8 characters MUST NOT be included
                   in Strings, ie. "a\ff" is illegal.

      Keyword      A Keyword Attribute has only a tag. A Keyword
                   Attribute MUST be designated by attr-tag in the
                   Attribute List, and it MUST have no values.

   Syntax errors in the Attribute List MUST result in a PARSE ERROR,
   which is returned if the request was unicast.

   When values are advertised by a SA or are registered in a DA, they
   MUST take on implicit typing rules for matching incoming requests,
   according to the types described above. Stored value types in
   Attribute Lists MUST be consistent, i.e., x=4,true,sue,\ff\00\00 is
   in error. Inconsistent stored value types in a SrvReg MUST result in
   a PARSE ERROR returned to the SA.

   A DA MUST consolidate multiple instances of the same Attribute within
   an Attribute List before storing and an SA MUST consolidate multiple
   instances before sending the Attribute in an AttrRply. For example,
   if the Attribute List received by a DA is:

      "(x=5,6,7),(y=a,b,c),(x=6,7,8)"

   one Attribute, "x", is stored having value list "5,6,7,8".

   Embedded blanks in Attribute tags and value lists MUST be processed
   as part of the tags or values in which they appear, embedded blanks
   MUST NOT be ignored. For example, in the Attribute List "(attra =
   -345)", the Attribute tag is "attra " and the value is the String "
   -345". The value is not an Integer due to the embedded blank.





Guttman & Kempf         Expires: 3 February 2003               [Page 13]

Internet Draft               SLPv2 Revision                  August 2002


4.3.7 Search Filter

   A SrvRqst message MAY include a LDAPv3 Search Filter [RFC2254], with
   certain restrictions. RFC 2254 describes the syntax of LDAPv3 Search
   Filters.

   A DA MUST accept any LDAPv3 query, excluding those with extensible
   matching rules.  A SA MAY accept only simple queries; otherwise, it
   MUST accept service queries as a DA would.  A UA SHOULD send only
   simple queries.

   The syntax for a simple query is:

         simple-query  =  conjoin / term
         conjoin       =  "(&" term-list ')'
         term-list     =  term term-list / term
         term          =  '(' tag querytype item ')' / '(' tag "=*)"
                          ; The "=*" term tests if the Attribute is
                          ; present.
         tag           =  1*tag-safe
         querytype     =  '='  / "~=" / ">=" / "<="
                          ; These correspond to equal, approx,
                          ; greater than or equal, less than or
                          ; equal.
         item          =  value / substring
                          ; Only substring matching is supported.
         value         =  1*val-safe
         substring     =  [ value ] any [ value ]
         any           =  '*' *(value "*")
         tag-unsafe    =  val-unsafe / CR / LF / HTAB / '_'
         tag-safe      =  ; All UTF-8 characters are included except
                          ; those in tag-unsafe.  Tag-unsafe must be
                          ; escaped.
         val-unsafe    =  '(' / ')' / ',' / '