I think that is the best approach as well. The WebSec use is purely to create a strong reference. I think that if we can get convergence on the core spec quickly, the WebSec use should be orthogonal.
The aim here is merely to ensure that we end up with one mechanism for specifying digests of referenced objects rather than having slightly different versions in different groups. There are many interesting things that can be done with digest URIs. Some of which will probably solve problems WebSEC faces. But DECADE is clearly the best place to discuss those at the moment. All that WebSEC will be using for the time being is the ability to refer to securely a blob of security policy related data in a fashion that packages all the crypto gubbins into one string of text. DECADE is rather different because it is in effect describing a new and very different form of URL. A traditional URL is a procedural content link, the content is defined by the means of retrieval. An ni URI is also a locator in that it MAY give one (or more) means of locating the data. But the data itself is specified in a functional style. Any method of function evaluation that produces the expected result is equally valid (but not necessarily equally efficient). I do have some proposals for using the digest URI that maybe fall outside both WG charters. This is a notary technology that I think we need. But this is something that simply has to be built on top of DECADE so that it can have the acronym DECADE-Notary Technology, or DECADENT. On Wed, Oct 26, 2011 at 9:34 AM, Dirk Kutscher <[email protected]>wrote: > Rich, > > yes, I agree that we should decide that. > > Our recommendation would be to do the base spec in DECADE. > > Best regards, > > Dirk > > > > > > -----Original Message----- > > From: Woundy, Richard [mailto:[email protected]] > > Sent: Mittwoch, 26. Oktober 2011 15:22 > > To: Dirk Kutscher; '[email protected]' > > Cc: '[email protected]'; '[email protected]'; > > '[email protected]'; Woundy, Richard > > Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme > > > > Now that we have established that websec and decade are at least > > interested in the named information uri scheme, do we know what group is > > expected to own the base specification? That might be a good topic to > > discuss with the relevant ADs in email now and at IETF 82 in person (app > and > > tsv at least). > > > > ----- Original Message ----- > > From: Dirk Kutscher [mailto:[email protected]] > > Sent: Wednesday, October 26, 2011 09:06 AM > > To: decade ietf <[email protected]> > > Cc: Christian Dannewitz ([email protected]) > <cdannewitz@uni- > > paderborn.de>; Rob Stradling ([email protected]) > > <[email protected]>; [email protected] > > <[email protected]> > > Subject: [decade] URIs for DECADE -- Named Information URI Scheme > > > > Dear all, > > > > We have updated the Named Information URI scheme that we presented at > > IETF-81. > > > > It turned out that the WEBSEC folks (Phillip Hallam-Baker and colleagues) > had > > started a parallel effort on a very similar approach, and -- fortunately > -- we > > have been able to combine our efforts and have advanced the spec so that > it > > would be useful for DECADE, WEBSEC and potentially other applications. > > > > We still think that DECADE could benefit most at this time, so we > submitted > > this (as an individual submission) to DECADE now. > > > > We found a, IMO, nice way to have a concise base specification without > > excluding extensions for future application requirements. Basically, > there is > > an extension mechanism that allows applications to specify additional > > parameters. > > > > To make this manageable, we have split the specification into two pieces: > > > > The base spec: > > > > http://tools.ietf.org/html/draft-farrell-decade-ni-00 > > > > This document defines a URI-based name form that identifies a named > > object via hash-based binding. The URI name form defined is intended > for > > use in applications that need to uniquely identify resources in a > location- > > independent way such as accessing in-network storage (DECADE), > > information-centric networking and more generally. The format is > designed > > to support a strong link to the referenced object such that the > referenced > > object may be authenticated to the same degree as the reference to it. > > > > The base spec has a set of useful general features (in addition to the > actual > > syntax definition), such as processing rules (testing for equality), and > an > > algorithm that can be used to map NI URIs to HTTP(S) automatically -- > which I > > believe could be useful for DECADE, too. The base spec also defines the > > fundamentals of the extension mechanism. > > > > > > A spec that defines a set of extension parameters and their semantics: > > > > http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-00 > > This document specifies some optional algorithms and parameters that may > > be used in the query string of ni URIs. > > > > One of the parameters that we have introduced here would allow you to > > specify additional locators for resources -- again, that is expected to > be useful > > for DECADE. > > > > Looking forward, we envision that DECADE protocols may need additional > > parameters. Investigating this and specifying the parameters could be > done > > in DECADE (should we decide to re-charter for that). > > > > Please note that these two are individual submissions only -- i.e., > merely > > proposals that the group of authors are offering at this point. > > > > Nevertheless, we would be happy for any feedback. > > > > Best regards, > > > > Dirk > > > > > > > > > > _______________________________________________ > > decade mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/decade > _______________________________________________ > decade mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/decade > -- Website: http://hallambaker.com/
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
