Subject: Extension draft updates

From: James M Snell <[email-masked]>
Date: Fri, 09 Dec 2005 13:35:29 -0800

I've updated the various extension drafts to point to RFC4287.

The feed thread draft is a major update that includes a simplification 
of the in-reply-to element.

   <in-reply-to
     id="tag:example.org,2005:some-unique-id"
     href="http://example.com/some-location" />

I'm moving the feed rank draft the "stable" status.. meaning that 
changes are unlikely between now and when I submit the draft as a 
standards-track RFC (which will be after APP is complete).

There is a new draft that defines a "transitional atom" format.  The 
t-atom format is usable during the production lifecycle of Atom entries; 
as such certain requirements from core Atom are relaxed (e.g. atom:id is 
optional, etc).

Works in progress:
http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-00.txt
http://www.ietf.org/internet-drafts/draft-snell-atompub-transitional-atom-00.txt

Last call:
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-03.txt

Stable:
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-index-04.txt
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-04.txt
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-expires-06.txt
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-nofollow-04.txt

As always, comments are welcome and desired.

- James

---

From: "James Holderness" <[email-masked]>
Date: Sat, 10 Dec 2005 05:26:27 -0000

James M Snell wrote:
> The feed thread draft is a major update that includes a simplification of 
> the in-reply-to element.
>
>   <in-reply-to

I really like what you've done with this. I have a couple of questions 
though.

What is the type of the resource pointed to by the in-reply-to href? It 
seems to me it can't be an Atom feed since that isn't really a 
representation of the resource being responded to (although that would 
probably be most useful here). An Atom entry document? An HTML web page? 
What would you expect a client application to do with this value? A link to 
the source feed I could see myself using (in combination with the id 
obviously), but I'm not sure about the other two.

Second question: what is the reason for recommending a related link when the 
href points to something external? It seems to me an unnecessary duplication 
of information but I may be missing something. And once again what would you 
expect the client to do with it? A HTML page could be provided to the user 
as a clickable link, but an Atom feed? An Atom entry document? Obviously the 
answer to this depends on the type of the href, which brings us back to 
initial question.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Fri, 09 Dec 2005 21:49:29 -0800

> What is the type of the resource pointed to by the in-reply-to href? It 

It's whatever type the server says it is when you GET it (Content-Type 
header).

> What would you expect a client application to do with this value? A link 
> to the source feed I could see myself using (in combination with the id 

Most likely it will end up being the source feed.  The idea was to leave 
this un(der)specified for now and let implementors figure out what works 
best.

> 
> Second question: what is the reason for recommending a related link when 
> the href points to something external? It seems to me an unnecessary 
> duplication of information but I may be missing something. And once 
> again what would you expect the client to do with it? A HTML page could 
> be provided to the user as a clickable link, but an Atom feed? An Atom 
> entry document? Obviously the answer to this depends on the type of the 
> href, which brings us back to initial question.
> 

The related link allows clients that are not familiar with the Feed 
Thread extension to at least be able to indicate that there is some kind 
of relationship between the two resources.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 10 Dec 2005 19:20:27 +0100

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

I like this. Simple and to the point, no longer desperately
generic, but still open enough to accomodate the non-Atom world.

+1

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

---

From: "James Holderness" <[email-masked]>
Date: Sun, 11 Dec 2005 02:45:16 -0000

> It's whatever type the server says it is when you GET it (Content-Type 

Well ideally you wouldn't want to GET or HEAD every href in order to 
determine its type. I'm not positive this is a problem, but it may be 
depending on what a client may want to do with this extension.

> The related link allows clients that are not familiar with the Feed Thread 
> extension to at least be able to indicate that there is some kind of 
> relationship between the two resources.

Imagine that a client doesn't know anything about this extension. What do 
you think such a client would typically do with related links? I don't know 
about anyone else, but what I do is display them in a "see also" list that 
the user can launch in a browser window. This works very well when the links 
are to web pages or other resources that can be handled usefully by a 
browser, but it's a complete waste of time if the link is pointing to an 
Atom feed. Most of the time the user will just get a page of meaningless 
XML - at best they'll get the option to subscribe to a feed that they're 
quite likely already subscribed to.

But that's just how I handle links. Maybe there's a better way. Can you 
imagine some other way in which clients might handle related links (without 
knowing anything about this extension) that would be able to do something 
useful with a link that pointed to an Atom feed - specifically the Atom feed 
that the current message is replying to?

Now if the in-reply-to href was pointing to a web page I could understand 
recommending a related link that pointed there too. So maybe you could limit 
the recommendation like that. Or otherwise just leave out the recommendation 
altogether and let the feed producer decide whether a related link is a good 
idea or not. Related links are already part of the Atom spec - there's 
nothing stopping a feed producer using them - but I'm not sure they should 
be encouraged to do so with links which may not be at all appropriate.

Regards
James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 11 Dec 2005 10:31:40 +0100

* James Holderness <[email-masked]> [2005-12-11 03:55]:
> What do you think such a client would typically do with related
> links? I don't know about anyone else, but what I do is display
> them in a "see also" list that the user can launch in a browser
> window. This works very well when the links are to web pages or
> other resources that can be handled usefully by a browser, but
> it's a complete waste of time if the link is pointing to an
> Atom feed.

You do that even if it’s

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

?

> Maybe there's a better way. Can you imagine some other way in
> which clients might handle related links (without knowing
> anything about this extension) that would be able to do
> something useful with a link that pointed to an Atom feed -
> specifically the Atom feed that the current message is replying
> to?

Minimally, it can pull the feed and look for its alternate link.
Less minimally it can also look at all the other metadata that
Atom documents can contain.

We’re talking about an Atom consumer here; that it wouldn’t be
able to do something sensible with Atom docs strikes me as an odd
objection.

Regards,

---

From: "James Holderness" <[email-masked]>
Date: Sun, 11 Dec 2005 11:20:04 -0000

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

Ideally if I know the type I can try to subscribe immediately without going 
through the browser which is likely to fail. My assumption (at least up to 
now) was that if a feed producer was adding a related link to another Atom 
feed it was because that feed really was a relevant, related link. However 
this extension is encouraging the feed producer to include related links 
that I don't think are very useful to the user and that they wouldn't 
usually include.

It makes perfect sense when you think about it theoretically. Those 
documents are technically related. But when you think about the practical 
implications, how the client needs to deal with it, how it affects the end 
user, I don't think it's a good idea.

> able to do something sensible with Atom docs strikes me as an odd

That's possible, but definately not something I would consider doing. Right 
now when a user clicks on a link I can pass that link directly to a browser. 
You're suggesting I should check the link type (possibly by doing a HEAD) 
and then if it's an Atom document I download the document myself, parse out 
an alternate link and then pass that on to the browser. I'd prefer something 
a little more efficient than that for a simple link click.

But I guess that is a possible alternative. Do you know of any client 
implementations that do that sort of thing?

Regards
James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 11 Dec 2005 20:24:45 +0100

* James Holderness <[email-masked]> [2005-12-11 12:30]:
> Those documents are technically related. But when you think
> about the practical implications, how the client needs to deal
> with it, how it affects the end user, I don't think it's a good
> idea.

Well, the idea for this, if I remember right, was actually mine;
and was based mainly on the thought you’re calling “technically.”
The idea was to give threading-unaware clients a chance to do
something useful.

Based on your argument I would agree that it would be best if the
related link pointed to the permalink of the entry being replied
to, rather than the feed. In fact that is a very good idea in any
case.

But in that case you run into the problem that there is no clear
way to associate the atom:link[@rel='related'] to a particular
permalink with its thr:in-reply-to pointer, ie. the information
is imprecise and  threading-aware clients have to guess.

A complication here is that we found in previous discussion that
nesting makes things more complex; ideally, therefore, any
approach would only add direct child elements to the atom:entry
element.

Given this constraint, do you have a better idea how do address
the following concerns?

• Threading-unaware clients should get at least some information
  that allows the user to notice that there’s more to the entry,
  even if the user agent remains blissfully unaware of the thread
  as such.
  
• The available information precise enough that threading-aware
  can correlate all the related bits without guessing.

The existing draft avoids problems with #2 by simply duplicating
URIs, so it’s always obvious which related links and which
threading elements belong together. If the URIs diverge, you need
some other mechanism of crossreferencing from one to the other.

> Do you know of any client implementations that do that sort of
> thing?

Honestly, I haven’t seen any yet that do anything interesting at
all with extra links (be they related, via, or something else)…
(Which rather irks me.)

Regards,

---

From: "James Holderness" <[email-masked]>
Date: Tue, 13 Dec 2005 02:47:34 -0000

>  even if the user agent remains blissfully unaware of the thread

I think a "related" link that points to the permalink of the original 
message is a good start.

>  can correlate all the related bits without guessing.

What about something like this:

<th:in-reply-to>
  <id>tag:www.example.org:2005:entry1</id>
  <link rel="feed" type="application/atom+xml" 
href="http://www.example.org/feed.atom"/>
  <link rel="related" type="text/html" 
href="http:www.example.org/entry1.html"/>
</th:in-reply-to>

No doubt there are issues with the syntax, but the important concept is the 
idea of having two clearly defined links: one being the permalink for the 
entry being replied to and the other being the atom feed in which that entry 
can be found. It could be made more flexible by allowing further "alternate" 
links, but I'm not sure that's necessary.

> all with extra links (be they related, via, or something else)…

Me neither. I can't say I'm exactly doing anything interesting with links, 
but I am at least doing something with them.

Regards
James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 13 Dec 2005 05:39:12 +0100

* James Holderness <[email-masked]> [2005-12-13 03:55]:
> No doubt there are issues with the syntax,

The biggest issue being that a threading-unaware client won’t
know to go looking inside thr:in-reply-to to find links. This
syntax will only satisfy the “allow threading-unaware clients to
do something useful” constraint if you duplicate the links at the
atom:entry level.

> but the important concept is the idea of having two clearly
> defined links: one being the permalink for the entry being
> replied to and the other being the atom feed in which that
> entry can be found. It could be made more flexible by allowing
> further "alternate" links, but I'm not sure that's necessary.

If the extensibility afforded by child elements is not a useful
goal (and in this case, I think it isn’t; is there more
information that is going to be needed than the source feed and
permalink?), that could be handled cleanly by just adding an
@alternate attribute to thr:in-reply-to to record the permalink.

atom:link elements can then simply be added to the atom:entry.
This keeps things nicely flat and simple.

I am not sure that the semantics of adding atom:link[@rel='feed']
to atom:entry are particularly clean; but we might just decide
that it isn’t a great loss if threading-unaware clients miss the
feed link. Or else we’d need to pick a better name for the
relation.

So the changes would be:
• Rename @href to @source.
• Repurpose @href to contain the alternate link.
• Change the recommendation to include an
  atom:link[@rel='related'] to point to the alternate link
  instead of the feed.

Regards,

---

From: "James Holderness" <[email-masked]>
Date: Tue, 13 Dec 2005 05:02:14 -0000

> do something useful” constraint if you duplicate the links at the

That's what I meant when I said: "I think a "related" link that points to 
the permalink of the original message is a good start."

I really don't think a threading-unaware client needs to know the URI of the 
Atom feed that contained the message.

> @alternate attribute to thr:in-reply-to to record the permalink.

I don't have a problem with that. I was just playing with ideas for the 
syntax.

> feed link.

I wouldn't suggest trying to add it to the entry at all. I don't think it's 
a useful piece of information to a threading-unaware client even if it was 
in a format that would be recognised.

>  atom:link[@rel='related'] to point to the alternate link

Sounds good to me.

Regards
James

---

From: Alex Milowski <[email-masked]>
Date: Tue, 13 Dec 2005 08:44:52 -0800

James M Snell wrote:

> t-atom format is usable during the production lifecycle of Atom 
> entries; as such certain requirements from core Atom are relaxed (e.g. 
> atom:id is optional, etc).
>
> Works in progress:

In this draft I noticed:

<thr:in-reply-to
           id="tag:entries.com,2005:1" href="#"/>

as an entry that is a "reply-to" for another entry in the same feed.

Why wouldn't we just have:

<thr:in-reply-to id="tag:entries.com,2005:1"/>

and make the 'href' attribute implied to be the current feed?

It just feels much more simply to omit the href.  Certainly, a value of 
'#' should
affect the threading in the same way.

--Alex Milowski

---

From: James M Snell <[email-masked]>
Date: Tue, 13 Dec 2005 08:46:57 -0800

> and make the 'href' attribute implied to be the current feed?

Yep, you could do that. href="#" just makes it more explicit.

- James