[cifs-protocol] [MS-DTYP] Conditional ACE attr-name2 whitespace escaping

[Douglas Bagnall]

hi Dochelp,

In MS-DTYP 2.5.1.1, attr-name2 is defined as containing attr-char2, 
which is described thus in the text:

> attr-char2: A character valid for use in an attribute name in @Prefixed form. Valid characters include
> all ASCII and UNICODE characters of the range 0x0-0xFFFF. Characters MAY be encoded either as
> literals or be encoded with a five-character sequence %XXXX, where XXXX are hexadecimal digits
> that represent the corresponding 16-bit Unicode value of the character with the following
> exceptions:
> 1. The following characters: "!", "&", "(", ")", ">", "<", "=", "|", "%", SP (space) and DQUOTE (as
> specified in [RFC5234]) MUST be encoded in the preceding five-character sequence.
> 2. The following characters MUST be encoded as literals: "#", "$", "'", "*", "+", "-", ".", "/", ":",
> ";", "?", "@", "[", "\", "]", "^", "_", "`", "{", "}", "~" and any characters in the ASCII ranges
> 0x41-0x5A (A-Z), 0x61-0x7A (a-z) and 0x30-0x39 (0-9.)

Note that SP, the space character '\x20' MUST be escaped, but other 
whitespace can be literal.

Now with certain operators:

> contains-op = attr-name wspace ("Contains" / "Not_Contains") wspace (attr-name2 / value-
> array)
> anyof-op = attr-name wspace ("Any_of" / "Not_Any_of") wspace (attr-name2 / value-array)

the attribute name is separated from "Contains" by *any* whitespace.

So considering a conditional ACE like this:

  (@Device.this\tattribute\tContains\tthe\tword\Contains Contains "fish")

where the "\t" represents a tab (obviously carriage return et. al. would 
do as well), does the parser *really* manage to find the right 
"Contains" to split on, or should the other whitespace be listed as 
needing escaping? Or is the rule more subtle, like, "you can get away 
with it when it's not confusing"?

cheers,
Douglas