[cifs-protocol] [EXTERNAL] Re: [MS-DTYP] Conditional ACE attr-name2 whitespace escaping - TrackingID#2303010040009037

[Douglas Bagnall]

Right, I looked again, and now I am confused again about 0x0000-0x001f 
(a.k.a. the control characters). Are they allowed or not, and in which form?
cheers,

Douglas

On 5/04/23 17:07, Douglas Bagnall via cifs-protocol wrote:
> hi Kristian,
> 
> Well I only ever write to you in a state of confusion.
> 
> Ultimately the question I care about is this one:
> 
>>> So my question I guess broadens into which characters actually
>>> MUST be escaped and which MUST be literal.
> 
> Which, yes, I think boils down to the range 0x0001-0x07f, or parts of 
> it. Actually really just the comma.
> 
> My current understanding is there are four classes of character:
> 
> 1. Forbidden in any form: 0x0000.
> 
> 2. Allowed in unescaped form only:
>     the ASCII numbers and letters [A-Za-z0-9] and
>     "#", "$", "'", "*", "+", "-", ".", "/", ":", ";", "?", "@",
>     "[", "\", "]", "^", "_", "`", "{", "}", "~".
> 
> 3. Allowed in escaped form only:
>      "!", "&", "(", ")", ">", "<", "=", "|", "%", space and DQUOTE
> 
> 4. Allowed in either form:
>     Anything 0x007f and over, anything 0x001f and below, and ",".
> 
> Are these correct? Is it true that the comma is special?
> 
> Douglas
> 
> 
> On 30/03/23 06:36, Kristian Smith wrote:
>> Hi Douglas,
>>
>> My apologies on the delay on your ABNF asks. Looking at this question, 
>> the way lit_char is described is indeed confusing.
>>
>> Specifically:
>> %x0080-FFFF / ( "%" 4HEXDIG); 4HEXDIG can have any value except 0000 
>> (NULL)
>>
>> I believe your primary question here is "what about 0x0001-0x080"? If 
>> I find that those are all accepted for lit_char, would that answer 
>> your question?
>>
>> Thanks again for your patience.
>> -Kristian
>>
>> Kristian Smith
>>
>> Support Escalation Engineer
>>
>> Microsoft Azure DevOps &
>>
>> Windows Open Spec Protocols
>>
>> Office: (425) 421-4442
>>
>> kristian.smith at microsoft.com<mailto:kristian.smith at microsoft.com>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
>> *Sent:* Tuesday, February 28, 2023 7:31 PM
>> *To:* cifs-protocol at lists.samba.org <cifs-protocol at lists.samba.org>; 
>> Interoperability Documentation Help <dochelp at microsoft.com>
>> *Subject:* [EXTERNAL] Re: [cifs-protocol] [MS-DTYP] Conditional ACE 
>> attr-name2 whitespace escaping
>> On 1/03/23 16:18, Douglas Bagnall via cifs-protocol wrote:
>>> 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.)
>>
>> Okay, I see the definition in the ABNF is quite a bit different:
>>
>>> attr-char2 = attr-char1 / lit-char
>>> attr-char1 = 1*(ALPHA / DIGIT / ":" / "." / "/" / "_")
>>> lit-char = "#" / "$" / "'" / "*" / "+" / "-" / "." / "/" / ":" / ";" 
>>> / "?" / "@" / "[" / "\"
>>>   / "]" / "^" / "_" / "`" / "{" / "}" / "~" / %x0080-FFFF / ( "%" 
>>> 4HEXDIG) ; 4HEXDIG can have any value except 0000 (NULL)
>>
>> where the valid literal characters are more constrained, and seem to
>> allow no ASCII control characters at all. Also no \u0000, which the text
>> explicitly allows.
>>
>> So my question I guess broadens into which characters actually
>> MUST be escaped and which MUST be literal.
>>
>> Douglas
>>
> 
> 
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol at lists.samba.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol