ietf
[Top] [All Lists]

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

2011-07-05 10:29:04
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 <eran(_at_)hueniverse(_dot_)com>
To: Hannes Tschofenig <hannes(_dot_)tschofenig(_at_)gmx(_dot_)net>; Mark 
Nottingham <mnot(_at_)mnot(_dot_)net>
Cc: "ietf(_at_)ietf(_dot_)org IETF" <ietf(_at_)ietf(_dot_)org>; oauth WG 
<oauth(_at_)ietf(_dot_)org>
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,

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 <hannes(_dot_)tschofenig(_at_)gmx(_dot_)net>
Date:  Sun, 3 Jul 2011 00:36:29 -0700
To:  Mark Nottingham <mnot(_at_)mnot(_dot_)net>
Cc:  Hannes Tschofenig <hannes(_dot_)tschofenig(_at_)gmx(_dot_)net>, 
"ietf(_at_)ietf(_dot_)org IETF" <ietf(_at_)ietf(_dot_)org>, Eran Hammer-lahav 
<eran(_at_)hueniverse(_dot_)com>, oauth WG <oauth(_at_)ietf(_dot_)org>
Subject:  Re: Second Last Call: <draft-hammer-hostmeta-16.txt> (Web Host 
Metadata) to Proposed Standard -- feedback


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.




_______________________________________________
OAuth mailing list
OAuth(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf