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 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.
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.
The POWDER protocol has been created 'to provide a means for individuals or organizations to describe a group of resources through the publication of machine-readable metadata'. While using a completely different descriptor format from XRDS and its own set of use cases, the overall design and flow are similar.
The parts of POWDER that are most relevant to this discussion, and should be reviewed by those interested in this work are:
The OASIS XRI TC has recently decided to spin-off its discovery protocol XRDS from the XRI specifications. The current effort is to define and position XRD (the new name for what has been previously known as XRID, XRDS, XRDS-Simple, and Yadis) as a generic discovery protocol for URIs. XRD is planned to cover the mechanism used to locate the retrieve the resource descriptor, the document format for that descriptor, and a trust and security mechanism.
Topics recently / currently being discussed:
- Review of existing and proposed trust solutions, including digital signatures and certificates. - Simplification of the XRDS schema as currently specified [3]. - Replacement of the xri:// scheme for XML namespaces with an http://oasis/... URI. - Delegation functionality for entire descriptor or select services. - Replacement of current Yadis-based workflow (X-XRDS-Location header, <meta> element, Accept Header) with Link and /site-meta.
While the official XRD work is done on a members-only mailing list, much of the work directly derives and depends on public discussions. Everything listed in this report is taken as input and as the basis for XRD 1.0. Non-members are free to participate via the 'xri-comment' list which is open to non-members.
OpenID Authentication 2.0, the latest version of the OpenID protocol includes both directly and via normative references a discovery protocol for obtaining identity related metadata from an HTTP(S) URI, or an XRI. With the recent consolidation of the various discovery discussions and the efforts of the (now closed) XRDS-Simple community, it has been suggested that the entire OpenID discovery workflow be reviewed for a potential update.
The current effort is focused on finalizing and approving a working group charter to review and potentially update how OpenID discovery works. Until a new working-group specific mailing list is created, the generic specs list should be used for such discussions. OpenID is considered a top priority use case for XRD.
While not directly related to discovery, URI templates have been positioned as a potential key component of the proposed solution via the /site-meta approach. The current I-D has expired and it is not clear its status moving forward. The proposal has raised a number of significant issues and has yet to achieve a wide enough consensus to move forward. In addition, an alternative has been suggested [4] which may be used as the basis of a new (perhaps competing) proposal. To be clear, all the statements made in this paragraph are my personal interpretation of the situation and do not represent the views of any of the authors or others involved.
If /site-meta will remain part of the proposed discovery architecture, and no stable URI template proposal is available in time for the various efforts to use, it is expected that a simple format be directly specified by the XRD or /site-meta specification. For the sake of completion, the OpenSearch specification also includes a URI template proposal [5] worth considering.
This report is part of an effort to better coordinate the various ongoing efforts happening in the discovery space as it relates to resource descriptors. As is evident from this report, the list of parallel efforts is long and for many people hard to follow. It is especially hard for newcomers to figure out where discussions are happening. It will be updated as new development justify it.
> 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 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.
> 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
> The POWDER protocol has been created 'to provide a means for individuals or
> organizations to describe a group of resources through the publication of
> machine-readable metadata'. While using a completely different descriptor
> format from XRDS and its own set of use cases, the overall design and flow
> are similar.
> The parts of POWDER that are most relevant to this discussion, and should
> be reviewed by those interested in this work are:
> The OASIS XRI TC has recently decided to spin-off its discovery protocol
> XRDS from the XRI specifications. The current effort is to define and
> position XRD (the new name for what has been previously known as XRID, XRDS,
> XRDS-Simple, and Yadis) as a generic discovery protocol for URIs. XRD is
> planned to cover the mechanism used to locate the retrieve the resource
> descriptor, the document format for that descriptor, and a trust and
> security mechanism.
> Topics recently / currently being discussed:
> - Review of existing and proposed trust solutions, including digital
> signatures and certificates.
> - Simplification of the XRDS schema as currently specified [3].
> - Replacement of the xri:// scheme for XML namespaces with an
> http://oasis/... URI.
> - Delegation functionality for entire descriptor or select services.
> - Replacement of current Yadis-based workflow (X-XRDS-Location header,
> <meta> element, Accept Header) with Link and /site-meta.
> While the official XRD work is done on a members-only mailing list, much of
> the work directly derives and depends on public discussions. Everything
> listed in this report is taken as input and as the basis for XRD 1.0.
> Non-members are free to participate via the 'xri-comment' list which is open
> to non-members.
> OpenID Authentication 2.0, the latest version of the OpenID protocol
> includes both directly and via normative references a discovery protocol for
> obtaining identity related metadata from an HTTP(S) URI, or an XRI. With the
> recent consolidation of the various discovery discussions and the efforts of
> the (now closed) XRDS-Simple community, it has been suggested that the
> entire OpenID discovery workflow be reviewed for a potential update.
> The current effort is focused on finalizing and approving a working group
> charter to review and potentially update how OpenID discovery works. Until a
> new working-group specific mailing list is created, the generic specs list
> should be used for such discussions. OpenID is considered a top priority use
> case for XRD.
> While not directly related to discovery, URI templates have been positioned
> as a potential key component of the proposed solution via the /site-meta
> approach. The current I-D has expired and it is not clear its status moving
> forward. The proposal has raised a number of significant issues and has yet
> to achieve a wide enough consensus to move forward. In addition, an
> alternative has been suggested [4] which may be used as the basis of a new
> (perhaps competing) proposal. To be clear, all the statements made in this
> paragraph are my personal interpretation of the situation and do not
> represent the views of any of the authors or others involved.
> If /site-meta will remain part of the proposed discovery architecture, and
> no stable URI template proposal is available in time for the various efforts
> to use, it is expected that a simple format be directly specified by the XRD
> or
> 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 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.
> 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
> The POWDER protocol has been created 'to provide a means for individuals
> or organizations to describe a group of resources through the publication
> of machine-readable metadata'. While using a completely different
> descriptor format from XRDS and its own set of use cases, the overall
> design and flow are similar.
> The parts of POWDER that are most relevant to this discussion, and should
> be reviewed by those interested in this work are:
> The OASIS XRI TC has recently decided to spin-off its discovery protocol
> XRDS from the XRI specifications. The current effort is to define and
> position XRD (the new name for what has been previously known as XRID,
> XRDS, XRDS-Simple, and Yadis) as a generic discovery protocol for URIs.
> XRD is planned to cover the mechanism used to locate the retrieve the
> resource descriptor, the document format for that descriptor, and a trust
> and security mechanism.
> Topics recently / currently being discussed:
> - Review of existing and proposed trust solutions, including digital
> signatures and certificates.
> - Simplification of the XRDS schema as currently specified [3].
> - Replacement of the xri:// scheme for XML namespaces with an
> http://oasis/... URI.
> - Delegation functionality for entire descriptor or select services.
> - Replacement of current Yadis-based workflow (X-XRDS-Location header,
> <meta> element, Accept Header) with Link and /site-meta.
> While the official XRD work is done on a members-only mailing list, much
> of the work directly derives and depends on public discussions. Everything
> listed in this report is taken as input and as the basis for XRD 1.0. Non-
> members are free to participate via the 'xri-comment' list which is open
> to non-members.
> OpenID Authentication 2.0, the latest version of the OpenID protocol
> includes both directly and via normative references a discovery protocol
> for obtaining identity related metadata from an HTTP(S) URI, or an XRI.
> With the recent consolidation of the various discovery discussions and the
> efforts of the (now closed) XRDS-Simple community, it has been suggested
> that the entire OpenID discovery workflow be reviewed for a potential
> update.
> The current effort is focused on finalizing and approving a working group
> charter to review and potentially update how OpenID discovery works. Until
> a new working-group specific mailing list is created, the generic specs
> list should be used for such discussions. OpenID is considered a top
> priority use case for XRD.
> While not directly related to discovery, URI templates have been
> positioned as a potential key component of the proposed solution via the
> /site-meta approach. The current I-D has expired and it is not clear its
> status moving forward. The proposal has raised a number of significant
> issues and has yet to achieve a wide enough consensus to move forward. In
> addition, an alternative has been suggested [4] which may be used as the
> basis of a new (perhaps competing) proposal. To be clear, all the
> statements made in this paragraph are my personal interpretation of
I agree. Robin Cover has been doing a similar thing for XML and related
technologies for years, and its really a one-stop-shop these days (he
includes many, if not all, of the specs here might be interested in as
well):
> > 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 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.
> > 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
> > The POWDER protocol has been created 'to provide a means for individuals
> > or organizations to describe a group of resources through the publication
> > of machine-readable metadata'. While using a completely different
> > descriptor format from XRDS and its own set of use cases, the overall
> > design and flow are similar.
> > The parts of POWDER that are most relevant to this discussion, and should
> > be reviewed by those interested in this work are:
> > The OASIS XRI TC has recently decided to spin-off its discovery protocol
> > XRDS from the XRI specifications. The current effort is to define and
> > position XRD (the new name for what has been previously known as XRID,
> > XRDS, XRDS-Simple, and Yadis) as a generic discovery protocol for URIs.
> > XRD is planned to cover the mechanism used to locate the retrieve the
> > resource descriptor, the document format for that descriptor, and a trust
> > and security mechanism.
> > Topics recently / currently being discussed:
> > - Review of existing and proposed trust solutions, including digital
> > signatures and certificates.
> > - Simplification of the XRDS schema as currently specified [3].
> > - Replacement of the xri:// scheme for XML namespaces with an
> > http://oasis/... URI.
> > - Delegation functionality for entire descriptor or select services.
> > - Replacement of current Yadis-based workflow (X-XRDS-Location header,
> > <meta> element, Accept Header) with Link and /site-meta.
> > While the official XRD work is done on a members-only mailing list, much
> > of the work directly derives and depends on public discussions.
> Everything
> > listed in this report is taken as input and as the basis for XRD 1.0.
> Non-
> > members are free to participate via the 'xri-comment' list which is open
> > to non-members.
> > OpenID Authentication 2.0, the latest version of the OpenID protocol
> > includes both directly and via normative references a discovery protocol
> > for obtaining identity related metadata from an HTTP(S) URI, or an XRI.
> > With the recent consolidation of the various discovery discussions and
> the
> > efforts of the (now closed) XRDS-Simple community, it has been suggested
> > that the entire OpenID discovery workflow be reviewed for a potential
> > update.
> > The current effort is focused on finalizing and approving a working group
> > charter to review and potentially update how OpenID discovery works.
> Until
> > a new working-group specific mailing list is created, the generic specs
> > list should be used for such discussions. OpenID is considered a top
> > priority use case for XRD.
Eran,
This is great, its good to get a refresh on whats going on out there
as things tend to thread out in different directions. I also recently
wrote up a piece on how decentralized discovery fits into a future web
ecology [1], and I'll be and sure and include this writeup and its
information in my next writeup on XRD 1.0 specifically.
> 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 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 towww.example.com. Consensus seems to be that this is an application specific need and not part of the generic solution.
> 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
> The POWDER protocol has been created 'to provide a means for individuals or organizations to describe a group of resources through the publication of machine-readable metadata'. While using a completely different descriptor format from XRDS and its own set of use cases, the overall design and flow are similar.
> The parts of POWDER that are most relevant to this discussion, and should be reviewed by those interested in this work are:
> The OASIS XRI TC has recently decided to spin-off its discovery protocol XRDS from the XRI specifications. The current effort is to define and position XRD (the new name for what has been previously known as XRID, XRDS, XRDS-Simple, and Yadis) as a generic discovery protocol for URIs. XRD is planned to cover the mechanism used to locate the retrieve the resource descriptor, the document format for that descriptor, and a trust and security mechanism.
> Topics recently / currently being discussed:
> - Review of existing and proposed trust solutions, including digital signatures and certificates.
> - Simplification of the XRDS schema as currently specified [3].
> - Replacement of the xri:// scheme for XML namespaces with anhttp://oasis/... URI.
> - Delegation functionality for entire descriptor or select services.
> - Replacement of current Yadis-based workflow (X-XRDS-Location header, <meta> element, Accept Header) with Link and /site-meta.
> While the official XRD work is done on a members-only mailing list, much of the work directly derives and depends on public discussions. Everything listed in this report is taken as input and as the basis for XRD 1.0. Non-members are free to participate via the 'xri-comment' list which is open to non-members.
> OpenID Authentication 2.0, the latest version of the OpenID protocol includes both directly and via normative references a discovery protocol for obtaining identity related metadata from an HTTP(S) URI, or an XRI. With the recent consolidation of the various discovery discussions and the efforts of the (now closed) XRDS-Simple community, it has been suggested that the entire OpenID discovery workflow be reviewed for a potential update.
> The current effort is focused on finalizing and approving a working group charter to review and potentially update how OpenID discovery works. Until a new working-group specific mailing list is created, the generic specs list should be used for such discussions. OpenID is considered a top priority use case for XRD.
> While not directly related to discovery, URI templates have been positioned as a potential key component of the proposed solution via the /site-meta approach. The current I-D has expired and it is not clear its status moving forward. The proposal has raised a number of significant issues and has yet to achieve a wide enough consensus to move forward. In addition, an alternative has been suggested [4] which may be used as the basis of a new (perhaps competing) proposal. To be clear, all the statements made in this paragraph are my personal interpretation of the situation and do not represent the views of any of the authors or others involved.
> If /site-meta will remain part of the proposed discovery architecture, and no stable URI template proposal is available in time for the various efforts to use, it is expected that a simple format
|
