[Cap-Talk] Re: Is there a capability RFC?

[John Stracke]

"David L. Nicol" wrote, on a separate list but CC:ed to me:

> John Stracke wrote:
> >
> > "David L. Nicol" wrote:
> >
> > > it occurs to me
> > > that a Standard Capability Protocol (capabilities are 1024 bits long,
> > > they include time-stamps and encooded origin info in a standard way,
> >
> > Can you define "capability" better, please? I don't follow what you want it
> > for.
>
> "capability" is a robust method for delegating (and rescinding, and
> tracking)
> authority or all kinds.
>
> Not Authenticity, but Authority.
>
> X session cookies are a good example.  Another is the random codes that
> prevent
> fake mailing list subscriptions.  CGI session cookies too -- they are
> random
> strings of characters that give one the capability to use a particular
> shopping
> cart object.
>
> If iCal (or MIME, for that matter) had a standard CAPABILIT[Y|IES]: header
> built
> into it, I, as an operator of a calendar, could ask my calendar for some
> posting
> capabilities which would expire at the end of the year, and distribute
> these
> capabilities (they would look like PGP signatures -- you know, binary
> garbage)
> to the people who are authorized to list events on the calendar, and they
> would
> use capability-aware tools to submit the items to the calendar, which would
> include the capability, associated with the event they are sending in, and
> the
> calendar would check the capability, and if it is good, go ahead and list
> the event, and if it is not, the calendar would pass it on for moderating.
>
> I believe this is desired functionality which is not currently addressed by
> the standard, in fact it is explicitly delegated to the implementors.

And for good reason: the IETF generally avoids trying to do things that don't
have wide experience yet; it makes for working groups that trail off into death
spirals.

Implementers of the various iCalendar protocols can experiment with capabilities
on their own; if they turn out to be useful, then they can be standardized.

> Capabilities could become a framework for authorization interoperability.
>
> I am not suggesting that any of the flexiblity in designing arbitrarily
> complex authorization systems be taken from the implementors; I am merely
> suggesting that specifying a place for such information to go, if it is
> used in an implementation, would ease interoperability.
>
> Since a general purpose authority delegation scheme is larger than
> calendaring
> (standardizing VERPs comes to mind as another possibility -- a VAriable
> Envelope
> Return Path could be considered as a Capability that allows a MTA,
> "exercising
> it" by bouncing a mail to the address, to unambiguously report a problem
> with
> a particular address) I think an RFC on incorporating them into MIME, which
> would then get inherited by all projects that rely on MIME, would be a
> better
> solution than including them in the iCalendar project.
>
> Including them in the iCalendar project, and expecting them to get
> back-ported
> into MIME, makes sense too.
>
> --
>                                            David Nicol 816.235.1187
>                    "Perl was born in downtown Hell!" -- Matt Youell

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |We want forty million helicopters and a dollar!|
|francis@ecal.com|--"Dinosaurs"                                  |
\================================================================/