From user-return-3363-archive-asf-public=cust-asf.ponee.io@guacamole.apache.org Sun Feb 25 02:58:03 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id B4A19180656 for ; Sun, 25 Feb 2018 02:58:02 +0100 (CET) Received: (qmail 34048 invoked by uid 500); 25 Feb 2018 01:58:01 -0000 Mailing-List: contact user-help@guacamole.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@guacamole.apache.org Delivered-To: mailing list user@guacamole.apache.org Received: (qmail 34039 invoked by uid 99); 25 Feb 2018 01:58:01 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 25 Feb 2018 01:58:01 +0000 Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 3EB4B1945 for ; Sun, 25 Feb 2018 01:57:59 +0000 (UTC) Received: by mail-lf0-f45.google.com with SMTP id 70so17480762lfw.2 for ; Sat, 24 Feb 2018 17:57:59 -0800 (PST) X-Gm-Message-State: APf1xPCr4X/9Sls+MBlJgBNPw+ocK4MAxSo0ggzzHLYHS18VZN5nwc3o B9HE/k5VRLldTgCuZuBA3u19FCfu6QNMvCYoWi0= X-Google-Smtp-Source: AG47ELtNNGZGhrLrsNRSWrNdkKhnrAYLHJOXlX6CImrQsqCID97D83Rw7N2a2bEN2veGAOQPMqTd1jJqlf/qinU2XE0= X-Received: by 10.25.227.71 with SMTP id c7mr4272831lfk.5.1519523878142; Sat, 24 Feb 2018 17:57:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.202.89 with HTTP; Sat, 24 Feb 2018 17:57:57 -0800 (PST) In-Reply-To: References: From: Nick Couchman Date: Sat, 24 Feb 2018 20:57:57 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ] To: user@guacamole.apache.org Content-Type: multipart/alternative; boundary="94eb2c1cc0fcfc0b0c0565ffb8a5" --94eb2c1cc0fcfc0b0c0565ffb8a5 Content-Type: text/plain; charset="UTF-8" > > >> The spec does call for UTF-16, but you present an interesting and > plausible theory. If specifying non-UTF-16 does work, then one of the > following must be true: > > * UTF-16 should indeed be used, but not across the board in the case of > the drive, and we are erroneously using UTF-16 in some of the cases where > it is not allowed. > > So, was reading the spec, and there's definitely some degree of ambiguity about this. From the MS-RDPEFS spec [1]: "...If the client supports DRIVE_CAPABILITY_VERSION_02 in the Drive Capability Set, then the full name MUST also be specified in the *DeviceData* field, as a null-terminated Unicode string . ..." If you click on the link to "Unicode string" [2], the following definition is provided: "*Unicode string*: A Unicode 8-bit string is an ordered sequence of 8-bit units, a Unicode 16-bit string is an ordered sequence of 16-bit code units, and a Unicode 32-bit string is an ordered sequence of 32-bit code units. In some cases, it could be acceptable not to terminate with a terminating null character. Unless otherwise specified, all Unicode strings follow the UTF-16LE encoding scheme with no Byte Order Mark (BOM)." So, according to Microsoft's documentation, it could either be 8-bit, 16-bit, or 32-bit, and should be 16-bit if not specified, but maybe they forgot to specify?! Unfortunately none of their examples actually have any of that data filled in, so it's hard to know, and they themselves say it's one of the three. -Nick [1] - https://msdn.microsoft.com/en-us/library/cc241357.aspx [2] - https://msdn.microsoft.com/en-us/library/cc241307.aspx#gt_b069acb4-e364-453e-ac83-42d469bb339e --94eb2c1cc0fcfc0b0c0565ffb8a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The spec does call for = UTF-16, but you present an interesting and plausible theory. If specifying = non-UTF-16 does work, then one of the following must be true:
* UTF-16 should indeed be used, but not across the board in the= case of the drive, and we are erroneously using UTF-16 in some of the case= s where it is not allowed.


So, was reading the spec, and there's definitely= some degree of ambiguity about this.=C2=A0 From the MS-RDPEFS spec [1]:

"...If the client supports DRIVE_CAPABILITY_VERSION_02 in the Driv= e Capability Set, then the full name MUST also be specified in the=C2= =A0DeviceData=C2=A0field, as a null-termin= ated=C2=A0Unicode string.=C2=A0..."

If you click on the link to "Unicode string&= quot; [2], the following definition is provided:

"Unicode string: A Unicode 8-bit string is an ordered sequence = of 8-bit units, a Unicode 16-bit string is an ordered sequence of 16-bit co= de units, and a Unicode 32-bit string is an ordered sequence of 32-bit code= units. In some cases, it could be acceptable not to terminate with a termi= nating null character. Unless otherwise specified, all=C2=A0Unicode stringsfollow the UTF-16LE encoding scheme with no Byte Ord= er Mark (BOM)."

So, acco= rding to Microsoft's documentation, it could either be 8-bit, 16-bit, o= r 32-bit, and should be 16-bit if not specified, but maybe they forgot to s= pecify?!=C2=A0 Unfortunately none of their examples actually have any of th= at data filled in, so it's hard to know, and they themselves say it'= ;s one of the three.

<Shrug>
--94eb2c1cc0fcfc0b0c0565ffb8a5--