This is a very good suggestion, and I'll do just as requested in the
next few days. I am sorry if this has caused you any problems.

---

However, the general rule is that specs in their first few drafts (and
here we are talking first draft for XRDS-Simple and second draft for
OAuth Discovery - both VERY premature) are considered highly unstable
and meant only for experimental usage. One thing I have learned from
the IETF process is to put an explicit expiration date on drafts so
that it will be clear they should not be used after a certain date.
IETF gives 6 months for drafts.

Anyone implementing OAuth in its first 3 drafts would have had to
throw the entire code base out and start over from scratch. Only from
draft 4 on it was considered stable for implementation. I have been
warning people about that with regard to XRDS-Simple and OAuth
Discovery, and in some cases also pointed out that they are being used
incorrectly. If fact, it is unlikely anyone used them correctly
(including myself).

I'll write more about it, but basically, XRDS-Simple is being replaced
by XRD 1.0 (first draft coming in the next few days) and its
dependency on Yadis is being replaced by draft-hammer-discovery [1].
OAuth Discovery is completely dependent on XRDS-Simple and hence will
be changed dramatically. Some of this is explained in [2].

Unlike the OAuth spec, XRDS-Simple and OAuth Discovery are both
individual submission (by me). While they both received some feedback,
none of it has made it to the specs (yet). I have decided to change
course with both and to significantly revisit their basic assumptions,
all of which was done in the open on the XRDS-Simple list (no
archived).

Both specs suffer from known issues which have been discussed on the
list and each have a issue list pending. The deprecation warning were
added because I have no intention of publishing such revisions at this
point. Both specs are copyrighted (by default) and are not covered by
any license. This is not a threat (as I will not enforce any of my
IPR) but a fact and an indication to their immature state.

As it currently stands, these two specs will be replaced by 3 new
specs:

1. HTTP-based Resource Descriptor Discovery [1] (Individual submission
at the IETF, discussed on [email protected])
2. XRD 1.0 (Extensible Resource Descriptor) (a product of the OASIS
XRI TC, membership required)
3. OAuth Service Descriptor (working title) (from past experience,
most likely an individual submission published under the OWF license
TBD - but would be nice to turn this into a community effort).

The first draft has been published two days ago. The second is coming
this week, and the third shortly after that in the form of a mailing
list post (with no draft expected until at least the second draft of
the first two).

It is unlikely that either spec 2 or 3 will be declared final before
September.

EHL

[1] http://tools.ietf.org/html/draft-hammer-discovery-00
[2] 
http://www.hueniverse.com/hueniverse/2009/01/discovery-on-my-mind-new-specification-published.html



On Jan 11, 12:04 pm, Evan Prodromou <[email protected]> wrote:
> Both the OAuth Discovery and XRDS-Simple documents now have
> deprecation warnings at the top of the page.
>
> It would be reasonable to give readers a rationale for why those
> specifications have been deprecated and should not be used. Has a
> grievous security error been found? Is a competing specification
> favored? Just the turn of the bureaucratic wheel in protocol
> development?
>
> A link in the deprecation warning to a longer blog post or other
> information would help a lot.
>
> As a data point: OpenMicroBlogging, a messaging protocol used on
> hundreds of public Web sites, depends on OAuth Discovery and XRDS-
> Simple. We'll continue using them for the time being.
>
> -Evan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to