Re: [websec] [decade] URIs for DECADE -- Named Information URI Scheme

[Phillip Hallam-Baker <[e-mail]>]

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 <[e-mail]>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:[e-mail]]
> > Sent: Mittwoch, 26. Oktober 2011 15:22
> > To: Dirk Kutscher; '[e-mail]'
> > Cc: '[e-mail]'; '[e-mail]';
> > '[e-mail]'; 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:[e-mail]]
> > Sent: Wednesday, October 26, 2011 09:06 AM
> > To: decade ietf <[e-mail]>
> > Cc: Christian Dannewitz       ([e-mail])
> <cdannewitz@uni-
> > paderborn.de>; Rob Stradling ([e-mail])
> > <[e-mail]>; [e-mail]
> > <[e-mail]>
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/decade
> _______________________________________________
> decade mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/decade
>



-- 
Website: http://hallambaker.com/