[foaf-protocols] implementation specific discussion on webid; azure service bus

[Kingsley Idehen]

On 3/16/11 7:12 PM, peter williams wrote:
>
> Below, I say "Being atom, content types of various types can accompany 
> the URI."
>
> In Atom, can the content attached to a URI be a MIME 
> multipart/alternative content type? ...such that to one URI might be 
> bound in the atom stream 3 alternative streams of metadata: (i) the 
> openid file (with microformats), (ii) the foaf card, (iii) the XRD for 
> hammarstack markup?
>

See: http://tools.ietf.org/html/rfc4287

Excerpt:

atomInlineOtherContent =
       element atom:content {
          atomCommonAttributes,
          attribute type { atomMediaType }?,
          (text|anyElement)*
       }

    atomOutOfLineContent =
       element atom:content {
          atomCommonAttributes,
          attribute type { atomMediaType }?,
          attribute src { atomUri },
          empty
       }

    atomContent = atomInlineTextContent
     | atomInlineXHTMLContent
     | atomInlineOtherContent
     | atomOutOfLineContent

4.1.3.1.  The "type" Attribute

    On the atom:content element, the value of the "type" attribute MAY be
    one of "text", "html", or "xhtml".  Failing that, it MUST conform to
    the syntax of a MIME media type, but MUST NOT be a composite type
    (see Section 4.2.6 of [MIMEREG]).  If neither the type attribute nor
    the src attribute is provided, Atom Processors MUST behave as though
    the type attribute were present with a value of "text".



Kingsley
>
> *From:*peter williams [mailto:home_pw at msn.com]
> *Sent:* Wednesday, March 16, 2011 12:18 PM
> *To:* foaf-protocols at lists.foaf-project.org
> *Subject:* implementation specific discussion on webid; azure service bus
>
> What does it have going for it?
>
> It has client-certs, with SAN-URIs.
>
> The URI is discoverable on the web, using atom
>
> Being atom, content types of various types can accompany the URI.
>
> Presumably, this could include a foaf card.
>
> Thus, the azure service bus could offer a way to deliver a million 
> foaf+ssl capabilities to a million folks, using the "remoting 
> concept". The resources they interact with would leverage the 
> server-side of the bus as the client side of the web.
>
> Obviously, everything in reality is spyable. But, its better than the 
> web (where folks pretend it's all end-end https, but it is rarely due 
> to the way https CONNECT proxies and https SSL MITM agents really work).
>
> Ok. I think I have an experiment thesis, a testable condition, and an 
> interesting implementation concept. Since I have to learn to program 
> the service bus anyways (to comprehend the role of this latest year's 
> token blobs), I might as well play with it in the FOAF+SSL/webid 
> sense. I can understand better how folks in the token world impose 
> delegation semantics on a server (now acting as client) -- which is 
> consistent with an W3C webid IX issue anyways.
>
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20110316/742239a1/attachment-0001.htm