Discovery Coordination Report, Dec 5th 2008
[Originally posted to the Metadata Discovery Coordination Group] * Link Relations and HTTP Header Linking Document: http://tools.ietf.org/html/draft-nottingham-http-link-header-03 Author: Mark Nottingham List: [EMAIL PROTECTED] Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ Org: IETF The Link draft revives the RFC 2068 Link header, as well as attempts to standardize link relationships between HTTP, HTML, and ATOM. The recently published revision of the spec switched the focus from the HTTP Link header to 'typed link relationships'. The new draft inspired an active debate on the list with focus on the following topics: - Relationship between 'rel' and 'rev' and their semantic meaning - The authoritative nature of the Link header and various attributes - The context of the link to be between 'representation->resource' or 'resource->resource' (or even 'representation->representation') The link concept is the most fundamental building block for discovery. With the draft taking a wider focus on typed links in general, not just the HTTP header, this work is now positioned as the centerpiece of the discovery discussion. A -04 draft is expected soon. * /site-meta: Site-Wide Metadata for the Web Document: http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-00.txt Authors: Mark Nottingham, Eran Hammer-Lahav List: [EMAIL PROTECTED] Archive: http://lists.w3.org/Archives/Public/www-talk/ Org: IETF /site-meta provides a known-location-based solution for providing site-wide metadata. In practice this translate into a list of links for a given website at the authority level (domain name). Some view this solution as a registry to avoid new known-location solution by creating one final known-location document. The /site-meta proposal came out of multiple discussions and as a result of trying to solve the 'dynamic mapping' option explained in 'Discovery and HTTP' [1]. Dynamic mapping is the idea of proving a map or template that can transform a resource URI to its descriptor URI. A map is simply a template-based link where the linked resource URI is generated using a template language instead of being explicitly specified. The overall idea is tightly coupled with typed links. The discussion about /site-meta is currently focused on: - The authority an HTTP server in general and /site-meta in particular have to provide descriptors/metadata about non-HTTP URIs. This is related to the OpenID use case of wanting to use email addresses (mailto URIs) as identity identifiers which requires a way to obtain a resource descriptor (currently OpenID uses the XRDS format) from a non-HTTP URI. - The document format of /site-meta. The -00 draft defines a new and very simple XML-based schema. A proposal has been made to use a simple one-link-per-line text format instead. - The mechanism in which /site-meta will support URI templates (template-based links). The discussion is in its early stage and will focus on whether /site-meta should allow such links (at all), simply enable the use case through future extensions (not prevent it), or directly address the use case. - Should there be a fallback mechanism when failing to obtain the /site-meta document for example.com to www.example.com. Consensus seems to be that this is an application specific need and not part of the generic solution. * Uniform Access to Information About Document: http://www.w3.org/2001/tag/doc/more-uniform-access.html Author: Jonathan Rees List: [EMAIL PROTECTED] Archive: http://lists.w3.org/Archives/Public/www-tag/ Org: W3C The W3C TAG (Technical Architecture Group) is scheduled to hold a face-to-face meeting Dec 9-11 in Cambridge, MA. This draft has been submitted as the basis for discussion on the topic of locating 'information about' resources. The work originated from past discussions related to the POWDER specification from the W3C (see below). The TAG is trying to address the discovery topic from a high-level architectural stand point which is usually different from the discussion over technical details (header format, parameter names, etc.). Such discussions tend to be more "philosophical" than implementation-based, which gives a great complimentary perspective to this work. The topics discussed in this draft: - Use of Link header and elements to identify the location of a resource descriptor (information about). - Relationship between the resource URI scheme and the use of HTTP for performing discovery itself. - Interaction with HTTP status codes. - Trust issues (authority and rights). The W3C TAG is expected to produce some written outcome from this upcoming discussion. It is not known at this point what level of output will be agreed-upon and produced and the timeline for that. * POWDER: Protocol for Web Description Resources Document: http://www.w3.org/TR/powder-dr/ Editors: Phil Archer, Kevin Smith, Andrea Perego List: [EMAIL PROTECTED] Archive: http://lists.w3.org/Archives/
RE: P&C Insurance Carriers
I would think the "membership" of Japan in P&C would be a different audience than in the US. Maybe we should keep the conversations separate but leverage the same "playbook". I do hope that the "vendors" on this forum would encourage their P&C insurance customers to participate as well... From: Nat Sakimura [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 7:40 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: P&C Insurance Carriers That sounds interesting. We have some member companies from P&C insurance in OpenID Japan as well, so I might able to cordinate something with you. =nat On Fri, Dec 5, 2008 at 4:31 AM, McGovern, James F (HTSC, IT) <[EMAIL PROTECTED]> wrote: I am attempting to put together a discussion amongst "employees" of P&C insurance carriers to discuss scenarios for using OpenID for independent insurance agents. Does anyone on this list know of employees at carriers that have an understanding at a technical level regarding OpenID? NOTE: I am not interested in turning this into a vendor lead generation mechanism. This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Nat Sakimura (=nat) http://www.sakimura.org/en/ This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
