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

Wed Apr 5 21:08:27 UTC 2023

Hi Douglas,

Thanks for getting back to me with the extra detail. I met with Obaid today and debriefed him regarding your current open asks.

He will be taking over and working them to resolution. Thank you for your patience while we continue to research the questions.

Regards,
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, April 4, 2023 10:16 PM
To: Kristian Smith <Kristian.Smith at microsoft.com>; cifs-protocol at lists.samba.org <cifs-protocol at lists.samba.org>
Cc: Microsoft Support <supportmail at microsoft.com>
Subject: Re: [cifs-protocol] [EXTERNAL] Re: [MS-DTYP] Conditional ACE attr-name2 whitespace escaping - TrackingID#2303010040009037

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.samba.org%2Fmailman%2Flistinfo%2Fcifs-protocol&data=05%7C01%7CKristian.Smith%40microsoft.com%7C3d7598b4f98c4d8e04e808db3594e5b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638162685871566849%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yZCmWUtX7OYUCYcu35VX5RMVXwoUWWnm5mJcqSAa2E8%3D&reserved=0<https://lists.samba.org/mailman/listinfo/cifs-protocol>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20230405/fe97f20b/attachment.htm>