Subject: about string escaping in SLPv2

From: [email-masked]
Date: Thu, 24 Dec 1998 18:06:38 +0900 (JST)

I have some questions about SLPv2 string processing.

1.
  I think escaping for the strings in  both attribute-tags and attribure-values 
  is only used for eliminating filter-parsing ambiguities, especially 
  attributes used in LDAPv3 filters as predicates-field.

  According to the ABNF of attr-list's syntax definition ( "draft-ietf-svrloc-protocol-v2-11.txt", page 10 ), I think escaping is used only for attr-val and attr-tag , and must not used for attr-val-list.

  So, unescaping should be done after decomposition of lists and applies to the each atomic values. 

  But in the "draft-ietf-svrloc-protocol-v2-11.txt", page 10,line 17,describes
  
>  The <attr-list>, if present, MUST be scanned prior to evaluation for
>  all occurrences of the escape character `\'.  

  and in the Interoperability test plan ,"iop5.v2.txt", 
  
>   register service
>    url=service:esc://localhost
>    lang=en
>    scope=default
>    attrs=(x\09\09x=red\2cwhite\2cblue)

those above shows to allow escaping for the attr-val-list,and the orders that firstly unescaping then decomposite the lists.

If such a processing  order is applies to the escaped strings "\3ctag-1\3e" as an attr-tag value in the filters, causes filter parsing ambiguities.

2.
   In the Interoperability test plan ,"iop5.v2.txt", I think following opaque datas and escaped datas are all probably typographical errors ( each duplicated backslashes must be single back slash).  Is it true ?

 (d= \\ff\\00,\\ff\\01,\\ff\\02, \\ff\\03)
 (\\09 b \\0A= \\09\\09 true \\09\\09)
 ( d = \\ff\\03 )
 (op=\\ff\\00,\\ff\\01) 

3.

   In the "draft-ietf-svrloc-api-07.txt", page 4,section2, described bellow.

>  Both files are defined in the UTF8 character set

   But according to the configuration file's ABNF Grammer , both tagchar and stringchar are defined in only  US-ASCII range .
   I think it is neccessary to modify the configuration file's ABNF grammer.

>prop          =  1*tagchar
>value         =  int / bool /
>                       "(" value-list ")" / string
>tagchar       =  DIGIT / ALPHA / tother / escape
> tother        =  %x21-%x2d / %x2f /
>                       %x3a / %x3c-%x40 /
>                       %x5b-%x60 / %7b-%7e
>                       ; i.e., all characters except `.',
>                       ; and `='.

> string        =  1*stringchar
> stringchar    =  DIGIT / ALPHA / sother / escape
> sother        =  %x21-%x27 / %x2a-%x2b /
>                       %x2d-%x2f / %x3a-%x40 /
>                       %x5b-%x60 / %7b-%7e
>                       ; i.e., all characters except `,',
>                       ; `(', and `)' except for scope names.

       --------------------------------------------------

  Telecommunications Advancements Organization Japan
  Kobe Network Control Resarch Center
  Yoichiro Kashu  [email-masked]
                  phone 078-991-1611

---

From: Erik Guttman <[email-masked]>
Date: Thu, 24 Dec 1998 12:09:55 +0100 (MET)

Kashu-san,

Thank you for the comments on the SLPv2 document and the interoperability
test plan.

>   According to the ABNF of attr-list's syntax definition (
> "draft-ietf-svrloc-protocol-v2-11.txt", page 10 ), I think escaping is used
> only for attr-val and attr-tag , and must not used for attr-val-list.
> 

The confusion arises, I believe, because you are misinterpreting my test.

The idea here is to have a value which is literally "red,white,blue" but
is *not* three distinct values.  So, the rule on page 10 tells us we have
to unescape the escaped values before comparison:

   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.

Suppose we registered "(x\09\09x=red\2cwhite\2cblue)" as the attributes of
service S and then issued a service request with the predicate: 
"(x\09\09x=red)".  This predicate would not match, since the value of the
attribute "x\09\09x" is "red,white,blue".  That is, the value is not 
"red", "white" and "blue".  If that were the intention, there would be
no reason to escape the commas.

> 
> those above shows to allow escaping for the attr-val-list,and the orders
> that firstly unescaping then decomposite the lists.
> 
> If such a processing  order is applies to the escaped strings "\3ctag-1\3e"
> as an attr-tag value in the filters, causes filter parsing ambiguities.
> 

Perhaps clarification is necessary.  Attribute lists, tag lists and filters
are processed without unescaping anything.  Only after these constructs have
been broken down into tags and possibly values are the unescaping rules applied
to transform the strings.  This allows reserved characters (used by the attr
list, tag list and filter syntax itself) to be included as data in  the
attribute tags and values.

> 2.
>    In the Interoperability test plan ,"iop5.v2.txt", I think following
> opaque datas and escaped datas are all probably typographical errors ( each
> duplicated backslashes must be single back slash).  Is it true ?
> 

You are absolutely right.  I cut and pasted this from test code.  
Apologies.

>    But according to the configuration file's ABNF Grammer , both tagchar and
> stringchar are defined in only  US-ASCII range .

The reason why we did that was to have a config file which was
ASCII readable and writable.  I guess that makes little sense.
It would be aweful to have to transcribe non-ASCII unicode values
into UTF-8 then transform the UTF-8 into our escape notation.

It is clear what we need to do is simply specify UTF-8.  If there
are no good UTF-8 'visual editors' yet, that's no reason to require
folks to hand edit escaped UTF-8 (which I've done and its not any
fun.)

So:  I agree with you and we should modify this in the API draft.

Thanks again,

Erik Guttman

---

From: Yoichiro Kashu <[email-masked]>
Date: Thu, 24 Dec 1998 22:37:03 +0900

Thank you for your kind response.

    I had misinterpreted the intention of the test plane, especially the case , as
in a predicate
    strings "(x\09\09x=red\2cwhite\2cblue)" .

    I agree with your explanations.

    And  I think my confusions about  processing priority among unescaping and
breaking down a list was
    comes from the word  <attr-list> in the following description.

 > all occurrences of the escape character `\'.

   I think that it is preferable to substitute the word <attr-list> to <attr-val>
or <attr-tag>.

   I have a new question about your explanations  bellow

 >  into UTF-8 then transform the UTF-8 into our escape notation.

  Although we cannot visualize and edit the texts which encoded in UTF-8, we need
not any escaping
  for UTF-8 characters.

  Probably my knowledges about UTF-8 is short to understand your explanations, I
think an
  escape notations which is defines in a ABNF of configuration file , is  used for
reserved
  characters( commented at last line of ABNF) , not for UTF-8.

Thanks again.
 -----------------------------------------------------------------------------