[messaging] Affirmations // User attribute packets and resource location format

[Natanael]

Den 5 jan 2015 15:47 skrev "Vincent Breitmoser" <valodim at mugenguild.com>:
>
>
> (This mail is a follow-up to its replied-to mail :)
>
> As mentioned, a user attribute packet is certified the same way a user id
> is. This means we get certification including a timestamp for free, so
the only
> actual content we need in the user attribute is *where* the resource is
located,
> and possibly parameters on *how* to access it.
>
> An important aspect here is that a client will in most cases require
specialized
> support for a resource type, like parsing a tweet from twitter, a gist
from
> github, or reading a dns record. One way to refer to different resources
would
> be by introducing a type registry and have a parametrized packet
structure for
> each. This would be inflexible and difficult to standardize though, I
think
> having human readability for unsupported resource types will aid ease of
> implementation, extensibility and lead to more transparent de facto
standards.
>
> The established way to refer to a resource on the web is a URI. A generic
URI
> will not do in this case though, because that does not include the
required
> semantic implication about specialized client support. A good example is
the
> direct uri to a tweet on twitter, where the user only has partial control
since
> replies are shown on the page as well - a generic "parse page and look if
the
> data I want is there" mechanism will not suffice. My proposal is a new URI
> scheme which bears this exact semantic, and supports additional
parameters:
>
> pgpid = "pgpid" ":" [options] "@" <absolute-URI>
> options = ( option / flag ) [";" options]
> option = key "=" value
> flag = key
> key = *(ALPHA / DIGIT)
> value = *(<unreserved> / <percent-encoded> / ",")

What about data in locations without a defined URI format? I'm mainly
thinking of profile entries in the Namecoin blockchain here, and other such
lookup systems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150105/49844d2a/attachment.html>