RE: [Uri-review] Request for review
Martin Duerst <duerst@it.aoyama.ac.jp> Tue, 23 May 2006 03:14 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiNLu-0005rR-Sc; Mon, 22 May 2006 23:14:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiNLs-0005pi-M0 for uri-review@ietf.org; Mon, 22 May 2006 23:14:32 -0400
Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiNLq-0005ZA-1A for uri-review@ietf.org; Mon, 22 May 2006 23:14:32 -0400
Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k4N3EMhv021850; Tue, 23 May 2006 12:14:22 +0900 (JST)
Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 5d19_3b76a9a6_ea0a_11da_870d_0014221fa3c9; Tue, 23 May 2006 12:14:22 +0900
Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4N3C5ep021007; Tue, 23 May 2006 12:12:47 +0900
Message-Id: <6.0.0.20.2.20060523114617.0860fa00@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Tue, 23 May 2006 12:03:32 +0900
To: Andrey Shur <andreysh@exchange.microsoft.com>, Mark Baker <distobj@acm.org>
From: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: RE: [Uri-review] Request for review
In-Reply-To: <1D4A05136773CF4DB373F6FE4E103150110EEE14@df-pug-msg.exchan ge.corp.microsoft.com>
References: <c70bc85d0605221313o5eb4a19chc35dadfe7b4a415b@mail.gmail.com> <1D4A05136773CF4DB373F6FE4E103150110EEE14@df-pug-msg.exchange.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: "John Calhoon (LCA)" <john.calhoon@microsoft.com>, Ted Hardie <hardie@qualcomm.com>, "uri-review@ietf.org" <uri-review@ietf.org>, Dunietz <jerryd@windows.microsoft.com>, Gregg Brown <greggb@microsoft.com>, Jerry@scmailgw1.scop.aoyama.ac.jp
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
Errors-To: uri-review-bounces@ietf.org
Hello Andrey, At 11:08 06/05/23, Andrey Shur wrote: >Mark, > >Thank you for the question. I can see two parts of it that should be answered: > >First, why do we consider "any relative reference"? Actually we expect >users of the packaging technology to store manifold content in the package parts. Of course. >Certain kinds of the content may hold relative references. Yes of course. But you don't have any guarantee that the content referenced will be part of the package. So if a user wants to create a 'self-contained' (meaning no external relative references) package, either the user (manually, or with dedicated scripts,...) or the packaging software has to check all the references anyway. Such a check is only marginally simplified by the fact that there is a way to rewrite these relative references so that any in-package relative reference can start with a single slash, and out-of package relative refences cannot be converted. >We don't want to limit our customers to a particular form of relative >references. If you want to make use of the specific properties of your scheme, you have to rewrite relative references anyhow, in which case it doesn't make much of a difference. Let's say the user uses something like ../../foo.ext. If this is in-package, you can leave it as that. If it is out-of-package, and you want to restrict such links, you have to raise an error (or do something else according to user preferences). Let's say the user uses something like /path/foo.ext. Again, this could be in-package or out of package. You have to check, and if necessary rewrite it. >Second, why do we have a goal to "keep relative references within the >package"? This is all about security. An application performing regular >(default) resolution of relative references should not access resources >outside of the package. But the syntax you came up with doesn't guarantee this, as you showed with the ../../../foo.ext example. Trying to get security with the syntax, when you actually don't have that security and therefore need to check things anyway on the receiving end and/or on the production end doesn't make much sense to me. Also, the additional potential security threads created by an additional escaping layer should be considered. >If an application needs to access external resources, it must be >explicitly defined in the content by specifying an appropriate base Uri So basically all the security precautions can be circumvented by using a base URI? Again, security has to be checked on resolution. Trying to build it into the syntax doesn't work. >or by using network-path form of the relative reference. Using a network-path reference means to use the same scheme as used previously, which means the pack: scheme. As said in RFC 3986, network-path references are rare anyway. You don't mention absolute URIs. Are they allowed or not? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Uri-review mailing list Uri-review@ietf.org https://www1.ietf.org/mailman/listinfo/uri-review
- [Uri-review] Request for review Andrey Shur
- Re: [Uri-review] Request for review Mark Baker
- Re: [Uri-review] Request for review Daniel R. Tobias
- RE: [Uri-review] Request for review Gregg Brown
- Re: [Uri-review] Request for review Mark Baker
- RE: [Uri-review] Request for review Andrey Shur
- RE: [Uri-review] Request for review Andrey Shur
- Re: [Uri-review] Request for review Mark Baker
- RE: [Uri-review] Request for review Andrey Shur
- RE: [Uri-review] Request for review Martin Duerst
- RE: [Uri-review] Request for review Andrey Shur
- Re: [Uri-review] Request for review Mark Baker
- RE: [Uri-review] Request for review Martin Duerst
- RE: [Uri-review] Request for review Jerry Dunietz
- Re: [Uri-review] Request for review Mark Baker
- RE: [Uri-review] Request for review Jerry Dunietz
- Re: [Uri-review] Request for review Mark Baker
- RE: [Uri-review] Request for review Jerry Dunietz
- Re: [Uri-review] Request for review Mark Baker
- RE: [Uri-review] Request for review Andrey Shur
- Re: [Uri-review] Request for review Mark Baker
- RE: [Uri-review] Request for review Andrey Shur
- RE: [Uri-review] Request for review Andrey Shur
- Re: [Uri-review] Request for review Martin Duerst
- Re: [Uri-review] Request for review Mark Baker
- RE: [Uri-review] Request for review Andrey Shur
- Re: [Uri-review] Request for review Mark Baker
- RE: [Uri-review] Request for review Andrey Shur
- Re: [Uri-review] Request for review Mark Baker
- RE: [Uri-review] Request for review Andrey Shur
- Re: [Uri-review] Request for review Mark Baker
- RE: [Uri-review] Request for review Andrey Shur
- Re: [Uri-review] Request for review Roy T. Fielding
- RE: [Uri-review] Request for review Andrey Shur
- Re: [Uri-review] Request for review Roy T. Fielding
- Re: [Uri-review] Request for review Roy T. Fielding
- RE: [Uri-review] Request for review Martin Duerst
- RE: [Uri-review] Request for review Andrey Shur
- RE: [Uri-review] Request for review Andrey Shur
- [Uri-review] Request for review Frank Ellermann
- Re: [Uri-review] Request for review Mykyta Yevstifeyev
- Re: [Uri-review] Request for review Bjoern Hoehrmann
- Re: [Uri-review] Request for review Frank Ellermann
- Re: [Uri-review] Request for review Bjoern Hoehrmann
- Re: [Uri-review] Request for review Frank Ellermann