authority component of another URI, but the concern described above

trumps it so I'll refrain from getting into that for now.

Cheers,

BTW, thanks for following the procedure described in RFC 4395. I=

think this is our first registration request under the new guidelines,=

so it's nice to see it in good shape.

Mark.

On 5/11/06, Andrey Shur <andreysh@exchange.microsoft.com> wrote:=

> This mail is sending to request the submission of the "pack&= quot; Uri scheme

> registration template (attached) for review.

> Regards

> - Andrey Shur

> _______________________________________________

> Uri-review mailing list

> Uri-review@ietf.org

> htt= ps://www1.ietf.org/mailman/listinfo/uri-review

--_000_1D4A05136773CF4DB373F6FE4E103150110EEAEBdfpugmsgexchang_-- --===============1697813001== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Uri-review mailing list Uri-review@ietf.org https://www1.ietf.org/mailman/listinfo/uri-review --===============1697813001==-- From uri-review-bounces@ietf.org Sat May 20 16:20:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhXw4-00064r-RJ; Sat, 20 May 2006 16:20:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhXw4-00064m-4i for uri-review@ietf.org; Sat, 20 May 2006 16:20:28 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhXw2-0006gZ-Ff for uri-review@ietf.org; Sat, 20 May 2006 16:20:28 -0400 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.70.52]) by mail4.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 May 2006 13:20:25 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-02.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 May 2006 13:20:25 -0700 X-MS-Exchange-Organization-AuthDomain: From: Andrey Shur To: Mark Baker Date: Sat, 20 May 2006 13:20:25 -0700 Subject: RE: [Uri-review] Request for review Thread-Topic: [Uri-review] Request for review Thread-Index: AcZ8RG4vRFOLgN5wQ7OU2OBhN+BtegAAQqeQ Message-ID: <1D4A05136773CF4DB373F6FE4E103150110EEAEE@df-pug-msg.exchange.corp.microsoft.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: AcceptLanguage: en-US x-ms-exchange-organization-authmechanism: SecureMapiSubmit x-ms-exchange-organization-authsource: df-bhd-02.exchange.corp.microsoft.com x-ms-exchange-organization-authas: Internal x-recipient-p2-type: Cc MIME-Version: 1.0 X-OriginalArrivalTime: 20 May 2006 20:20:25.0331 (UTC) FILETIME=[D4074C30:01C67C4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 Cc: "John Calhoon \(LCA\)" , Gregg, Ted Hardie , "uri-review@ietf.org" , Jerry Dunietz , Brown X-BeenThere: uri-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Proposed URI Schemes List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0947329799==" Errors-To: uri-review-bounces@ietf.org --===============0947329799== Content-Type: multipart/alternative; boundary="_000_1D4A05136773CF4DB373F6FE4E103150110EEAEEdfpugmsgexchang_" --_000_1D4A05136773CF4DB373F6FE4E103150110EEAEEdfpugmsgexchang_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mark, you ask why do we need to refer to a part using /bar.xml? We don't need to use exactly this form of relative reference to refer to a = part. Our goal was to guarantee that any relative reference in a package pa= rt refers to a part within the same package (unless, as I mentioned before,= relative reference is in the network-path form, or base Uri for the refere= nce is explicitly defined in a way that leads to opposite). Having said this, in the example below "/= bar.xml" can be replaced by e.g. "../../../bar.xml" with the same reasoning= . As for your concerns about the component of the "pack:" Uri bei= ng the encoded Uri of the package, it is indeed an unusual (although we are= sure - consistent) approach. I would expect the serious discussion on that= in the context of registration procedure. To begin with let me say that th= e grammar for pack: component completely fits the RFC 3986. Thanks - Andrey -----Original Message----- From: mbaker@gmail.com [mailto:mbaker@gmail.com] On Behalf Of Mark Baker Sent: Saturday, May 20, 2006 12:35 PM To: Andrey Shur Cc: uri-review@ietf.org; Ted Hardie; Jerry Dunietz; Gregg Brown; John Calho= on (LCA) Subject: Re: [Uri-review] Request for review Andrey, First, my sincere apologies for botching your name earlier. I didn't look closely enough, obviously ... On 5/20/06, Andrey Shur wrote: > Mark, > > Thank you for the question. The primary reason why we did not use the > approach you describe is the requirement for relative references within a > package parts to refer to parts within the same package. > Our registration template says: > > The purposes of the "pack" URI scheme are: > > 1. To identify a part resource within a package that conforms to > Open Packaging Conventions [4]. > 2. To enable the use of a part's URI as a base URI for resolving > relative references to parts within the same package. > > Let's assume that in your example part identified by the Uri > http://www.mysite.com/my.package/a/b/foo.xaml > holds relative reference /bar.xml. > Being resolved against the base Uri of the part it gives us > http://www.mysite.com/bar.xml which is outside of the package. Ok, thanks. But why do you need to refer to a part using "/bar.xml"? What purpose does that serve? Why does "bar.xml" not suffice? Perhaps the packaging spec could shed some light on this, and I'm sure you're just doing what your lawyers suggested by using a license, but I'm not about to accept its terms without running it by my employer's lawyers, lest I get my employer in trouble by accepting (even though I'm not representing them here). And I'm not sure about the IETF rules about this stuff, but I believe it to be (at least) considered bad form. Mark. --_000_1D4A05136773CF4DB373F6FE4E103150110EEAEEdfpugmsgexchang_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mark,

you ask why do we need to refer to a part using /bar.xml?

We don’t need to use exactly this form of relative reference = to refer to a part. Our goal was to guarantee that any relative referen= ce in a package part refers to a part within the same package (unless, as I menti= oned before, relative reference is in the network-path form, or base Uri for the reference is explicitly defined

in a way that leads to opposite). Having said this, in the example below “/bar.xml” can be replaced by e.g. “../../../bar.xm= l” with the same reasoning.

As for your concerns about the <authority> component of the &= #8220;pack:” Uri being the encoded Uri of the package, it is indeed an unusual (although= we are sure – consistent) approach. I would expect the serious discussio= n on that in the context of registration procedure. To begin with let me say tha= t the grammar for pack: <authority> component completely fits the RFC 3986.=

Thanks

- Andrey

-----Original Message-----
From: mbaker@gmail.com [mailto:mbaker@gmail.com] On Behalf Of Mark Baker Sent: Saturday, May 20, 2006 12:35 PM
To: Andrey Shur
Cc: uri-review@ietf.org; Ted H= ardie; Jerry Dunietz; Gregg Brown; John Calhoon (LCA)
Subject: Re: [Uri-review] Request for review

Andrey,

First, my sincere apologies for botching your name earlier. I didn't

look closely enough, obviously ...

On 5/20/06, Andrey Shur <andreysh@exchange.microsoft.com> wro= te:

> Mark,

> Thank you for the question. The primary reason why we did not = use the

> approach you describe is the requirement for relative referenc= es within a

> package parts to refer to parts within the same package.<= /o:p>

> Our registration template says:

> The purposes of the "pack" URI sch= eme are:

> 1. To identify a part resource within a pack= age that conforms to

> Open Packaging Conventions [4].

> 2. To enable the use of a part's URI as a ba= se URI for resolving

> relative references to par= ts within the same package.

> Let's assume that in your example part identified by the Uri

> http://www.mysite.com/my.package/a/b/foo.xaml

> holds relative reference /bar.xml.

> Being resolved against the base Uri of the part it gives us

> http://www.mysite.com/bar.xml which is outside of the package.=

Ok, thanks. But why do you need to refer to a part using "/bar.xml"?

What purpose does that serve? Why does "bar.xml" no= t suffice?

Perhaps the packaging spec could shed some light on this, and I'm s= ure

you're just doing what your lawyers suggested by using a license, b= ut

I'm not about to accept its terms without running it by my employer= 's

lawyers, lest I get my employer in trouble by accepting (even thoug= h

I'm not representing them here). And I'm not sure about the I= ETF

rules about this stuff, but I believe it to be (at least) considere= d

bad form.

Mark.

--_000_1D4A05136773CF4DB373F6FE4E103150110EEAEEdfpugmsgexchang_-- --===============0947329799== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Uri-review mailing list Uri-review@ietf.org https://www1.ietf.org/mailman/listinfo/uri-review --===============0947329799==-- From uri-review-bounces@ietf.org Mon May 22 16:13:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiGm3-00033m-JF; Mon, 22 May 2006 16:13:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiGm3-00033h-BW for uri-review@ietf.org; Mon, 22 May 2006 16:13:07 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiGm2-0002SE-5U for uri-review@ietf.org; Mon, 22 May 2006 16:13:07 -0400 Received: by py-out-1112.google.com with SMTP id f28so1564525pyf for ; Mon, 22 May 2006 13:13:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=bvz22IJli5HyTez9GiTrBRtqCJPfcCiSffCQkT98tnyv8QKM6XQmIq1vUJ5bKI25y0KSnHdCmDwmTv4wb14jUbdWcW9lx7kEbP41/a994bNKt0Le0IbwRu+pXLH2jyaroxOni8AiaV/OGIGpqCRVYiMZUf3hMIrPM5pikA9+EII= Received: by 10.35.93.18 with SMTP id v18mr151228pyl; Mon, 22 May 2006 13:13:05 -0700 (PDT) Received: by 10.35.70.20 with HTTP; Mon, 22 May 2006 13:13:05 -0700 (PDT) Message-ID: Date: Mon, 22 May 2006 22:13:05 +0200 From: "Mark Baker" To: "Andrey Shur" Subject: Re: [Uri-review] Request for review In-Reply-To: <1D4A05136773CF4DB373F6FE4E103150110EEAEE@df-pug-msg.exchange.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1D4A05136773CF4DB373F6FE4E103150110EEAEE@df-pug-msg.exchange.corp.microsoft.com> X-Google-Sender-Auth: 27e3ed9368c8ab6f X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Ted Hardie , "uri-review@ietf.org" , Jerry Dunietz , Gregg Brown , "John Calhoon \(LCA\)" X-BeenThere: uri-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Proposed URI Schemes List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: uri-review-bounces@ietf.org Andrey, On 5/20/06, Andrey Shur wrote: > Mark, > > you ask why do we need to refer to a part using /bar.xml? > > We don't need to use exactly this form of relative reference to refer to = a > part. Our goal was to guarantee that any relative reference in a package > part refers to a part within the same package Ok, thanks. What purpose does this goal serve? Mark. _______________________________________________ Uri-review mailing list Uri-review@ietf.org https://www1.ietf.org/mailman/listinfo/uri-review From uri-review-bounces@ietf.org Mon May 22 22:08:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiMJa-0002RB-FD; Mon, 22 May 2006 22:08:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiMJZ-0002R2-CS for uri-review@ietf.org; Mon, 22 May 2006 22:08:05 -0400 Received: from mail3.exchange.microsoft.com ([131.107.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiMJT-0003Ba-Ul for uri-review@ietf.org; Mon, 22 May 2006 22:08:05 -0400 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.70.52]) by mail3.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 19:07:59 -0700 Received: from df-bhd-01.exchange.corp.microsoft.com ([157.54.54.216]) by df-hub-02.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 19:07:58 -0700 X-MS-Exchange-Organization-AuthDomain: From: Andrey Shur To: Mark Baker Date: Mon, 22 May 2006 19:08:00 -0700 Subject: RE: [Uri-review] Request for review Thread-Topic: [Uri-review] Request for review Thread-Index: AcZ93CTvYN9wsrGETaa5x/1rhEgQAgAH196g Message-ID: <1D4A05136773CF4DB373F6FE4E103150110EEE14@df-pug-msg.exchange.corp.microsoft.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: AcceptLanguage: en-US x-ms-exchange-organization-authmechanism: SecureMapiSubmit x-ms-exchange-organization-authsource: df-bhd-01.exchange.corp.microsoft.com x-ms-exchange-organization-authas: Internal x-recipient-p2-type: Cc MIME-Version: 1.0 X-OriginalArrivalTime: 23 May 2006 02:07:58.0520 (UTC) FILETIME=[B652EB80:01C67E0D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: "John Calhoon \(LCA\)" , Jerry, Ted Hardie , "uri-review@ietf.org" , Dunietz , Gregg Brown X-BeenThere: uri-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Proposed URI Schemes List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1518216663==" Errors-To: uri-review-bounces@ietf.org --===============1518216663== Content-Type: multipart/alternative; boundary="_000_1D4A05136773CF4DB373F6FE4E103150110EEE14dfpugmsgexchang_" --_000_1D4A05136773CF4DB373F6FE4E103150110EEE14dfpugmsgexchang_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mark, Thank you for the question. I can see two parts of it that should be answer= ed: First, why do we consider "any relative reference"? Actually we expect user= s of the packaging technology to store manifold content in the package part= s. Certain kinds of the content may hold relative references. We don't want= to limit our customers to a particular form of relative references. Second, why do we have a goal to "keep relative references within the packa= ge"? This is all about security. An application performing regular (default= ) resolution of relative references should not access resources outside of = the package. If an application needs to access external resources, it must be explicitly= defined in the content by specifying an appropriate base Uri or by using n= etwork-path form of the relative reference. - Andrey -----Original Message----- From: mbaker@gmail.com [mailto:mbaker@gmail.com] On Behalf Of Mark Baker Sent: Monday, May 22, 2006 1:13 PM To: Andrey Shur Cc: John Calhoon (LCA); Ted Hardie; uri-review@ietf.org; Jerry Dunietz; Gre= gg Brown Subject: Re: [Uri-review] Request for review Andrey, On 5/20/06, Andrey Shur wrote: > Mark, > > you ask why do we need to refer to a part using /bar.xml? > > We don't need to use exactly this form of relative reference to refer to = a > part. Our goal was to guarantee that any relative reference in a package > part refers to a part within the same package Ok, thanks. What purpose does this goal serve? Mark. --_000_1D4A05136773CF4DB373F6FE4E103150110EEE14dfpugmsgexchang_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mark,

Thank you for the question. I can see two parts of it that should be a= nswered:

First, why do we consider "any relative reference"? Actually= we expect users of the packaging technology to store manifold content in t= he package parts. Certain kinds of the content may hold relative references= . We don't want to limit our customers to a particular form of relative references.

Second, why do we have a goal to "keep relative references within= the package"? This is all about security. An application performing r= egular (default) resolution of relative references should not access resour= ces outside of the package.

If an application needs to access external resources, it must be expli= citly defined in the content by specifying an appropriate base Uri or by us= ing network-path form of the relative reference.

- Andrey

-----Original Message-----
From: mbaker@gmail.com [mailto:mbaker@g= mail.com] On Behalf Of Mark Baker
Sent: Monday, May 22, 2006 1:13 PM
To: Andrey Shur
Cc: John Calhoon (LCA); Ted Hardie; uri-review@ietf.org; Jerry Dunietz; Gre= gg Brown
Subject: Re: [Uri-review] Request for review

Andrey,

On 5/20/06, Andrey Shur <andreysh@exchange.microsoft.com> wrote:=

> Mark,

> you ask why do we need to refer to a part using /bar.xml?

> We don't need to use exactly this form of relative reference to r= efer to a

> part. Our goal was to guarantee that any relative reference in a = package

> part refers to a part within the same package

Ok, thanks. What purpose does this goal serve?

Mark.

--_000_1D4A05136773CF4DB373F6FE4E103150110EEE14dfpugmsgexchang_-- --===============1518216663== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Uri-review mailing list Uri-review@ietf.org https://www1.ietf.org/mailman/listinfo/uri-review --===============1518216663==-- From uri-review-bounces@ietf.org Mon May 22 23:14:39 2006 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 , Mark Baker From: Martin Duerst Subject: RE: [Uri-review] Request for review In-Reply-To: <1D4A05136773CF4DB373F6FE4E103150110EEE14@df-pug-msg.exchan ge.corp.microsoft.com> References: <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\)" , Ted Hardie , "uri-review@ietf.org" , Dunietz , Gregg Brown , 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 List-Unsubscribe: , List-Post: List-Help: List-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 From uri-review-bounces@ietf.org Tue May 23 12:30:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZm1-00076y-O2; Tue, 23 May 2006 12:30:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZm1-00076t-1P for uri-review@ietf.org; Tue, 23 May 2006 12:30:21 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZls-0006d5-9J for uri-review@ietf.org; Tue, 23 May 2006 12:30:20 -0400 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.69.171]) by mail4.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 09:30:11 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 09:30:11 -0700 X-MS-Exchange-Organization-AuthDomain: From: Andrey Shur To: Martin Duerst , Mark Baker Date: Tue, 23 May 2006 09:30:12 -0700 Subject: RE: [Uri-review] Request for review Thread-Topic: [Uri-review] Request for review Thread-Index: AcZ+FwBiytFkIHUYQ561iYDvzileGgAKxhfw Message-ID: <1D4A05136773CF4DB373F6FE4E103150110EEEB9@df-pug-msg.exchange.corp.microsoft.com> In-Reply-To: <6.0.0.20.2.20060523114617.0860fa00@localhost> Accept-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: AcceptLanguage: en-US x-ms-exchange-organization-authmechanism: SecureMapiSubmit x-ms-exchange-organization-authsource: df-bhd-02.exchange.corp.microsoft.com x-ms-exchange-organization-authas: Internal x-recipient-p2-type: Cc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 May 2006 16:30:11.0462 (UTC) FILETIME=[298F6A60:01C67E86] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: "John Calhoon \(LCA\)" , Ted, Hardie , "uri-review@ietf.org" , Jerry Dunietz , Gregg Brown , "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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: uri-review-bounces@ietf.org Hi Martin, thank you for the feedback. You have raised the number of points, but befor= e going through them let me describe how relative references in a part's co= ntent are resolved according to the Open Packaging Conventions (OPC) techno= logy (which "pack:" Uri scheme is a part of). Let's take the package http://www.mysite.com/my.package. The package holds = a number of parts; the part named /bar.xml holds relative references "../..= /foo.ext" and "/path/foo.ext". OPC defines the base Uri of the part named /bar.xml as pack://http%3c,,www.= mysite.com,my.package/bar.xml. Note that OPC only defines the base Uri of a= part, the resolution of relative references follows the algorithm defined = in RFC 3986 section 5. If content of the part /bar.xml does not hold explicit instructions definin= g another base Uri (e.g. xml:base attribute), relative references are resol= ved against the base Uri of the part. In our example: Relative reference ../../foo.ext resolved against the base Uri =3D pack://h= ttp%3c,,www.mysite.com,my.package/bar.xml gives us pack://http%3c,,www.mysi= te.com,my.package/foo.ext. The obtained Uri identifies part named /foo.ext = within the given package. Relative reference /path/foo.ext resolved against the base Uri =3D pack://h= ttp%3c,,www.mysite.com,my.package/bar.xml gives us pack://http%3c,,www.mysi= te.com,my.package/path/foo.ext. The obtained Uri identifies part named /pat= h/foo.ext within the given package. We can see from these two examples that any relative reference (let's put n= etwork-path aside) being resolved against the base Uri of the part gives us= the "pack:" Uri that identifies a part within the same package. Regards, Andrey Shur -----Original Message----- From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] Sent: Monday, May 22, 2006 8:04 PM To: Andrey Shur; Mark Baker Cc: John Calhoon (LCA); Jerry@scmailgw1.scop.aoyama.ac.jp; Ted Hardie; uri-= review@ietf.org; Jerry Dunietz; Gregg Brown Subject: RE: [Uri-review] Request for review 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 answe= red: > >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 From uri-review-bounces@ietf.org Tue May 23 16:24:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FidQg-0005gB-OP; Tue, 23 May 2006 16:24:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FidQg-0005fx-2P for uri-review@ietf.org; Tue, 23 May 2006 16:24:34 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FidQe-0001vT-SK for uri-review@ietf.org; Tue, 23 May 2006 16:24:34 -0400 Received: by py-out-1112.google.com with SMTP id f28so1876159pyf for ; Tue, 23 May 2006 13:24:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=YMFKinjtae/pNR9mznLG2EmAWbgCZ+tHOG87qgQFtla2MPJLdbaXuUO0ISu8UaIACgXloHP2HG4EEmnDsNaxc8au2ZlkyY8GjP1icBs8ZSVImCBmshryx/J5jKdtHcV+6LsJ2GFZ7NYV64scxysWw9H5jVUQ7ZVZdUMovJbY0so= Received: by 10.35.97.17 with SMTP id z17mr2905498pyl; Tue, 23 May 2006 13:24:32 -0700 (PDT) Received: by 10.35.70.20 with HTTP; Tue, 23 May 2006 13:24:32 -0700 (PDT) Message-ID: Date: Tue, 23 May 2006 22:24:32 +0200 From: "Mark Baker" To: "Martin Duerst" Subject: Re: [Uri-review] Request for review In-Reply-To: <6.0.0.20.2.20060523114617.0860fa00@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1D4A05136773CF4DB373F6FE4E103150110EEE14@df-pug-msg.exchange.corp.microsoft.com> <6.0.0.20.2.20060523114617.0860fa00@localhost> X-Google-Sender-Auth: 0be6d88c907a1e79 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: "John Calhoon \(LCA\)" , Andrey Shur , Ted Hardie , "uri-review@ietf.org" , Dunietz , Gregg Brown , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: uri-review-bounces@ietf.org On 5/23/06, Martin Duerst wrote: > 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. AIUI, that's a guaranteed in-package reference. But I agree with the gist of your argument, Martin; it's where I was going with my questioning, in particular the value of syntactic safety (low) vs. the cost of deploying a new URI scheme (high). Mark. _______________________________________________ Uri-review mailing list Uri-review@ietf.org https://www1.ietf.org/mailman/listinfo/uri-review From uri-review-bounces@ietf.org Wed May 24 21:26:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj4bx-000126-W1; Wed, 24 May 2006 21:26:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj4bx-000121-7e for uri-review@ietf.org; Wed, 24 May 2006 21:26:01 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj4bt-0000Vb-JB for uri-review@ietf.org; Wed, 24 May 2006 21:26:01 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k4P1PqRH015070; Thu, 25 May 2006 10:25:52 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 67dd_678b7e48_eb8d_11da_8572_0014221f2a2d; Thu, 25 May 2006 10:25:51 +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 k4P1NrdT031436; Thu, 25 May 2006 10:24:19 +0900 Message-Id: <6.0.0.20.2.20060524192151.08818180@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 24 May 2006 19:28:44 +0900 To: Andrey Shur , Mark Baker From: Martin Duerst Subject: RE: [Uri-review] Request for review In-Reply-To: <1D4A05136773CF4DB373F6FE4E103150110EEEB9@df-pug-msg.exchan ge.corp.microsoft.com> References: <6.0.0.20.2.20060523114617.0860fa00@localhost> <1D4A05136773CF4DB373F6FE4E103150110EEEB9@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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "John Calhoon \(LCA\)" , TedHardie , "uri-review@ietf.org" , Jerry Dunietz , Gregg Brown , "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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: uri-review-bounces@ietf.org At 01:30 06/05/24, Andrey Shur wrote: >Hi Martin, > >thank you for the feedback. You have raised the number of points, but >before going through them let me describe how relative references in a >part's content are resolved according to the Open Packaging Conventions >(OPC) technology (which "pack:" Uri scheme is a part of). [Examples removed] >We can see from these two examples that any relative reference (let's put >network-path aside) being resolved against the base Uri of the part gives >us the "pack:" Uri that identifies a part within the same package. Well, that's true as long as you stay within your packageing technology. But what I was talking about (sorry I wasn't explicit enough) was conversion from e.g. a directory full of files and directories and so on to a package and again backwards. Relative references serve various purposes. One of the is to be able to use short URIs for 'close' things. But another is to be able to create collections of stuff where internal references don't have to be changed if the location of the overall thing changes. The "location of the overall thing" doesn't only mean in the same scheme, but also across schemes (http: and ftp: would be the example where this is easiest to do/show). If you re-read my previous mail from that viewpoint, I hope you understand my point better. 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 From uri-review-bounces@ietf.org Fri May 26 02:57:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjWG5-0001cF-DQ; Fri, 26 May 2006 02:57:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjVDH-0000d5-HX for uri-review@ietf.org; Fri, 26 May 2006 01:50:19 -0400 Received: from maila.microsoft.com ([131.107.1.6] helo=mail1.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjVD8-0005N3-V8 for uri-review@ietf.org; Fri, 26 May 2006 01:50:19 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 22:50:10 -0700 Received: from tuk-hub-01.redmond.corp.microsoft.com ([157.54.70.27]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 22:50:09 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 22:50:09 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 22:50:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Uri-review] Request for review Date: Thu, 25 May 2006 22:49:52 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80E4ABC1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6.0.0.20.2.20060524192151.08818180@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Uri-review] Request for review thread-index: AcZ/mke7quG/zhdpQ1+SYQyh5UO8iwA6O/GQ From: "Jerry Dunietz" To: "Martin Duerst" , "Andrey Shur" , "Mark Baker" X-OriginalArrivalTime: 26 May 2006 05:50:09.0243 (UTC) FILETIME=[3F4B12B0:01C68088] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c X-Mailman-Approved-At: Fri, 26 May 2006 02:57:16 -0400 Cc: Jerry@scmailgw1.scop.aoyama.ac.jp, TedHardie , uri-review@ietf.org, Gregg Brown , "John Calhoon \(LCA\)" X-BeenThere: uri-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Proposed URI Schemes List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: uri-review-bounces@ietf.org Forgive me for being late to join this conversation. Thanks for all of=20 the constructive discussion! I'm going to chime in with some long mail, picking up on some comments made by both Martin Duerst and Mark Baker. =20 I'm covering three topics here: I. Relative references and leading slash II. Martin Duerst's scenarios involving a "directory of files" III. Refining the goals for the "pack:" scheme I. Relative references and leading slash Just to confirm, I hope that it is now clear that there is no requirement=20 for the relative references within a package to begin with a leading slash. =20 Assume that we take some hierarchically-"close" resources on the web, and=20 we copy their representations (unmodified) into a package. If the package=20 preserves enough of the "close" naming hierarchy surrounding the resources,=20 then the original relative-references will now resolve to the=20 representation-copies within the package. Achieving this behavior is one=20 of the goals we had in specifying the "pack:" scheme. II. Martin Duerst's scenarios involving a "directory of files" Martin Duerst wrote: > But what I was talking about (sorry I wasn't explicit > enough) was conversion from e.g. a directory full of files and=20 > directories and so on to a package and again backwards. I want to take the time to expound on this topic at some length, just to make sure that we clearly understand one another. (I think that I understand=20 the concerns, and I believe that the implications are acceptable.) It is true that if one of our resource-representations contained a relative=20 reference which pointed outside of the "close" naming hierarchy that has been preserved in the package, then such a relative reference will no longer=20 resolve within the package in a manner that is consistent with the way in=20 which it was resolved against the original HTTP server. Most likely, the=20 relative-reference will fail to resolve. However, it is conceivable that=20 the relative reference will now be interpreted as pointing to some other resource-representation within the package. So, for example, if I have=20 on a web-server: http://example.com/foo.xml http://example.com/a/foo.xml http://example.com/a/b/foo.xml http://example.com/a/b/bar.xml Let us assume that http://example.com/a/b/bar.xml contains within it=20 three relative references, with the following forms: "foo.xml" "../foo.xml" "/foo.xml" Against the HTTP server, the these three reference will resolve to=20 *different* resources. Now, suppose we choose to gather everything under "http://example.com/a/b"=20 into a package. There are three different naming choices I might make in putting together=20 my package. 1) /foo.xml /bar.xml 2) /b/foo.xml /b/bar.xml 3) /a/b/foo.xml /a/b/bar.xml If I take the first naming approach, the relative references of the=20 form "../foo.xml" and "/foo.xml" behave very differently then they did=20 against the HTTP server. They both successfully resolve, but produce=20 very different results than they originally did. The behavior of=20 "../foo.xml" is a direct result of the requirements of RFC 3986 --=20 the excess leading ".." segments (in the context of the package authority)=20 effectively disappear. All three references now resolve to the same=20 resource, whereas they resolved to three different resources originally. If I take the second or third naming approach, the references of the=20 form "../foo.xml" and "/foo.xml" will not be resolvable, but at least=20 they will not resolve to totally different resources (or copies of=20 a resource-representations) then they did in the original environment. =20 However, if I take the second approach, there are other relative=20 references which will (successfully) resolve differently then they=20 would have originally. By taking the third approach, I guarantee, without processing the=20 contents of every copied resource-representation, that no formerly- functioning relative reference will *successfully* resolve differently=20 then it did in the original environment. If I take instead the stronger goal of assuring that no formerly- functioning relative-reference is broken, then I must either propagate=20 every resource from the original web-server (authority) into the package,=20 or I must filter all of the references within all of the resources=20 being propagated into the package. So far, I've only addressed what happens when I propagate a bunch=20 of resources into a package. I haven't discussed what happens if=20 I take a copy of the package, and then "explode" its contents to point=20 deep within the naming hierarchy of my own private filesystem or web- server. If any reference contained excess leading ".." segments on=20 the original HTTP server, then it is true such a reference might have=20 successfully resolved in the original environment and also within the=20 package environment, but it might (successfully) resolve differently=20 in the new environment. Having taken the time to write all of the above down, I don't actually=20 consider the behavior I've described above to be problematic enough=20 to outweigh the advantages of what we've designed. I recognize that=20 others might disagree. But I do want to make sure that I fully=20 understand the behavior that might be seen as problematic. Have=20 I captured your concerns (perhaps in too great detail)? Hopefully,=20 we can agree on all matters of fact, but we might have disagreements=20 on matters of judgment. III. Refining the goals for the "pack:" scheme Let me list a few goals here, some of which were not clearly called out=20 in the original submission. I believe that this set of goals leads us=20 to the design we've proposed here. I think it important that we clearly distinguish between discussions questioning the goals below from=20 discussion questioning the means for achieving these goals. (Both are=20 interesting discussions, but let's me clear about when we are discussing each.) 1) Relative references within a package should "work" correctly. 2) Given a package on an HTTP server somewhere, we should be able to=20 construct an absolute reference to a particular part nested in the=20 package, made from outside of the package. 3) We would like the absolute reference described in #2 to function=20 without requiring the deployment of any new code on the HTTP server=20 holding the package. (Mark Baker's suggestion of=20 "http://www.mysite.com/my.package/a/b/foo.xaml" does not satisfy=20 this goal.) 4) We would like to deliver behavior above without changing existing=20 code that relies upon off-the-shelf client-side libraries for dealing=20 with URIs. (That is, we assume that client-side library or installed code would be updated to support the "pack:" scheme, but the=20 code that calls the library requires no change.) So -- are concerns being expressed with respect to the desirability of=20 the new set of goals I describe here, or are they with the means for=20 achieving those goals? (I do think that it would be reasonable for us=20 to flesh out the goals stated in the original submission.) -- Jerry Dunietz =20 _______________________________________________ Uri-review mailing list Uri-review@ietf.org https://www1.ietf.org/mailman/listinfo/uri-review