Subject: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host Metadata) to Proposed Standard

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Jul 2010 10:17:44 -0600

FYI.

-------- Original Message --------
Subject: Last Call: draft-hammer-hostmeta (Web Host Metadata) to
Proposed	Standard
Date: Fri, 25 Jun 2010 05:30:41 -0700 (PDT)
From: The IESG <[email-masked]>
Reply-To: [email-masked]
To: IETF-Announce <[email-masked]>

The IESG has received a request from an individual submitter to consider
the following document:

- 'Web Host Metadata '
   <draft-hammer-hostmeta-13.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2010-07-23. Exceptionally,
comments may be sent to [email-masked] instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-hammer-hostmeta-13.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19329&rfc_flag=0

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Blaine Cook <[email-masked]>
Date: Fri, 23 Jul 2010 15:37:36 +0100

Sneaking in under the wire with these comments, which I'm sure will
exact punishment from Eran at some later point (though I have made
these comments unofficially in other venues).

I strongly disagree with the processing model for LRDD proposed in
Section 4.2 of draft-hammer-hostmeta-13. The model amounts to a
client-side approach to template processing. I believe this will lead
to inconsistent (i.e., non-interoperable) results across client
implementations, is harder to implement for client developers, and
adds complexity for server administrators and implementors.

By way of comparison, HTML *could* have client-side include operators
(indeed, it does - the <object> tag can be used to include other HTML
documents), but the web at large has spoken - server-side templating
has totally won. What is the justification for doing client-side
includes here?

My alternate proposal:

1. All <link>s present in the host-meta document apply to the host
unless the link is a template.
2. If the <link> is a template, the semantics of that template are
defined by the rel type.
3. The "lrdd" rel type means "a template URL providing arbitrary
metadata about the substituted entity in XRD format" (perhaps "meta"
would be a better rel than "lrdd", since it's host-meta, not
host-lrdd).

As for link inclusion, I would argue that any ordering outside of a
document-level ordering is completely impossible to enforce. Metadata
resolution and inclusion should happen by descent only, and then only
within the context of a single entity (i.e., a template URL marks the
boundary between host-meta and a host-bound URL; links discovered in
host-meta do not apply to links discovered in the template URL).

If site owners want a link to apply across all hosted profiles, they
can include that link in the document served up at the template URL.

I believe this approach simplifies the host-meta draft, as well as the
processing rules, while not removing any functionality.

b.

On 1 July 2010 17:17, Peter Saint-Andre <[email-masked]> wrote:
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 23 Jul 2010 13:12:15 -0700

Host-meta includes two discovery mechanisms:

- host-wide - metadata about the "host" in general
- resource-specific - metadata about an individual resource under the control of the "host"

To accomplish this, host-meta defines clear semantic meanings to links:

- <Link> elements with an 'href' attribute are host-wide
- <Link> elements with a 'template' attribute are resource-specific

In addition, since there are cases where resource-specific information cannot be expressed using a template, host-meta provides a link relation type 'lrdd' which means 'additional links and metadata available here'. Because link templates in host-meta have the same context-URI as links in a LRDD document (obtained using the same resource URI), they are semantically equivalent.

In addition, XRD documents require processing links in document order.

The processing rules defined in section 4 do nothing more than apply this to provide a uniform and clearly stated client behavior:

- Since link templates in host-meta are equivalent to those in LRDD documents, LRDD documents are treated as an 'include' directive when processing host-meta.
- Since XRD documents have a prescribed order, and 'lrdd' link templates are treated just like any other link (in terms of priority), constructing a full resource descriptor requires combining links from multiple source in order.

Section 4.2 is written for clients looking for the complete resource descriptor, collected from potentially multiple documents (host-meta and one or more LRDD documents). However, the introduction in section 4 clearly states:

   Clients usually look for a link with a specific relation type or
   other attributes.  In such cases, the client does not need to process
   the entire host-meta document and all linked LRDD documents, but
   instead, process the various documents in their prescribed order
   until the desired information is found.

Which means clients are not required to construct a complete resource descriptor when they are looking for a single link (the most common use case). This significantly simplifies the processing.

** If this is not clear, I am happy to make it more explicit in section 4.2, including adding a full procedure for clients looking for a specific link.

The current processing rules of section 4.2 are nothing more than stating the logical conclusion derived from the rules set by host-meta and XRD (as explained above).

However, if people would like to simplify this a bit, I am open to (but not excited about) making a small change in which clients will first look for (any) 'lrdd' link templates, process them, and only then look for other link-templates in host-meta. This exception will deviate from the normal XRD processing rules of document order, but will move from a potential complex mix from link sources to a two stage procedure (LRDD links, then host-meta link templates). Note that this does not solve the basic requirement to construct the full resource descriptor from multiple location, only the order in which that is done.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Blaine Cook
> Sent: Friday, July 23, 2010 7:38 AM
> To: [email-masked]
> Subject: Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web
> Host Metadata) to Proposed Standard
> 
> Sneaking in under the wire with these comments, which I'm sure will exact
> punishment from Eran at some later point (though I have made these
> comments unofficially in other venues).
> 
> I strongly disagree with the processing model for LRDD proposed in Section
> 4.2 of draft-hammer-hostmeta-13. The model amounts to a client-side
> approach to template processing. I believe this will lead to inconsistent (i.e.,
> non-interoperable) results across client implementations, is harder to
> implement for client developers, and adds complexity for server
> administrators and implementors.
> 
> documents), but the web at large has spoken - server-side templating has
> totally won. What is the justification for doing client-side includes here?
> 
> My alternate proposal:
> 
> 1. All <link>s present in the host-meta document apply to the host unless the
> link is a template.
> 2. If the <link> is a template, the semantics of that template are defined by
> the rel type.
> 3. The "lrdd" rel type means "a template URL providing arbitrary metadata
> about the substituted entity in XRD format" (perhaps "meta"
> would be a better rel than "lrdd", since it's host-meta, not host-lrdd).
> 
> As for link inclusion, I would argue that any ordering outside of a document-
> level ordering is completely impossible to enforce. Metadata resolution and
> inclusion should happen by descent only, and then only within the context of
> a single entity (i.e., a template URL marks the boundary between host-meta
> and a host-bound URL; links discovered in host-meta do not apply to links
> discovered in the template URL).
> 
> If site owners want a link to apply across all hosted profiles, they can include
> that link in the document served up at the template URL.
> 
> > The IESG has received a request from an individual submitter to
> > consider the following document:
> >
> > - 'Web Host Metadata '
> > final comments on this action.  Please send substantive comments to
> > the [email-masked] mailing lists by 2010-07-23. Exceptionally, comments
> > may be sent to [email-masked] instead. In either case, please retain
> > the beginning of the Subject line to allow automated sorting.
> >

---

From: Blaine Cook <[email-masked]>
Date: Sat, 24 Jul 2010 01:15:47 +0100

> ** If this is not clear, I am happy to make it more explicit in section 4.2, including adding a full procedure for clients looking for a specific link.

+1 - In my reading of 4.2, I had overlooked the sentence in 4 that
describes stopping whenever a suitable link relation is found. With
that processing rule in place, the semantic is clear and simple.

> However, if people would like to simplify this a bit, I am open to (but not excited about) making a small change in which clients will first look for (any) 'lrdd' link templates, process them, and…

I'm not sure what others think about this, but I personally prefer
this approach (LRDD-first, followed by host-level templates). The
reasoning is that this gives LRDD profiles the ability to over-ride
host-level decisions, whereas strictly following document ordering
means that hosts could potentially force all users to use a single URL
for a given rel value.

The challenge is not so much that the hosts could force this (because
a "malicious" host could over-write the rel value in ever user's LRDD
document), but that interop becomes more challenging since any parser
that does LRDD-first *might* disagree with a strictly ordered parser
(an example where this is a real possibility: three parsers, one
SAX-based, one XPath based, and one DOM-based, may come up with very
different results if we rely on document ordering alone).

b.

---

From: John Panzer <[email-masked]>
Date: Fri, 23 Jul 2010 18:36:31 -0700

That's also why I don't see "stop when you see the rel you're looking
for" as a big help - you actually are looking for a collection where
rel=x in the general case (think rel=alternate for a common example
from other formats).  So you have to get the set of links in some
context, which could be the host-meta document or the target of the
lrdd template.

But in general I agree with Blaine's primary objection; this adds an
include model that has not been proven and which forces clients to
provision for a nearly arbitrary number of worst-case http fetches.

Query:  Is it at least possible for a server to automatically merge
multiple rel=lrdd targets and serve up a single composite rel=lrdd
target resource to clients without impacting semantics?  It's not
clear to me from the spec.

-- 
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer