Subject: finishing autodiscovery, like now

From: Robert Sayre <[email-masked]>
Date: Thu, 19 Jan 2006 12:05:47 -0500

PaceAnchorSupport and PaceDifferentRelValue don't seem very useful,
and they weren't proposed by implementors. The spec is extremely
well-written and reflects existing behavior.

Can we please un-expire this:
http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html

and be done?

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 19 Jan 2006 19:13:09 +0100

* Robert Sayre <[email-masked]> [2006-01-19 18:25]:
>PaceAnchorSupport and PaceDifferentRelValue don't seem very
>useful, and they weren't proposed by implementors. The spec is
>extremely well-written and reflects existing behavior.

They’re trying to do something useful, but in the wrong way. Both
seem to stem from a desire to be able to link feeds other than
those which are an alternate of the page in question.

But we already have a name for doing that: it’s called “linking
to something.” Now, it’d be useful to encourage people to add
`type` attributes to their `<a>` links, so tools could find them
just by looking at the page without spidering. But `rel` does not
add any information. The page is simply linking to another
resource. So +1 to encouraging `type`, -1 on fiddling with `rel`
at all (let alone going around changing values).

In fact, semantically, we should be encouraging people to move
things out of their `<link>`s and into `<a>`s in the page. After
all, the infrastructure for doing something useful with feeds
when a user clicks on a link in the page already exists: MIME
types and and `atom:link[@rel='self']`. This infrastructure is
not well supported; true. But new autodiscovery syntax is not
going to become well supported any quicker.

>http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html

+1

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

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 Jan 2006 06:54:16 +1100

On 20/1/06 5:13 AM, "A. Pagaltzis" <[email-masked]> wrote:

> But we already have a name for doing that: it¹s called ³linking
> to something.² Now, it¹d be useful to encourage people to add
> add any information.

Here is a link to a resource:

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

Please explain how a tool can decide whether that is a link to a <atom:feed>
document, or is a link to an <atom:entry> document?
 
> things out of their `<link>`s and into `<a>`s in the page.

Sounds like PaceAnchorSupport. How do you propose we do this encouragement,
if not by codifying it into a spec?

On 20/1/06 4:05 AM, "Robert Sayre" <[email-masked]> wrote:
> The spec is extremely well-written and reflects existing behavior.

The existing behaviour is based on the various incarnations of RSS where the
only document type involved are feeds. RFC 4287 introduces a new document
type, the Atom Entry Document, which autodiscovery-01 fails to take into
consideration. That doesn't meet my definition of "well-written".

e.

---

From: Anne van Kesteren <[email-masked]>
Date: Thu, 19 Jan 2006 21:05:37 +0100

> document, or is a link to an <atom:entry> document?

Why is that relevant?

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

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 Jan 2006 07:10:17 +1100

>> document, or is a link to an <atom:entry> document?

umm ... "autodiscovery" ???

or are you saying that links to Atom Entry Documents would/should never
appear in x/html pages?

e.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 19 Jan 2006 15:27:17 -0500

> consideration. That doesn't meet my definition of "well-written".

Well, if anyone actually did that, it might be a problem. But, then
again, it might not be. You've had years to propose your definition of
"well-written". I think the current draft reflects what
implementations do pretty well. We haven't been able to come to
consensus on additional features, so I suggest we're done.

--

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Thu, 19 Jan 2006 12:57:40 -0800

> document, or is a link to an <atom:entry> document?

This is a general limitation of the media type definition, not with the 
autodiscovery draft.  We have the same problem differentiating 
<atom:link type="application/atom+xml" href="..." />.  This isn't a 
problem that the autodiscovery draft needs to solve.  If it's a problem, 
solve it in the Atom format spec where the media type is defined.

> consideration. That doesn't meet my definition of "well-written".

I really don't believe this is going to be much of a problem in practice.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 19 Jan 2006 21:52:14 +0100

Hi Eric,

* Eric Scheid <[email-masked]> [2006-01-19 21:10]:
>Please explain how a tool can decide whether that is a link to a
><atom:feed> document, or is a link to an <atom:entry> document?

this is an excellent point. How does either Pace address it?

>Sounds like PaceAnchorSupport. How do you propose we do this
>encouragement, if not by codifying it into a spec?

PaceAnchorSupport merely promotes `<a>` to parity with `<link>`,
for which the I-D says a `rel` attribute consisting of at least
`alternate` is required.

But I don’t see how “this is a feed I want to link to” implies a
different relationship with the linking page than “this is some
resource I want to link to.” The mere fact that the linked
resource is a feed (or entry document) does not constitute a
relationship with the linking page in and of itself; and that
makes `rel` the wrong place to shoehorn this information into.

So no, encouraging people to add advisory `type` information to
their links is not equivalent to PaceAnchorSupport.

In any case, the important part is that when someone clicks the
link in a browser, the right things happen. For that, the `type`
is not even necessary, so long as the feed is served with the
correct MIME type and contains a self-link. The type makes some
harvesting easier, but ultimately, it’s not *necessary*.

We’re trying to shoehorn this functionality in with autodiscovery
right now because as of yet, the right things do not happen, even
though they *could*, whereas something closer to the right things
does happen when autodiscovery links are added willy-nilly.

>The existing behaviour is based on the various incarnations of
>RSS where the only document type involved are feeds. RFC 4287
>introduces a new document type, the Atom Entry Document, which
>autodiscovery-01 fails to take into consideration. That doesn't
>meet my definition of "well-written".

I don’t know how that is relevant. I am trying to think of a
scenario where I’d want to autodiscover an entry document (as
opposed to simply linking to it) and the inability to distinguish
between feed and entry documents is causing a problem, but I
can’t come up with anything. Can you provide an example?

Regards,

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 19 Jan 2006 16:08:59 -0500

> consideration. That doesn't meet my definition of "well-written".

"""
The purpose of Atom autodiscovery is for clients who know the URI of a
web page to find the location of that page's associated Atom feed.
"""

Not an entry but a feed. The autodiscovery is unambiguous on what such
a link points to. Now to match RFC 4287 that 'feed' ought to
be 'Feed', but that is a rather minor change.

   -joe

--
Joe Gregorio        http://bitworking.org

---

From: Phil Ringnalda <[email-masked]>
Date: Thu, 19 Jan 2006 13:16:59 -0800

On 1/19/06, A. Pagaltzis <[email-masked]> wrote:
> I don't know how that is relevant. I am trying to think of a
> scenario where I'd want to autodiscover an entry document (as
> can't come up with anything. Can you provide an example?

I have a weblog post. I would like aggregators to discover both the
feed for comments (rel="alternate feed") and the feed for my weblog
(rel="feed"), but I would like search engines and hypothetical
Atom-aware browsers and Piggybank-style history miners to discover the
Atom Entry document, where they can find just the entry for one-time
fetching with no question about what they are getting
(rel="alternate").

Of course, if we spec only things which include "feed" in the rel
value as being appropriate for aggregators, and all others as not, we
still would need to wait three or four years for existing use of
"alternate" alone to die down before any aggregator developer would
consider following along and ignoring non-"feed"s.

Phil Ringnalda

---

From: Robert Sayre <[email-masked]>
Date: Thu, 19 Jan 2006 16:31:03 -0500

> consider following along and ignoring non-"feed"s.

First person to need the feature has to spec "alternate entry" instead
of making everyone change to "alternate feed". Not it!

--

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Thu, 19 Jan 2006 13:37:19 -0800

Why wouldn't this work?

rel="alternate feed"
rel="alternate entry"
rel="alternate replies"  (see [1])

[1]http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-03.txt

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 Jan 2006 09:01:56 +1100

> this is an excellent point. How does either Pace address it?

PaceDifferentRelValue addresses this. It suggests using "feed" as an @rel
value to indicate the referenced resource is a feed (ie. is not an entry
doc) which can be subscribed to. It doesn't rule out continuing to use
"alternate" for those cases where the feed is actually an alternate to the
current document.

> I am trying to think of a scenario where I¹d want to autodiscover an entry
> document (as opposed to simply linking to it) and the inability to distinguish
> between feed and entry documents is causing a problem, but I can¹t come up
> with anything. Can you provide an example?

I'm not talking about autodiscovery of entry documents. I'm talking about
autodiscovery of feeds, which (and this is the point) is *different* from
autodiscovery of resources with the mime type of "application/atom+xml".

Apart from Atom Entry Documents, there are also "application/ref+xml"
documents ... and not all of those are RSS 1.0 feeds.

Using "feed" solves the problem for both cases (atom entry and rdf+xml), and
potentially any similar problems (eg newsml+xml?).

e.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 Jan 2006 09:01:43 +1100

> solve it in the Atom format spec where the media type is defined.

Too late. It would have been nice to have "application/atomentry+xml"

Also, fixing it in the atom format spec doesn't fix the exact same problem
autodiscovery has with "application/rdf+xml".

e.

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 19 Jan 2006 16:52:17 -0500

> rel="alternate replies"  (see [1])

Because rel is a space separated list of link types:

  http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel

I.e. the values are all orthogonal.

   -joe

---

From: Robert Sayre <[email-masked]>
Date: Thu, 19 Jan 2006 17:11:31 -0500

On 1/19/06, Eric Scheid <[email-masked]> wrote:
> doc) which can be subscribed to.

The spec already does this without a new rel value.

> It doesn't rule out continuing to use

I am lie-down-in-the-road opposed to PaceDifferentRelValue.
Interesting idea. I suggest someone write a DifferentSpec.

--

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 20 Jan 2006 00:10:40 +0100

* Phil Ringnalda <[email-masked]> [2006-01-19 22:30]:
>> I am trying to think of a scenario where I'd want to
>> autodiscover an entry document (as opposed to simply linking
>> to it) and the inability to distinguish between feed and entry
>> documents is causing a problem, but I can't come up with
>> anything. Can you provide an example?
>
>I have a weblog post. I would like aggregators to discover both
>the feed for comments (rel="alternate feed") and the feed for my
>weblog (rel="feed"),

Is `feed` a relationship of the page with the feed? Is there a
reason `<a type="application/atom+xml">` wouldn’t suffice?

>but I would like search engines and hypothetical Atom-aware
>browsers and Piggybank-style history miners to discover the Atom
>Entry document, where they can find just the entry for one-time

Okay, so you have two alternates: one with comments, one without.
That would be `rel="alternate"` in both cases, with
`title="Entry"` in one of them and `title="Entry with comments"`
in the other.

This is semantically weak, I know.

But I don’t see how it can be strengthened. It merely appears to
be expressible more precisely because we’re sticking to the
weblog use case.

What about feeds for a page on a wiki? Say you have one entry
document which contains the latest version of the page at the
time of retrieval, one feed which lists the history of major
edits, one which lists major+minor edits, and let’s say it’s one
of those newfangled wikis where you can leave comments on a page
separately from the page content, so you have a feed for that as
well. How do you tell those apart?

Then someone comes around and does this on his site:
http://www-128.ibm.com/developerworks/webservices/library/ws-atomwas/

And then someone else does something else.

And someone else still uses Atom in yet another clever way.

It’s just impossible to specify enough precise semantics to cover
everyone’s use cases, and no single app will ever understand all
of these disparate semantics. The problem seems simple while you
look at it with blog-coloured glasses because that is such a
small and well-understood niche of the problem space.

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 20 Jan 2006 00:32:28 +0100

* Eric Scheid <[email-masked]> [2006-01-19 23:10]:
>PaceDifferentRelValue addresses this. It suggests using "feed"
>as an @rel value to indicate the referenced resource is a feed
>(ie. is not an entry doc) which can be subscribed to. It doesn't
>rule out continuing to use "alternate" for those cases where the
>feed is actually an alternate to the current document.

Quibbling about the assumption that noone would ever want to
subscribe to an entry document aside, I guess I can see the
point. But `rel` is not the place for that. I don’t think we *do*
have a place for it.

What you really want is to express that the linked resource
adheres to a certain profile. (Hm, what happened to James Snell’s
profile extension?)

People could be as precise as they care to be, and bots and user
agents could support whichever profiles they cared to. You avoid
requiring full buy-in from everyone in order to make something
useful even though it’s as vague as “feed.”

Of course, this requires a mythical hook in HTML to hang the
profile information off of…

Regards,

---

From: James M Snell <[email-masked]>
Date: Thu, 19 Jan 2006 16:35:11 -0800

A. Pagaltzis wrote:
> (Hm, what happened to James Snell’s profile extension?)

In progress. I decided to hold off in favor of a few other higher 
priority items.  Expect a draft on this either later this month or next.

- James

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 Jan 2006 11:42:57 +1100

On 20/1/06 8:08 AM, "Joe Gregorio" <[email-masked]> wrote:

> a link points to.

Unambiguous? The autodiscovery spec does not outlaw using
link[@type=application/atom+xml,@rel=alternate] for linking to atom entry
documents. It only says that such links may be used to find Atom Feed
Documents. This is a subtle nuance.

e.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 Jan 2006 11:42:20 +1100

> This is semantically weak, I know.

@rel contains tokens, @title contains human language content.

Would @title="Entrada com comentários" also be acceptable? How about
@title="Entrata con le osservazioni" or @title="Entrée avec des
commentaires" or @title="Entrada con comentarios" or @title="Eintragung mit
Anmerkungen"? No. This is no basis for auto-whatever.

No matter what the @lang might be, the @rel would still contain the same
token for each of those possible @title links. It's just English Language
Imperialism why it happens to be "alternate entry", it could just as easily
be specced to be "FooBarBaz" or "3576.24352.987".

e.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 Jan 2006 11:43:04 +1100

> And someone else still uses Atom in yet another clever way.

Which is precisely why link[@rel="alternate",@type="atom+xml"] is an
*ambiguous* way of discovering atom Feeds ...

> It¹s just impossible to specify enough precise semantics to cover
> everyone¹s use cases, and no single app will ever understand all
> of these disparate semantics.

Strawman. I'm not suggesting we pre-define all these other cases. I'm
suggesting we define this one case (here is a feed document related to this
page) in a manner which distinguishes it from other [undefined] cases.

> The problem seems simple while you

Be careful what you assume. I'm thinking of using atom entry documents for
many non-blog related purposes, and this is what is driving my interest in
disambiguating feed autodiscovery.

e.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 Jan 2006 11:41:08 +1100

> I.e. the values are all orthogonal.

Yes, but that would mean that it *would* work, not that it *wouldn't*. Being
orthogonal means that those three links are equivalent to these six links

>> rel="alternate" href="1"
>> rel="alternate" href="2"
>> rel="alternate" href="3"
>> rel="feed"      href="1"
>> rel="entry"     href="2"
>> rel="replies"   href="3"

Which is exactly what was intended.

e.

---

From: Phil Ringnalda <[email-masked]>
Date: Thu, 19 Jan 2006 16:53:09 -0800

On 1/19/06, Joe Gregorio <[email-masked]> wrote:
> https://mail.google.com/mail/

Though at this point in this discussion, someone is always duty-bound
to point out that the only use of <link> that HTML actually specifies,
for stylesheets, treats them as not orthogonal ("alternate stylesheet"
is not "alternate" and a "stylesheet", it's an
"alternate-stylesheet"), and further assigns meaning to the presence
(though not, exactly, the content) of a title attribute.

Phil Ringnalda

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 Jan 2006 12:01:39 +1100

On 20/1/06 8:31 AM, "Robert Sayre" <[email-masked]> wrote:

> of making everyone change to "alternate feed".

How is speccing "alternate entry" helpful?

That would *still* be considered an autodiscovery link to a "feed",
according the current autodiscovery spec. That's the problem right there.

The spec should allow for the creation of other specs without land-grabbing
the non-specific "alternate" @rel value.

e.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 19 Jan 2006 20:12:44 -0500

> according the current autodiscovery spec. That's the problem right there.

It's not a "problem". It works now, and no one is going to run out and
change the running code. If someone did do "alternate entry", I can
see implementations getting patches to ignore those. In fact, you
don't even need a spec to help. Just start doing it. If it becomes
common, there will be patches.

--

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Thu, 19 Jan 2006 17:25:56 -0800

> Which is exactly what was intended.

Yep. Specifying them as separate tokens provides backwards compatibility 
(with clients that are actually implemented properly) and better 
semantics.  Folks that rely just on the "alternate" mechanism won't be 
any worse off than they are currently.  Folks that want the clearer and 
specific semantics would look for "feed", "entry", "replies"

- James

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 19 Jan 2006 20:29:17 -0500

> Documents. This is a subtle nuance.

That is not a subtle nuance but an incorrect interpretation. By that
same logic it does not outlaw using
link[@type=application/atom+xml,@rel=alternate] to point to
an RSS feed, or a PNG.

The autodiscovery spec would be the only RFC that defines
the behaviour of link[@type=application/atom+xml,@rel=alternate],
and the verbage in the autodiscovery spec is unambiguous
about that fact that it is talking about feeds and not entries.

   -joe

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 19 Jan 2006 20:32:33 -0500

> (though not, exactly, the content) of a title attribute.

Marvelous.

Are you suggesting we promulgate that behaviour in
the face of autodiscovery for RSS that already uses
"alternate"?

    -joe

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 Jan 2006 13:24:24 +1100

On 20/1/06 12:12 PM, "Robert Sayre" <[email-masked]> wrote:

> see implementations getting patches to ignore those.

and patches for "alternate replies", and patches for "alternate
something-else", and patches for "alternate blah" and patches for "alternate
[anything but blank space]".

Yep, that's the smart way to write a spec. Write it such that
implementations need to patch around it's shortcomings. And of course these
use cases for patches won't be documented anywhere, and different
implementers will do different patches. Didn't we already go through this
with the bugs and ambiguities in the html spec?

> In fact, you don't even need a spec to help. Just start doing it. If it
> becomes common, there will be patches.

Why not just spec it properly now? We know this is a possibility, we know
that keying off "alternate" is casting too wide a net. This change is
backwards compatible, so why the resistance?

Anybody would think that wide deployment is an argument against making
things better. If so we'd all be doing stuff using gopher, not http; or
using html 1.0 not xhtml.

e.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 19 Jan 2006 21:37:21 -0500

> [anything but blank space]".

Those probably aren't all alternates.

> Yep, that's the smart way to write a spec.

I think it is. I would be willing to change my mind if a browser
implementor agrees with you.

--

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 Jan 2006 13:43:13 +1100

>> (though not, exactly, the content) of a title attribute.

Yeah, awful.

> the face of autodiscovery for RSS that already uses

Speaking for myself, quite the opposite.

Robert Sayre is the only one so far suggesting that @rel="alternate entry"
should be treated as excluding the semantic of @rel="alternate". Which is
surprising: I would have bet he would consider the "alternate stylesheet"
thing an abomination.

I'm suggesting that if we want to link to a resource which is considered to
be a feed for the current document we use "feed". If we want to link to a
resource which is considered to be an alternate representation of the
current document we use "alternate". If the resource is considered to be
both, then the x/html spec allows both relationships to be expressed in the
one <link> as a space separated list.

Specifying "feed" does not rule out using "alternate feed" for backwards
incompatibility purposes, except to those implementations that can't cope
with more than one value in @rel, and according to the autodisco 1.0 spec
they are broken anyways so I have no compassion for them.

e.

---

From: "John Panzer" <[email-masked]>
Date: Thu, 19 Jan 2006 18:39:36 -0800

> about that fact that it is talking about feeds and not entries.

What autodiscovery links should I do on a web page that displays a 
single blog entry, like this one?

http://journals.aol.com/panzerjohn/abstractioneer/entries/1238

It's not unreasonable to link to the overall feed for the entire blog 
from this page, but it's a bit unreasonable to say that the feed is an 
'alternate' for the current page -- it's a superset of the current page, 
at best.  It's also not unreasonable to want to have a way to find an 
individual Atom entry associated with this page.  This would intuitively 
seem to be a reasonable 'alternate' since it contains the same 
information in a different format.

-- 
John Panzer
Sr. Technical Manager
http://journals.aol.com/panzerjohn/abstractioneer

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 19 Jan 2006 21:55:35 -0500

> http://journals.aol.com/panzerjohn/abstractioneer/entries/1238

Actually on my blog each page has a feed associated with
it that is a feed of all the comments on that page.

Regardless, the current spec is unambiguous, it points to
feeds. If we want it to point to something besides a feed
it has to be changed.

If we were to change something, one way to disambiguate feeds
from entries would be to add a parameter to the mime-type:

  application/atom+xml; doc=entry

   -joe

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 Jan 2006 14:09:17 +1100

> it that is a feed of all the comments on that page.

Are the comments on the same html page, or on another page? Some websites do
it the latter way. It often depends on the size of the article, especially
if the article is split into multiple pages (eg.
<http://www.xml.com/pub/a/2005/12/07/catching-up-with-the-atom-publishing-pr
otocol.html> ).

In the first use case, it would make sense to have @rel="alternate feed
replies" (it's an alternate representation of the page, it's a feed of
updates of this page, and it's a resource containing replies to this page).

In the latter case however @rel="alternate feed replies" would be broken.
The replies are not on that page, so how is a feed of replies an alternative
representation? It would make sense to have @rel="related feed replies"
though.

> feeds. If we want it to point to something besides a feed

No, it does *not* point to "feeds", it points to resources of a certain mime
type of which a subset are feeds. There's the ambiguity.

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 20 Jan 2006 10:36:54 +0100

* Eric Scheid <[email-masked]> [2006-01-20 01:50]:
>Which is precisely why link[@rel="alternate",@type="atom+xml"]
>is an *ambiguous* way of discovering atom Feeds ...

And why `rel="feed"` will not disambiguate them.

>> It¹s just impossible to specify enough precise semantics to
>> cover everyone¹s use cases, and no single app will ever
>> understand all of these disparate semantics.
>
>Strawman. I'm not suggesting we pre-define all these other
>cases. I'm suggesting we define this one case (here is a feed
>document related to this page) in a manner which distinguishes
>it from other [undefined] cases.

No, you misunderstood the argument. I’m wondering why the one
case you want defined stands out over the many other possible
cases such that a definition for it is urgent, even though the
way you propose to define it would require the same sort of
effort all over for the next use case.

You’re asking for a semantically broken definition that fixes
one use case without providing any value for any other use case.

* James M Snell <[email-masked]> [2006-01-19 22:05]:
>This is a general limitation of the media type definition, not
>with the autodiscovery draft.  We have the same problem
>differentiating <atom:link type="application/atom+xml"
>href="..." />.  This isn't a problem that the autodiscovery
>draft needs to solve.

+1

+1

Yes, that would be the correct place to fix this.

In fact, thinking about it, it seems like it would be the correct
place to put the profile information I was talking about in
another message:

    application/atom+xml;profile=http://example.org/ns/webservices/

* Eric Scheid <[email-masked]> [2006-01-20 04:15]:
>Are the comments on the same html page, or on another page? Some
>websites do it the latter way. It often depends on the size of
>the article, especially if the article is split into multiple
>pages (eg.
>In the first use case, it would make sense to have
>@rel="alternate feed replies" (it's an alternate representation
>of the page, it's a feed of updates of this page, and it's a
>resource containing replies to this page).
>
>In the latter case however @rel="alternate feed replies" would
>be broken. The replies are not on that page, so how is a feed of
>replies an alternative representation? It would make sense to
>have @rel="related feed replies" though.

Noone has explained to me so far how “the target of this link is
a feed” constitutes a relationship of the linking page with the
link target.

Regards,

---

From: Tim Bray <[email-masked]>
Date: Tue, 24 Jan 2006 10:08:53 -0800

> http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html

+1.  Ship it.  -Tim

---

From: Sean Lyndersay <[email-masked]>
Date: Tue, 24 Jan 2006 13:33:04 -0800

On Jan 19, 2006, at 9:05 AM, Robert Sayre wrote:
> The spec is extremely 
> well-written [...].

Heartily concur.

> +1.  Ship it.  -Tim

+1. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Bray
Sent: Tuesday, January 24, 2006 10:09 AM
To: Robert Sayre
Cc: Atom Syntax; Phil Ringnalda; Mark Pilgrim
Subject: Re: finishing autodiscovery, like now

+1.  Ship it.  -Tim

---

From: James M Snell <[email-masked]>
Date: Tue, 24 Jan 2006 13:51:50 -0800

+1

---

From: "John Panzer" <[email-masked]>
Date: Tue, 24 Jan 2006 14:26:09 -0800

+1 to "ship it".

---

From: Robert Sayre <[email-masked]>
Date: Wed, 25 Jan 2006 02:10:45 -0500

> +1 to "ship it".

I would like to reverse my previous position.

I think it's clear that many WG members have problems with the
document. There aren't very many WG members that can get code into
anything more substantial than essentially unused Java open source
projects. But that's not what matters, right?

There are only three significant implementers here. Microsoft,
Mozilla, and Apple. But, I think it's very important to consider the
responses of every WG member, don't you? We clearly don't have rough
consensus.

--

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 25 Jan 2006 13:31:31 +0100

>I would like to reverse my previous position.

You can be a pain sometimes. :-)

>But, I think it's very important to consider the responses of
>every WG member, don't you? We clearly don't have rough
>consensus.

I’m not going to usurp the WG chair positions here, but it seemed
to me that there was a pretty strong “ship it” response.

In any case, I see it as a problem that there is no currently (if
only tentatively) valid autodiscovery document, because I’ve had
to advise two concerned publishers about that so far; that’s
something I think needs addressing ASAP. I don’t see any downside
to unexpiring the existing I-D that codifies the status quo.

If enough people agree that it needs to be amended, then let’s
unexpire it as just a draft. We can discuss it then. We just need
*something* “on paper” for now.

Regards,

---

From: John Panzer <[email-masked]>
Date: Wed, 25 Jan 2006 10:03:45 -0800

To clarify my +1 to "Ship it":  At AOL, we are using Atom internally as 
a data exchange format (and just converted to 1.0 syntax).  We are using 
an early version of the introspection document as well, but only for 
limited internal use as it's nonstandard and likely to change.  When the 
dust settles on the APP we plan to use it both internally and 
externally.  Thus I have a strong interest in settling the dust.

-John