Re: [Uri-review] Request for review
"Mark Baker" <distobj@acm.org> Thu, 29 June 2006 14:40 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxhB-0001il-Fj; Thu, 29 Jun 2006 10:40:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxhA-0001if-D0 for uri-review@ietf.org; Thu, 29 Jun 2006 10:40:40 -0400
Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvxh9-0003HT-Ut for uri-review@ietf.org; Thu, 29 Jun 2006 10:40:40 -0400
Received: by ug-out-1314.google.com with SMTP id m3so385353uge for <uri-review@ietf.org>; Thu, 29 Jun 2006 07:40:38 -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=jdRyVpqSlP84mKUJdYQIP2lXwv4cUZO548vabPICn2OPit9sgmiaP5yPWQVcyRLOmLSixyZTAwJxEqQmzH++v2cqFBI9G0AJD5uG7oRcDthXuUbyFIop3aHfOWT0QyC9qaCGvfDCY0+5ootrv5qMssLi7yMhP3ndtAk0wSoY2Vw=
Received: by 10.78.159.7 with SMTP id h7mr981167hue; Thu, 29 Jun 2006 07:40:38 -0700 (PDT)
Received: by 10.78.15.17 with HTTP; Thu, 29 Jun 2006 07:40:38 -0700 (PDT)
Message-ID: <c70bc85d0606290740i458c1666j85b09636d5a84679@mail.gmail.com>
Date: Thu, 29 Jun 2006 10:40:38 -0400
From: Mark Baker <distobj@acm.org>
To: Jerry Dunietz <jerryd@windows.microsoft.com>
Subject: Re: [Uri-review] Request for review
In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80015067DA@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <c70bc85d0606182202g384b9ddk20313d324f352f6d@mail.gmail.com> <5F3AAFB2FEC5ED4AA6DE79A3E0B47D80015067DA@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
X-Google-Sender-Auth: e0b770d3ee513182
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: "John Calhoon (LCA)" <john.calhoon@microsoft.com>, Andrey Shur <andreysh@exchange.microsoft.com>, TedHardie <hardie@qualcomm.com>, uri-review@ietf.org, 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
Jerry, On 6/23/06, Jerry Dunietz <jerryd@windows.microsoft.com> wrote: > > I'm not sure I'm following you. What do you mean by "the code works > with"? > > Let me elaborate. There exist programming frameworks in both > the Java and .NET worlds that includes classes for dealing with and > dereferencing URIs and/or URLs. (The exact class names used varies.) > > My point was that any code which written to use such a general > URI-dereferencing class need not be modified to deal with the > introduction of the "pack:" scheme; the only modification would be > the one required to incorporate "pack:" support into the URI- > dereferencing class. If a component's source code deals with, for > example, the SVG media type, then it need not be modified to > support SVG embedded within a package. Ok, thanks. I agree that is valuable. > Furthermore, as I stated before, our goal is to allow for dereference- > able external URIs pointing to individual part-resources within a > package. If we were to model the package only with a media type (or > set of media types), then we would have to invent a fragment-identifier > mechanism to allow for the referencing of individual parts within the > package. No, you wouldn't AFAICT. You could use what I proposed before, about using references relative to the URI of the package. > And if we were to use fragment-identifiers for this purpose, > we would raise the problematic question of what base URI should be > used when dereferencing relative-URIs embedded within an individual > part. If we used a fragment-identifier to address the individual > part, then by ordinary conventions, the base URI for resolving > relative references embedded in the individual part would be the > (fragment-identifier-free) URI of the package as a whole. > > The combination of our three goals lead us to our specification: > > 1. External absolute references to individual parts. > 2. An individual part's URI can serve as a base URI. > 3. Package can reside on any server implementing any protocol > supporting a GET-like operation, without requiring new code to be > deployed on the server. My solution also meets those goals, AFAICT. > > As I see it, if the package were downloaded to the client, be it with > > HTTP, FTP, or a pack-specific PACK-TP, it should ideally be > > transferred using a media type which declares the format; say, > > application/vnd.ms.pack. And that media type should be used in > > locating an application which can process the package. I don't see > > why the URI should be used in that process, because a) URIs are names > > and don't typically carry that kind of info (the data scheme > > notwithstanding), and b) that sounds just like what a media type is > > for. > > We do have a number of media types for domain- or application- > specific data formats that are defined in terms of the package-format > spec. We are considering the possibility, as you suggest, of a > domain-independent media-type for a generic package, applicable > independently of what the package holds. Good. > > > It doesn't require any more server-side support than the new URI > scheme, AFAICT. > > We believe that the URI scheme we propose requires *no* server-side > support. Right. But you seemed to suggest that my alternate proposal does require it. I don't believe either approach does, at least for this case of "download the package to the client". > Finally, I would now like to re-introduce the "security" argument > that I set aside earlier in this thread. I said before that I didn't > believe that the "security" topic was necessary to motivate our > specification. But we observe that some existing software makes > security decisions based on determining whether or not two URIs > reference resources within the same "site" or "zone". We regard it > to be a feature of our proposal that any such pre-existing software > will consider any package-boundary to be a "site" boundary. Any > protections for cross-site references will apply to references > that cross a package boundary. Can you provide some more specifics about this software? Cheers, Mark. _______________________________________________ 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