Subject: PaceMakeAutodiscoveryInformational

From: James M Snell <[email-masked]>
Date: Tue, 28 Nov 2006 08:37:03 -0800

http://www.intertwingly.net/wiki/pie/PaceMakeAutodiscoveryInformational

#pragma section-numbers off

== Abstract ==

Move Autodiscovery forward as an Informational RFC

== Status ==

Proposed

== Rationale ==

At this point there seems to be very little reason for the autodiscovery
draft to be on the Standards Track.  An Informational RFC would appear
to be the most appropriate way forward.

== Proposal ==

Change the status of the autodiscovery draft to Informational.

== Impacts ==

== Notes ==

----

CategoryProposals

---

From: Lachlan Hunt <[email-masked]>
Date: Wed, 29 Nov 2006 04:06:09 +1100

> Move Autodiscovery forward as an Informational RFC

But if it were published as an informational RFC, what purpose would it 
serve?

I intend to post a much more substantial review of the current draft 
shortly, but for now, see my comments on the RSS Autodiscovery spec, 
some of which will also apply to the Atom Autodiscovery spec.

http://www.rssboard.org/news/70/vote-rss-autodiscovery-specification#discuss

-- 
Lachlan Hunt
http://lachy.id.au/

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 28 Nov 2006 18:17:16 +0100

> Change the status of the autodiscovery draft to Informational.

+1

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

---

From: James M Snell <[email-masked]>
Date: Tue, 28 Nov 2006 09:26:19 -0800

Lachlan Hunt wrote:
>[snip]

To document best practice as it relates specifically to syndication
feeds.  For example, HTML5 says nothing about whether the relative order
of feed autodiscovery links within a document is significant.  The Atom
autodiscovery draft, however, defines that the order is significant.

> some of which will also apply to the Atom Autodiscovery spec.

Excellent. FWIW, I agree with just about all of your comments.

- James

---

From: Geoffrey Sneddon <[email-masked]>
Date: Tue, 28 Nov 2006 17:37:35 +0000

+1

There's really no need for it to be a standard, as it's widely  
implemented in a common way.

- Geoffrey Sneddon

---

From: Robert Sayre <[email-masked]>
Date: Tue, 28 Nov 2006 13:08:13 -0500

James M Snell wrote:
> feeds.  

The draft makes several requirements. That's not documenting best practice.

> For example, HTML5 says nothing about whether the relative order

Which software does that requirement concern?

- Rob

---

From: James M Snell <[email-masked]>
Date: Tue, 28 Nov 2006 10:32:59 -0800

> The draft makes several requirements. That's not documenting best

If the doc is changed to informative, the normative requirements in the
draft would need to be relaxed and/or refactored to describe current and
best practice.

I didn't write the doc so please don't complain to me about what's in
there.  If there is something that needs to be changed write up a pace.

- James

---

From: Robert Sayre <[email-masked]>
Date: Tue, 28 Nov 2006 13:48:16 -0500

> there.  If there is something that needs to be changed write up a pace.

Uh, no. I don't think you should write it at all, and I resent having to 
waste my time following this completely redundant effort to make sure it 
doesn't do damage by making requirements that would break backwards 
compatibility with previous Firefox versions.

The WHAT-WG text is fine.

- Rob

---

From: James M Snell <[email-masked]>
Date: Tue, 28 Nov 2006 11:05:08 -0800

I do believe that participation in this discussion is optional, as is
choosing whether or not to support any particular IETF draft
(informational or otherwise) so there is absolutely no need (or desire)
for you to "waste" your time here.  Your opinion that the document is
unnecessary has been noted.  Thanks for the input.

- James

---

From: Robert Sayre <[email-masked]>
Date: Tue, 28 Nov 2006 14:23:17 -0500

James M Snell wrote:
> for you to "waste" your time here.  

Nonsense. You know very well that projects I work on will get bug 
reports on "standards" compliance if you change something. So, yes, I do 
have to waste my time here. Since I maintain autodiscovery code people 
actually use, you'd think my opinion would count for something.

== Abstract ==

Don't move forward with the autodiscovery draft.

== Status ==

Proposed

== Rationale ==

At this point there seems to be no reason for the autodiscovery draft to 
exist, since the WHAT-WG has ably covered the subject in Web 
Applications 1.0.

http://whatwg.org/specs/web-apps/current-work/#alternate0

Reasons given for the continued existence of the IETF draft have been 
non-technical doubletalk.

== Proposal ==

Stop work on the autodiscovery draft.

== Impacts ==

Reduces mailing list traffic and standards noise.

---

From: James M Snell <[email-masked]>
Date: Tue, 28 Nov 2006 11:35:52 -0800

+0. I have no particular agenda on this other than helping to move it
forward if that's what folks want.  I will note, however, that the
overall response to PaceResurrectAutodiscovery was positive and there
seemed (to me at least) to be interest in at least discussing the future
of the draft. So please stop trying so hard to kill it before folks get
a chance to actually think it over and discuss it.  Your opinion counts
but it's not the only one that matters.

- James

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 28 Nov 2006 20:51:43 +0100

> The WHAT-WG text is fine.

-1
For various reasons, including:
http://www.imc.org/atom-syntax/mail-archive/msg19100.html
http://www.imc.org/atom-syntax/mail-archive/msg19107.html

-- 
Thomas Broyer

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 28 Nov 2006 21:01:02 +0100

> actually use, you'd think my opinion would count for something.

If autodiscovery could be defined as in [1], I'd happy to see Firefox
(and IE7) have bug reports on "standards" compliance: I do not use
current autodiscovery implementations because I'm not confident in
their (undocumented) behavior (among other things, like integration
with external aggregators). I'd like autodiscovery documented
somewhere, but not as a documentation of current practices (which I
think are Bad Things), rather as "clean" way to do it.

However, if any spec (informational or not) tends to only document
what's already done, be sure I'll try to "kiil it before it's done".

-- 
Thomas Broyer

---

From: "Edward O'Connor" <[email-masked]>
Date: Tue, 28 Nov 2006 15:11:46 -0500

> Don't move forward with the autodiscovery draft.
[...]
> At this point there seems to be no reason for the autodiscovery draft
> to exist, since the WHAT-WG has ably covered the subject in Web
> Applications 1.0.

I am worried that there are three simultaneous efforts to spec out feed
autodiscovery: WA1, the RSS board's recent spec, and this draft. Ideally
this stuff would get specced just once. WHAT WG seems like a neutral
ground, syndication-format wise, so perhaps they're best positioned to
spec feed autodiscovery in a way that makes everybody happy.

Ted

-- 
Edward O'Connor
[email-masked]

Ense petit placidam sub libertate quietem.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 28 Nov 2006 15:26:58 -0500

> spec feed autodiscovery in a way that makes everybody happy.

Not only that, they are actually qualified to spec changes to HTML, 
which is what this is.

-Rob

---

From: James M Snell <[email-masked]>
Date: Tue, 28 Nov 2006 12:40:37 -0800

Heh.. I probably should not have been taking a drink when I read this
last sentence :-).  You do know that we're talking about the
*syndication community* right?

- James

Edward O'Connor wrote:
> [snip] ... feed autodiscovery in a way that makes everybody happy.
> 
> 
> Ted
>

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Tue, 28 Nov 2006 20:59:34 +0000

> Not only that, they are actually qualified to spec changes to HTML,

If autodiscovery is only a browser feature then indeed it has nothing to
do here. But is it only meant for browsers?

- Sylvain

---

From: Robert Sayre <[email-masked]>
Date: Tue, 28 Nov 2006 16:00:28 -0500

> *syndication community* right?

Actually, it's an HTML issue, so I don't see why the RSS Board or the 
Atom list or any incarnation of the "syndication community" would be an 
appropriate venue.

-Rob

---

From: Robert Sayre <[email-masked]>
Date: Tue, 28 Nov 2006 16:03:30 -0500

> do here. But is it only meant for browsers?

Browsers are surely the primary target, but bots and other HTML UAs make 
use of it. Both uses are covered by the people working on HTML, in the 
WHAT-WG and the W3C.

-Rob

---

From: Robert Sayre <[email-masked]>
Date: Tue, 28 Nov 2006 16:06:25 -0500

> http://www.rssboard.org/news/70/vote-rss-autodiscovery-specification#discuss 

"Like the Atom Autodiscovery draft, this spec serves no purpose. 
Autodiscovery is being defined in the HTML5 spec where it belongs, with 
both the alternate 
<http://www.whatwg.org/specs/web-apps/current-work/#alternate0> and feed 
<http://www.whatwg.org/specs/web-apps/current-work/#feed0> relationships."

Fully agree.

-Rob

---

From: James M Snell <[email-masked]>
Date: Tue, 28 Nov 2006 13:39:44 -0800

Ok, so given that I think this is the fifth or sixth note in which
you've said exactly the same thing, I think your position has been well
established.  What would be excellent is if you'd give others the
opportunity to weigh in on it before trying so hard to filibuster it.

- James

---

From: Rogers Cadenhead <[email-masked]>
Date: Tue, 28 Nov 2006 13:49:18 -0800 (PST)

If the Atom/RSS autodiscovery spec describes how to
work with the link element to achieve feed
autodiscovery in browsers and other clients, isn't it
an application of (X)HTML rather than an attempt to
specify (X)HTML?

My thinking was that we're accomplishing a task
similar to the creators of the Robots Exclusion meta
tag [1] -- put X values in element Y to achieve effect
Z.

1: http://www.robotstxt.org/wc/exclusion.html#meta

---

From: Robert Sayre <[email-masked]>
Date: Tue, 28 Nov 2006 16:51:13 -0500

> opportunity to weigh in on it before trying so hard to filibuster it.

Huh? I'm not sure what you mean--you send way more messages than I do. 
I'm merely pointing out facts.

I think the following entry from the WHAT-WG blog might be of use here.

http://blog.whatwg.org/proposing-features

Here are some key things that any proposal should include:

 * What is the problem you are trying to solve
 * What is the feature you are suggesting to help solve it?
 * What is the processing model for that feature, including error 
handling? This should be very clear, including things such as event 
timing if the feature involves events, how to create graphs representing 
the data in the case of semantic proposals, etc
 * Why do you think browsers would implement this feature
 * Why do you think authors would use this feature?

- Rob

---

From: Robert Sayre <[email-masked]>
Date: Tue, 28 Nov 2006 16:56:41 -0500

> opportunity to weigh in on it before trying so hard to filibuster it.

This looks like an inappropriate personal attack to me. Surely James has 
been warned about this in the past?

- Rob

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 29 Nov 2006 00:06:52 +0200

On Nov 28, 2006, at 22:11, Edward O'Connor wrote:

> WHAT WG seems like a neutral ground, syndication-format wise, so  
> perhaps they're best positioned to spec feed autodiscovery in a way  
> that makes everybody happy.

+1 for leaving speccing this to the WHATWG.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: James M Snell <[email-masked]>
Date: Tue, 28 Nov 2006 14:02:09 -0800

Ted,

Please correct me if I get any of this incorrect, but for the sake of
the discussion I wanted to summarize the HTML5 [1][2] definitions here:

The following three links are equivalent to one another and specify that
the linked feed is an alternate representation of the page.

 <link rel="alternate" type="application/atom+xml" href="..." />
 <link rel="alternate feed" type="application/atom+xml" href="..." />
 <link rel="feed alternate" type="application/atom+xml" href="..." />

This means, for instance, if the links appear on a blog home page that
lists the 10 most recent entries, the feed will likely also be a listing
of the 10 most recent entries.  However, if the link appears on a page
that shows a single entry along with a listing of comments that have
been received, the link will likely point to an Atom feed listing that
entry and it's various comments.  Is that correct?

HTML 5 defines the "feed" relation as pointing to a feed that is not
necessarily an alternative representation of the page where it is found.
 This relation can, for instance, be used on a blog home page to point
to a comments feed or category feed.

 <link rel="feed" type="application/atom+xml" href="..." />

What I did not see in the HTML5 spec is any indication of whether the
order of link relations is significant.  I'm assuming that means that it
is not.  I'm also assuming that means that all "alternate feed" link
relations, with the same type attribute value, appearing anywhere within
the document are considered to be equivalent?

- James

[1] http://whatwg.org/specs/web-apps/current-work/#alternate0
[2] http://whatwg.org/specs/web-apps/current-work/#feed0

---

From: Robert Sayre <[email-masked]>
Date: Tue, 28 Nov 2006 17:14:54 -0500

> tag [1] -- put X values in element Y to achieve effect

Hmm, have to disagree. The behavior is already well-documented, so this 
isn't accomplishing much. This effort is similar to rewriting the robots 
exclusion meta tag document. Is there some aspect of the WHAT-WG 
document that bothers you? Why not provide feedback there?

http://whatwg.org/mailing-list

The feedback you received from WHAT-WG members on the RSS Board blog was 
extremely detailed and accurate.

- Rob

---

From: Rogers Cadenhead <[email-masked]>
Date: Tue, 28 Nov 2006 14:25:32 -0800 (PST)

--- Robert Sayre <[email-masked]> wrote:
> Is there some aspect of the WHAT-WG document that
> bothers you?

Not yet, aside from the notion that they've got an
incredibly ambitious goal -- spec the next
HTML/XHTML/DOM -- and I have no idea how to gauge the
likelihood they'll achieve it. Or whether they'll
respect current autodiscovery functionality in MSIE 7
and Firefox 2.0.

> Why not provide feedback there?

I will if that's where autodiscovery goes.

But I'm +1 on PaceMakeAutodiscoveryInformational.
Seems like a good idea to tell Atom publishers how to
support autodiscovered feeds.

---

From: "Edward O'Connor" <[email-masked]>
Date: Tue, 28 Nov 2006 17:50:09 -0500

James,

[...]
> order of link relations is significant. I'm assuming that means that
> it is not. I'm also assuming that means that all "alternate feed" link
> relations, with the same type attribute value, appearing anywhere
> within the document are considered to be equivalent?

These are good questions, but you and I are equally able (or unable) to
answer them. Perhaps they would be better asked to the WHAT WG community
on their mailing list?

Ted

-- 
Edward O'Connor
[email-masked]

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Tue, 28 Nov 2006 22:52:32 +0000

> support autodiscovered feeds.

Same here.
If as James suggested the proposal is merely informational then there
will be little harm done while providing something useful enough to be
actually used.

I have no will to wait and see whether or not the WHATWG recommendation
will eventually be applied. If we have to wait for one or two years to
get their final document then I don't see how an informational spec
could harm the community while waiting.

Besides the fact that browsers are the primary target is not relevant to
me. Atom is more than just a feed to subscribe to to get the latest news
from a website. We don't have the background to understand how Atom
thanks to APP will evolve in the field.

+1 to the pace.

- Sylvain

---

From: James M Snell <[email-masked]>
Date: Tue, 28 Nov 2006 15:06:33 -0800

The problem I have with the WHAT-WG definition of the alternate and feed
relations is the unintended conflict that occurs when the alternate
representation of a page happens to be an Atom Entry Document.

The HTML5 draft says,

	"If the alternate keyword is used with the type attribute set to
	the value application/rss+xml or the value application/atom+xml,
	then the user agent must treat the link as it would if it had
	the feed keyword specified as well."

It goes on to say,

	"The feed keyword indicates that the referenced document is a
	syndication feed. If the alternate link type is also specified,
	then the feed is specifically the feed for the current document"

The problem with this is that the "application/atom+xml" media type is
also used for Atom Entry Documents:

  <link rel="alternate" type="application/atom+xml" href="entry.xml" />

The current WHAT-WG definition is inadequate.

There are three possible solutions:

  1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom
     media type is addressed

  2. We add a type parameter to the application/atom+xml media type
     to differentiate feed and entry documents,
     e.g. application/atom+xml;type=feed,
          application/atom+xml;type=entry

     When the media type is used without the type parameter,
     type=feed is assumed.

  3. We define a new media type for Atom Entry Documents,
     e.g. application/atomentry+xml

Given that there are significantly fewer instances of Atom Entry
Documents that would need to be updated and the fact that the ambiguity
in the Atom media type has come up as a problem before, I'd actually
lean strongly in favor of options 2 or 3.

- James

Henri Sivonen wrote:
> --Henri Sivonen

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 28 Nov 2006 18:16:52 -0500

On 11/28/06, Rogers Cadenhead <[email-masked]> wrote:
>
> I have no idea how to gauge the

My experience is that the IETF is essentially unresponsive to backward
compatibility concerns, to the extent that they will debate the
meaning of the term "MUST". It's like existential poetry.

In my experience, the WHAT-WG doesn't make any changes that break
compatibility unless users are already having problems caused by
implementation divergence. To make sure this is true, they research
and make decisions based on metrics, rather than ill-defined consensus
handwaving and individually-authored drafts with no support from
client implementors. I've even seen it claimed that "servers are
clients too", in the IETF.

> I will if that's where autodiscovery goes.

It is already there.

> support autodiscovered feeds.

They already know how, in general. The WHAT-WG is the place to work
out edge cases in HTML semantics.

Sylvain Hellegouarch wrote:
>
> there will be little harm done

Actually, the proposal seems so poorly researched and poorly
coordinated with WHAT-WG that I don't see how you can make that claim.
When Pilgrim wrote the draft, there weren't as many existing
implementations, so his approach made more sense at the time.

-- 

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Tue, 28 Nov 2006 15:18:33 -0800

Hello,

Over on the IETF Atom Syntax mailing list we're discussing whether or
not to pursue the autodiscovery draft that had previously been put on
the table [1] or to simply point to the HTML5 work and be done with it.
 While reviewing the HTML5 draft and comparing that to the Atom
auto-discovery draft, a couple of questions came to mind.

 1. Is the order of alternate link rels in a document significant?

 2. Are multiple alternate links with the same type attribute
    considered to be equivalent regardless of where those links appear
    in the document.

Thanks!

[1]
http://www.ietf.org/internet-drafts/draft-snell-atompub-autodiscovery-00.txt

- James

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 28 Nov 2006 18:22:06 -0500

>   e.g. application/atomentry+xml

No one relies on Atom Entry alternates now, so this is the best
option. We should tack it onto the APP draft, since that will solve
issues with the accept element there. And praise to mnot, who
suggested we do this in RFC4287 but was overruled by the WG (including
myself).

-- 

Robert Sayre

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 28 Nov 2006 18:40:43 -0500

>     considered to be equivalent regardless of where those links appear

What do you mean by "equivalent" ?

-- 

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Tue, 28 Nov 2006 15:57:50 -0800

> out edge cases in HTML semantics.

Over the course of history, a remarkable number of different groups  
have jumped up and down and said "*We're* the ones defining HTML!!!  
Listen to *us*!!!".  It's foolish to draw conclusions about any HTML- 
related spec based either on which group is originating it or what  
anyone claims the browser engineers are going to do.

  -Tim

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 28 Nov 2006 19:11:06 -0500

On 11/28/06, Tim Bray <[email-masked]> wrote:
> Listen to *us*!!!".

Yes, and *all* have them have done a poor job, except for the WHAT-WG.
I am not a frequent participant there, but I have noticed a large leap
in quality. For example, Firefox 2 is already shipping section 5.3.5
of HTML5, DOM Storage.

http://www.whatwg.org/specs/web-apps/current-work/#scs-client-side

I am supposed to be implementing getElementsByClassName today...
instead I am posting to this list. *sigh

> It's foolish to draw conclusions about any HTML-
> related spec based either on which group is originating it

Agree. But the WHAT-WG document and process are much better than the
alternatives.

> or what anyone claims the browser engineers are going to do.

Well, I've made the last 5-10 changes to the autodiscovery-related
code in one popular browser, so I can go by what I've already done,
rather than predicting the future.

Here is the bug where I'm going to implement the 'feed' relation, as
specified by the WHAT-WG:
https://bugzilla.mozilla.org/show_bug.cgi?id=362156

-- 

Robert Sayre

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Nov 2006 16:19:53 -0800

At 4:56 PM -0500 11/28/06, Robert Sayre wrote:
>This looks like an inappropriate personal attack to me.

<co-chair-hat value='on'>It may look like that to you, but it does 
not look that way to the WG Chairs. Please immediately stop posting 
messages such as this to the mailing list, It gets in the way of the 
technical discussion. If you cannot stop yourself from posting such 
messages, please consider not posting any more messages to the 
mailing list at all.
</co-chair-hat>

---

From: James M Snell <[email-masked]>
Date: Tue, 28 Nov 2006 16:26:14 -0800

Ian Hickson wrote:
> Good question. The draft hadn't covered that. I've now fixed the spec to 
> say that the order is important in one respect: the first <link>, <a>, or 
> <area> element whose rel="" attribute has the keyword "feed" (which might 
> also be implied by rel=alternate in certain cases) is defined to be the 
> default syndication feed for autodiscovery purposes.
> 

Excellent.  However, wouldn't it be more appropriate to limit this just
to rel="alternate feed"?  I can't imagine that the ordering of "feed"
links that are not also alternates is really all that significant.

> Currently, the location of the link is irrelevant (except for the first 
> one being the default). However, different links with different href="" 
> attributes aren't "equivalent"; they point to different documents. They 
> can also have different titles (title=""), languages (hreflang=""), and 
> preferred media (media="").
> 

Equivalent was the wrong word I think.

Assuming that A includes alternate links to B and C, Can I assume that B
is also an alternate of C; and vice versa?

If that is the case, consider the header of the mozilla.org start page
in which you'll find four distinct alternate links:

 <link rel="alternate" type="application/rss+xml"
       title="Mozilla Announcements"
       href="http://www.mozilla.org/news.rdf">
 <link rel="alternate" type="application/rss+xml"
       title="Mozilla Weblogs"
       href="http://planet.mozilla.org/rss10.xml">
 <link rel="alternate" type="application/atom+xml"
       title="mozillaZine News"
       href="http://www.mozillazine.org/atom.xml">
 <link rel="alternate" type="application/rss+xml"
       title="Mozilla Developer News"
       href="http://developer.mozilla.org/devnews/index.php/feed/">

Each represent alternative representations of distinct subsets of the
start page but they are not alternatives to one another.  I'm guessing
that using the "feed" link relation without the "alternate" keyword
would have been more appropriate

> I hope this helps. If you have any other feedback, or if you'd like the 
> spec changed in any way, please let us know. I am very interested in 
> addressing any requirements the Atom community may have.
> 

Yes, it does help.  Thanks for taking the time.

- James

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Nov 2006 17:09:28 -0800

At 6:16 PM -0500 11/28/06, Robert Sayre wrote:
>compatibility concerns,

The IETF has been very good with this on some protocols, and bad on 
others. Even if a major vendor has deployed something, if it is 
technically broken or limited, the IETF will generally ignore it. If 
the protocol is just acceptable, we will spend a huge amount of time 
trying to decide between "good enough" and "replace it", usually with 
silly results.

>  to the extent that they will debate the

+1

---

From: James M Snell <[email-masked]>
Date: Tue, 28 Nov 2006 18:09:39 -0800

Ian Hickson wrote:
> [snip]
> Here, while the last three are also valid feeds, it is the first one that 
> should be considered the default when doing auto-discovery. This isn't to 
> say that the feed UA should ignore the other three, or that it should only 
> show them if the user goes out of his way to obtain them -- indeed, the 
> "default" relationship could be completely ignored. It just means that if 
> it has to automatically pick one, then the first one is the one it should 
> pick. (It might also decide to only pick the one that is both a feed and 
> an alternative representation of the document, instead of picking the 
> default feed.)
> 

Hmm... Ok, I can live with that.

> Oh, you mean is the 'alternative' link type transitive? I guess so. I've 
> added a paragraph to the spec stating this.
> 

!@#$%! I was trying to think of that word all afternoon.  Yes, I was
meaning to ask if they were transitive.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 29 Nov 2006 03:21:59 +0100

+1

* Robert Sayre <[email-masked]> [2006-11-29 00:40]:
> We should tack it onto the APP draft, since that will solve
> suggested we do this in RFC4287 but was overruled by the WG
> (including myself).

+1

(Wow, I +1ed both James and Robert in the same mail. :-) )

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Lachlan Hunt <[email-masked]>
Date: Wed, 29 Nov 2006 14:40:54 +1100

> could harm the community while waiting.

Don't freak out, but it's going to take *a lot* longer than 1 or 2 years 
for the WHATWG work to finish.  Hixie posted the estimated schedule on 
www-archive.

    First Working Draft . . . . 2007
    Last Call Working Draft . . 2009
    Candidate Recommendation  . 2012
    Proposed Recommendation . . 2022

http://lists.w3.org/Archives/Public/www-archive/2006Nov/0000

However, that schedule really only represents the estimated time for a 
sufficent amount of test cases to be written and for implementations to 
become fully interoperable.  As features get implemented by browsers, 
you can start using them.  e.g. things like <canvas> or XMLHttpRequest 
are already widely supported and used, but their specs are not yet finished.

It's exactly the same with autodiscovery.  Since much of it is already 
widely supported and the rest of that section is relatively trivial to 
implement, the official status of the spec won't hold it up at all.

But what you can do to speed up the process is to write test cases. 
Hundreds of them for both HTML and XHTML, especially ones that test for 
edge cases and non-conforming behaviour.  That also helps to reveal 
holes in the spec, since if you can't test something, it's not specced 
well enough.

> +1 to the pace.

Why on earth is it called a pace?

-- 
Lachlan Hunt
http://lachy.id.au/

---

From: "Mark Baker" <[email-masked]>
Date: Tue, 28 Nov 2006 23:20:11 -0500

>   1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom

What ambiguity?  There's no ambiguity AFAICT.

But the WHAT spec does need fixing.  Assuming rel="feed" because of
the value of a (non-authoritative!) media type conflates two
independent concepts, and as a result may confuse users who are
looking for syndication feeds but instead find themselves confronted
with non-traditional (non-"feed") Atom documents.

If that's fixed, then this should work fine for entries (assuming
"alternate" semantics);

<link rel="alternate" type="application/atom+xml" href="foo.atom" />

There's no need for a new media type.

Mark.

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 29 Nov 2006 07:37:46 +0000

> suggested we do this in RFC4287 but was overruled by the WG (including

+1 very much on a new media type. The confusion carried by the current
one is alarming now but will become a real issue if APP does take off.

- Sylvain

---

From: "Thomas Broyer" <[email-masked]>
Date: Wed, 29 Nov 2006 09:03:50 +0100

> The current WHAT-WG definition is inadequate.

Already exposed here:
and there:
;-)

>   1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom

+1 (see above; see also Mark Baker's mail in this same thread –not yet
in the archives)

+1

>      When the media type is used without the type parameter,

I'd rather say: if there's no 'type' parameter, assume nothing, it can
be a feed or entry; this would make the "updated media-type" fully
backwards compatible with the current one (which shipped a year ago).

-1

-- 
Thomas Broyer

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Wed, 29 Nov 2006 20:18:49 +0800

I would like to have application/atomentry+xml for entry. As a result, application/atom+xml must be a feed.

>      When the media type is used without the type parameter,

This cause is ok, but a bit complicated. We have already had a charset parameter. If using both the type and the charset parameters together, then the Content-Type header will be application/atom+xml; type=feed; charset=utf-8. If type parameter is not declared, then type=feed is assumed because most feeds are serving with application/atom+xml with or without the charset parameter today.

Franklin Tse

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Broyer
Sent: Wednesday, November 29, 2006 16:04
To: Atom-Syntax
Subject: Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)

Already exposed here:

+1

-1

-- 
Thomas Broyer