Subject: Re: Second Last Call: <draft-hammer-hostmeta-16.txt> (Web Host Metadata) to Proposed Standard -- feedback

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 3 Jul 2011 10:36:29 +0300

I also never really understood why XRD was re-used. 

Btw, XRD is not used by any of the current OAuth WG documents, see http://datatracker.ietf.org/wg/oauth/

On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote:

> * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm just scarred by WS-*, but it seems very over-engineered for what it does. I understand that the communities had reasons for using it to leverage an existing user base for their specific user cases, but I don't see any reason to generalise such a beast into a generic mechanism.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 3 Jul 2011 09:50:58 -0700

Hannes,

None of the current OAuth WG document address discovery in any way, so clearly there will be no use of XRD. But the OAuth community predating the IETF had multiple proposals for it. In addition, multiple times on the IETF OAuth WG list, people have suggested using host-meta and XRD for discovery purposes.

The idea that XRD was reused without merit is both misleading and mean-spirited. Personally, I'm sick of it, especially coming from standards professionals.

XRD was largely developed by the same people who worked on host-meta. XRD predated host-meta and was designed to cover the wider use case. Host-meta was an important use case when developing XRD in its final few months. It was done in OASIS out of respect to proper standards process in which the body that originated a work (XRDS) gets to keep it.

I challenge anyone to find any faults with the IPR policy or process used to develop host-meta in OASIS.

XRD is one of the simplest XML formats I have seen. I bet most of the people bashing it now have never bothered to read it. At least some of these people have been personally invited by me to comment on XRD while it was still in development and chose to dismiss it.

XRD was designed in a very open process with plenty of community feedback and it was significantly simplified based on that feedback. In addition, host-meta further simplifies it by profiling it down, removing some of the more complex elements like Subject and Alias (which are very useful in other contexts). XRD is nothing more than a cleaner version of HTML <LINK> elements with literally a handful of new elements based on well defined and widely supported requirements. It's entire semantic meaning is based on the IETF Link relation registry RFC.

There is something very disturbing going on these days in how people treat XML-based formats, especially form OASIS.

When host-meta's predecessor - side–meta – was originally proposed a few years ago, Mark Nottingham proposed an XML format not that different from XRD. There is nothing wrong with JSON taking over as a simpler alternative. I personally prefer JSON much better. But it would be reckless and counter productive to ignore a decade of work on XML formats just because it is no longer cool. Feels like we back in high school.

If you have technical arguments against host-meta, please share. But if your objections are based on changing trends, dislike of XML or anything OASIS, grow up.

EHL

From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Date: Sun, 3 Jul 2011 00:36:29 -0700
To: Mark Nottingham <[email-masked]<mailto:[email-masked]>>
Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]> IETF" <[email-masked]<mailto:[email-masked]>>, Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>, oauth WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Second Last Call: <draft-hammer-hostmeta-16.txt> (Web Host Metadata) to Proposed Standard -- feedback

---

From: "William J. Mills" <[email-masked]>
Date: Sun, 3 Jul 2011 11:01:55 -0700 (PDT)

FYI there is a form of discovery for OAuth defined in http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth-02 which uses LINK headers.

________________________________
From: Eran Hammer-Lahav <[email-masked]>
To: Hannes Tschofenig <[email-masked]>; Mark Nottingham <[email-masked]>
Cc: "[email-masked] IETF" <[email-masked]>; oauth WG <[email-masked]>
Sent: Sunday, July 3, 2011 9:50 AM
Subject: Re: [OAUTH-WG] Second Last Call: <draft-hammer-hostmeta-16.txt> (Web Host Metadata) to Proposed Standard -- feedback

Hannes,

EHL

From:  Hannes Tschofenig <[email-masked]>
Date:  Sun, 3 Jul 2011 00:36:29 -0700
To:  Mark Nottingham <[email-masked]>
Cc:  Hannes Tschofenig <[email-masked]>, "[email-masked] IETF" <[email-masked]>, Eran Hammer-lahav <[email-masked]>, oauth WG <[email-masked]>
Subject:  Re: Second Last Call: <draft-hammer-hostmeta-16.txt> (Web Host Metadata) to Proposed Standard -- feedback

>* XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm just scarred by WS-*, but it seems very over-engineered for what it does. I understand that the communities had reasons for u…
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Tue, 5 Jul 2011 09:22:09 -0400

The OpenID Connect folks have been using Simple Web Discovery, which is
as I understand it a rough translation of XRD into JSON, with a couple
of simplifying changes. (Mike, want to throw your hat in on this one?)

http://tools.ietf.org/html/draft-jones-simple-web-discovery-00

 -- Justin

On Mon, 2011-07-04 at 00:27 -0400, Eve Maler wrote:
> FWIW, the "Dynamic OAuth Client Registration" proposal made by the
> User-Managed Access folks:
> 
> 
> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg-00
> 
> 
> ...makes use of XRD, hostmeta, and discovery, as does the OAuth-based
> UMA protocol itself:
> 
> 
> http://www.ietf.org/internet-drafts/draft-hardjono-oauth-umacore-00.txt
> 
> 
> We'd be just as happy to use a JSON-based version of XRD if it can be
> standardized, and we did do some experimentation with this early on.
> But because XRD 1.0 is now stable and is straightforward enough to use
> for our needs, we decided to use it normatively for now. The UMA
> implementation used by http://smartam.net implements this today and it
> works fine.
> 
> 
> Eve
> 
> On 3 Jul 2011, at 9:50 AM, Eran Hammer-Lahav wrote:
> 
> > Hannes,
> > 
> > 
> > None of the current OAuth WG document address discovery in any way,
> > so clearly there will be no use of XRD. But the OAuth community
> > predating the IETF had multiple proposals for it. In addition,
> > multiple times on the IETF OAuth WG list, people have suggested
> > using host-meta and XRD for discovery purposes.
> > 
> > 
> > The idea that XRD was reused without merit is both misleading and
> > mean-spirited. Personally, I'm sick of it, especially coming from
> > standards professionals.
> > 
> > 
> > XRD was largely developed by the same people who worked on
> > host-meta. XRD predated host-meta and was designed to cover the
> > wider use case. Host-meta was an important use case when developing
> > XRD in its final few months. It was done in OASIS out of respect to
> > proper standards process in which the body that originated a work
> > (XRDS) gets to keep it.
> > 
> > 
> > XRD is one of the simplest XML formats I have seen. I bet most of
> > the people bashing it now have never bothered to read it. At least
> > some of these people have been personally invited by me to comment
> > on XRD while it was still in development and chose to dismiss it.
> > 
> > 
> > XRD was designed in a very open process with plenty of community
> > feedback and it was significantly simplified based on that feedback.
> > In addition, host-meta further simplifies it by profiling it down,
> > removing some of the more complex elements like Subject and Alias
> > (which are very useful in other contexts). XRD is nothing more than
> > a cleaner version of HTML <LINK> elements with literally a handful
> > of new elements based on well defined and widely supported
> > requirements. It's entire semantic meaning is based on the IETF Link
> > relation registry RFC.
> > 
> > 
> > There is something very disturbing going on these days in how people
> > treat XML-based formats, especially form OASIS.
> > 
> > 
> > When host-meta's predecessor - side–meta – was originally proposed a
> > few years ago, Mark Nottingham proposed an XML format not that
> > different from XRD. There is nothing wrong with JSON taking over as
> > a simpler alternative. I personally prefer JSON much better. But it
> > would be reckless and counter productive to ignore a decade of work
> > on XML formats just because it is no longer cool. Feels like we back
> > in high school.
> > 
> > 
> > If you have technical arguments against host-meta, please share. But
> > if your objections are based on changing trends, dislike of XML or
> > anything OASIS, grow up.
> > 
> > 
> > EHL
> > 
> > 
> > 
> > 
> > 
> > 
> > Cc: Hannes Tschofenig <[email-masked]>, "[email-masked]
> > IETF" <[email-masked]>, Eran Hammer-lahav <[email-masked]>,
> > oauth WG <[email-masked]>
> > Subject: Re: Second Last Call: <draft-hammer-hostmeta-16.txt> (Web
> > Host Metadata) to Proposed Standard -- feedback
> > 
> > 
> > 
> > > > * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth.
> > > > Maybe I'm just scarred by WS-*, but it seems very
> > > > over-engineered for what it does. I understand that the
> > > > communities had reasons for using it to leverage an existing
> > > > user base for their specific user cases, but I don't see any
> > > > reason to generalise such a beast into a generic mechanism.
> > > 
> > > 
> > > 
> > > 
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>

---

From: Eve Maler <[email-masked]>
Date: Sun, 3 Jul 2011 21:27:36 -0700

FWIW, the "Dynamic OAuth Client Registration" proposal made by the User-Managed Access folks:

...makes use of XRD, hostmeta, and discovery, as does the OAuth-based UMA protocol itself:

We'd be just as happy to use a JSON-based version of XRD if it can be standardized, and we did do some experimentation with this early on. But because XRD 1.0 is now stable and is straightforward enough to use for our needs, we decided to use it normatively for now. The UMA implementation used by http://smartam.net implements this today and it works fine.

	Eve

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 12 Jul 2011 13:36:40 -0600

On 6/21/11 11:08 PM, Mark Nottingham wrote:
> Generally, it's hard for me to be enthusiastic about this proposal,
> for a few reasons. That doesn't mean it shouldn't be published, but I
> do question the need for it to be Standards Track as a general
> mechanism.

How about publishing it on the standards track but not as a general
mechanism (i.e., why not clarify when it is and is not appropriate)?

Clearly, both service providers (Google, Yahoo, etc.) and spec authors
(draft-hardjono-oauth-dynreg-00, draft-hardjono-oauth-umacore-00) have
found hostmeta somewhat useful in certain contexts.

RFC 2026 says:

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.

and:

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

The spec seems to be stable at this point, it's received significant
review, people seem to understand what it does and how it works, it's
had both implementation and operational experience, and it appears to
enjoy enough community interest to be considered valuable in certain
contexts. I also think it has resolved the design choices and solved the
requirements that it set out to solve, although you might be right that
it doesn't solve all of the problems that a more generic metadata
framework would need to solve.

As a result, it seems like a fine candidate for Proposed Standard, i.e.,
an entry-level document on the standards track that might be modified or
even retracted based on further experience.

> Mostly, it's because I hasn't really seen much discussion of it as a
> general component of the Web / Internet architecture; AFAICT all of
> the interest in it and discussion of it has happened in more
> specialised / vertical places. 

Again, perhaps we need to clarify that it is not necessarily a general
component of the web architecture, although it can be used to solve more
specific problems.

> The issues below are my concerns;
> they're not insurmountable, but I would have expected to see some
> discussion of them to date on lists like this one and/or the TAG list
> for something that's to be an Internet Standard.
> 
> 
> * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe
> I'm just scarred by WS-*, but it seems very over-engineered for what
> it does. I understand that the communities had reasons for using it
> to leverage an existing user base for their specific user cases, but
> I don't see any reason to generalise such a beast into a generic
> mechanism.

As discussed in responses to your message, XRD seems to have been an
appropriate tool for the job in this case. Whether XRD, too, is really a
general component of the web architecture is another question.

> * Precedence -- In my experience one of the most difficult parts of a
> metadata framework like this is specifying the combination of
> metadata from multiple sources in a way that's usable, complete and
> clear. Hostmeta only briefly mentions precedence rules in the
> introduction.

That could be something to work on if and when folks try to advance this
technology to the next maturity level (currently Draft Standard).

> * Scope of hosts -- The document doesn't crisply define what a "host"
> is.

This seems at least somewhat well-defined:

   a "host" is not a single resource but the entity
   controlling the collection of resources identified by Uniform
   Resource Identifiers (URI) with a common URI host [RFC3986].

That is, it references Section 3.2.2 of RFC 3986, which defines "host"
with some precision (albeit perhaps not "crisply").

> * Context of metadata -- I've become convinced that the most
> successful uses of .well-known URIs are those that have commonality
> of use; i.e., it makes sense to define a .well-known URI when most of
> the data returned is applicable to a particular use case or set of
> use cases. This is why robots.txt works well, as do most other
> currently-deployed examples of well-known URIs.
> 
> Defining a bucket for potentially random, unassociated metadata in a
> single URI is, IMO, asking for trouble; if it is successful, it could
> cause administrative issues on the server (as potentially many
> parties will need control of a single file, for different uses --
> tricky when ordering is important for precedence), and if the file
> gets big, it will cause performance issues for some use cases.

It would be helpful to hear from folks who have deployed hostmeta to
hear if they have run into any operational issues of the kind you
describe here.

> * Chattiness -- the basic model for resource-specfic metadata in
> hostmeta requires at least two requests; one to get the hostmeta
> document, and one to get the resource-specific metadata after
> interpolating the URI of interest into a template.
> 
> For some use cases, this might be appropriate; however, for many
> others (most that I have encountered), it's far too chatty. Many use
> cases find the latency of one extra request unacceptable, much less
> two. Many use cases require fetching metadata for a number of
> distinct resources; in this model, that adds a request per resource.
> 
> I'd expect a general solution in this space to allow describing a
> "map" of a Web site and applying metadata to it in arbitrary ways, so
> that a client could fetch the document once and determine the
> metadata for any given resource by examining it.

That sounds like good input to a more generic approach. Many discovery
protocols do seem to have an inherent chattiness about them, but you
might be right that ideally the round trips could be kept to a minimum.

> If hostmeta is designed for specific use cases and meets them well,
> that's great, but it shouldn't be sold as a general mechanism. So,
> I'm -1 on this going forward as a standards-track general mechanism.
> I wouldn't mind if it were Informational, or if it were
> Standards-Track but with a defined use case.

Again, I think some clarifying language about the applicability of the
technology is in order.

> Apologies for giving this feedback so late in the process; I knew
> hostmeta was there, just didn't have time to step back and think
> about it.

And my apologies for taking so long to reply.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jul 2011 22:06:08 +0200 (MEST)

> mechanism (i.e., why not clarify when it is and is not appropriate)?

How about publishing as Informational?

RFC 2026 says:

   4.  THE INTERNET STANDARDS TRACK

   Specifications that are intended to become Internet Standards evolve
   through a set of maturity levels known as the "standards track".
   These maturity levels -- "Proposed Standard", "Draft Standard", and
   "Standard" -- are defined and discussed in section 4.1.

If there is no strong consensus and commitment to work the document
along the standards track up to full standard, then it shouldn't
be on the standards track at all.

For documents where the only purpose of publishing it is only to obtain
an rfc number for it, but otherwise just describe "this is how others
have solved a particular problem before" and let vendors and implementors
wiggle out interop, then Informational is quite appropriate.

-Martin

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 13 Jul 2011 21:35:57 +1000

Personally, I think Informational is most appropriate (and probably easier), but a paragraph or two of context, as well as corresponding adjustments, would work as well. 

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 13 Jul 2011 15:26:47 -0600

> be on the standards track at all.

Who said there isn't strong consensus and commitment to work the
document along the standards track? The only statement I've seen is that
it's not a generic solution for all metadata problems.

> wiggle out interop, then Informational is quite appropriate.

I see no reason to make those assumptions here.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 13 Jul 2011 15:30:16 -0600

On 7/13/11 5:35 AM, Mark Nottingham wrote:
> Personally, I think Informational is most appropriate (and probably
> easier), but a paragraph or two of context, as well as corresponding
> adjustments, would work as well.

Personally I'm not wedded to Standards Track for this document, and
neither are the authors. I just want to make sure that there's a good
reason to change it from Standards Track to Informational. IMHO "this
document doesn't solve the problem in the most generic way" would
prevent us from publishing a rather large number of specifications on
the Standards Track. There's nothing evil about scoping a document so
that it solves a more particular problem.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 14 Jul 2011 11:22:53 -0600

Mark, I will work with the authors on proposed wording to describe the
context in which this technology is most applicable, and post again once
we've done that.