What would the relationship of that document be to RFC4287?
Cheers,
On 2006/12/11, at 7:32 PM, James M Snell wrote:
The I-D would be an individual draft, not a WG draft.
--
Mark Nottingham http://www.mnot.net/
Also, the MediaRSS module references it as a best practice.
When I started working on it, there was interest from server-side
folks as well (e.g., Six Apart); AFAIK they're just waiting for it to
be finalised (it's taken a while).
Cheers,
On 2006/11/27, at 11:18 AM, Mark
o make
the attempt?
- Ernie P.
On Nov 26, 2006, at 1:25 PM, Mark Nottingham wrote:
Sorry, this got lost in my inbox...
I think they do, although the draft is silent on it. This is one
of those areas where it would have been really nice if the WG had
agreed to take on FH as part of the core, r
mentation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <[EMAIL PROTECTED]>
___
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce
--
Mark Nottingham http://www.mnot.net/
, how do I determine the atom:id of the logical feed?
- James
--
Mark Nottingham http://www.mnot.net/
versions of HTML to appear in the same places that XHTML1 content is
allowed, processors wouldn't know what to do with it unless they
understood XHTML2. Tying the allowed content to a specific version of
XHTML promotes interoperability.
Cheers,
--
Mark Nottingham http://www.mnot.net/
dence. If you find an entry with a duplicate atom:id
and an
older or equal atom:updated, the one you currently have takes
precedence. If you want more granularity, look for app:edited
elements.
- James
Mark Nottingham wrote:
I haven't had any feedback on the possible change below. Does
I haven't had any feedback on the possible change below. Does anyone
want to see things move in this direction?
Cheers,
On 2006/10/11, at 10:06 PM, Mark Nottingham wrote:
1. I think your document might need to address what's supposed to
happen
if duplicate items are disco
time.
tag:example.org,2006:archives/200609.xml" />
...
- James
Mark Nottingham wrote:
OK. I'm adding this text just after the list of feed types in the
introduction;
---8<---
The semantics of a feed that combines these types is undefined by
this
specification
n 2006/10/12, at 2:42 AM, Andreas Sewe wrote:
Mark Nottingham wrote:
Andreas Sewe wrote:
But it would be desirable, IMHO, to be able to link to archived,
older versions of a complete feed from within the current
complete feed document.
Say, a feed document contains this month's Top Ten
least two
deployed
implementations I am aware of that use the same feeds for both and I'm
currently working on a third. In Google's new Blogger Beta, for
instance, the subscription feed is also the collection feed.
I believe that any assumption that the subscription and collections
to update that link in the documentation)
Thanks!
Thanks-
David
From: Mark Nottingham <[EMAIL PROTECTED]>
Date: 4 October 2006 11:13:06 AM
To: Atom-Syntax Syntax
Subject: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07
I've only had positive comments about -07 so far,
some use cases for this
sort of thing, it's going beyond the 80/20 point, and adding a lot of
complexity/abstraction. When I said that they were complementary, I
meant that together, they cover most feeds in common use today, not
that they can be used together.
I do want to address the combination issue, however. I'm inclined to
just state that the semantics of feeds that have more than one type
is undefined by this spec. Does that work for you?
Cheers,
--
Mark Nottingham http://www.mnot.net/
http://www.opensearch.org/Specifications/OpenSearch/1.1#The_.
22totalResults.22_element
Cheers,
On 2006/10/04, at 11:13 AM, Mark Nottingham wrote:
I've only had positive comments about -07 so far, so I've
recommended it for publication as a Proposed Standard to the IESG.
As part of th
.mnot.net/rss/history/feed_history.py>
Others? I know paging is used informally a lot in other situations/
specs.
On 2006/10/04, at 12:45 PM, James M Snell wrote:
Are you aware of Atom feeds that are currently implementing this
version
of the draft? I'd like to do some interop testi
do people think about putting this document on the Standards
Track?
* Do you have an implementation available, in progress, planned, etc.?
http://ietfreport.isoc.org/idref/draft-nottingham-atompub-feed-history/
Please provide feedback by October 18th.
Cheers,
--
Mark Nottingham http://www.mnot.net/
ID: <[EMAIL PROTECTED]>
___
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce
--
Mark Nottingham http://www.mnot.net/
they may safely assume that if
they have retrieved the archive document at a particular URI once, it
will not meaningfully change in the future.
]]]
Section 6.1
The archive document examples do not have the element
Fixed; thanks (and to Stefan as well).
--
Mark Nottingham http://www.mnot.net/
ta which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <[EMAIL PROTECTED]>
___
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce
--
Mark Nottingham http://www.mnot.net/
is the case, or am I (happily) mistaken?
--
Mark Nottingham http://www.mnot.net/
7, at 3:35 PM, James Holderness wrote:
Mark Nottingham wrote:
I'm not sure how ETags and 304s come into it -- it sounds like
you're proposing using either the entry-level updated date or the
entry- level id as input to a server-side function to select a set
of entries from the feed. C
On 2006/06/07, at 11:16 AM, James Holderness wrote:
Mark Nottingham wrote:
These are pretty much the assumptions that I was making
previously. The degree of precision that FH currently provides
isn't desirable for search results. Feed History also requires
that the server mai
3". That will break the FH algorithm
badly, reducing the value of the mechanism as a whole, because people
will stop trusting it. The link relation for implementing the
incremental approach needs to have the stability semantics baked in
and explicit.
--
Mark Nottingham http://www.mnot.net/
egators AFAICT; it seems to be more
for machine->machine communication, or for browsing a result set.
--
Mark Nottingham http://www.mnot.net/
("prev-archive"
and friends) and paging feeds ("previous", "next" and friends).
If people think that's a good idea, I can prepare a new draft that
attempts to address both. The intent would be to be compatible with
current usage by OpenSearch, GData, etc., while giving people the
option to use something more reliable when necessary.
Thoughts?
--
Mark Nottingham http://www.mnot.net/
derations: Automated agents should take care when this
relation crossed administrative domains (e.g. the URI has a
different
authority than the current document)
===
Example;
http://example.org/archive?
when=2006/04" />
- James
David Powell wrote:
Wednesday, May 3, 2006, 6:48:5
s out thing directly in a future rev? I think it might
be helpful for robust server designs if some guidance were given.
cheers
Bill
Mark Nottingham wrote:
If you use URIs like
http://example.com/feed?start=5&num=10
changing the directionality of "next" and "previous&q
m -- which is a primary requirement for feed
history.
What are the requirements that drove you to this type of paging
solution?
On 2006/05/02, at 9:14 PM, James M Snell wrote:
Mark Nottingham wrote:
[snip]
As it stands now, a single feed
cannot implement APP, OpenSearch AND Feed Histor
Peter,
Can you expand upon "being more precise about exactly what is needed"?
On 2006/05/01, at 3:16 AM, Peter Robinson wrote:
Mark Nottingham <[EMAIL PROTECTED]> wrote:
One thing I did notice -- you're using URLs like this for your
archives:
http://journa
time in a data store
arranged chronologically makes sense.
What Eric said.
As it stands now, a single feed
cannot implement APP, OpenSearch AND Feed History.
Please describe the scenario where you'd want that to happen -- show
the feed.
--
Mark Nottingham http://www.mnot.net/
.aol.com/panzerjohn/
abstractioneer/atom.xml
Thanks,
--
John Panzer
System Architect
http://abstractioneer.org
--
Mark Nottingham http://www.mnot.net/
et me know, I'd love to see if there are any
interoperability problems.
--
Mark Nottingham http://www.mnot.net/
s, respectively.
* More carefully specified the feed state reconstruction process;
please review.
* Moved fh:incremental boolean to fh:complete empty element (has
incremental=false semantics).
Please review and give feedback ASAP; I think this has incorporated
all feedback and stated plans to
so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--
Mark Nottingham http://www.mnot.net/
I've had a response; they're happy (Joe G can confirm this), and say
they'll update their next draft to accommodate the regs.
All systems go; requesting registration shortly.
On 03/11/2005, at 6:54 AM, Mark Nottingham wrote:
On 24/10/2005, at 2:12 PM, Peter Robinson wrot
x27;s any response.Cheers,--Mark Nottingham http://www.mnot.net/
that 'next' et al will be
purposefully generic; i.e., they won't mean much until used in
conjunction with another extension (in my case, fh:incremental).
My plan for feed history is to recommend people walk both 'previous'
and 'next' from the subscription feed, so that it doesn't matter
which "way" the feed goes.
Cheers,
--
Mark Nottingham http://www.mnot.net/
'll always have the latest entries in it.
On 22/10/2005, at 11:01 AM, Elias Torres wrote:
What's the difference between current and last?
Elias
On 10/22/05, Mark Nottingham <[EMAIL PROTECTED]> wrote:
I've replaced "subscribe" with "current"; otherwise,
stics: Undefined.
- Security considerations: Automated agents should take care when
this relation crosses administrative domains (e.g., the URI has a
different authority than the current document).
--
Mark Nottingham http://www.mnot.net/
Great! I'll summarise where they are and do a last call.
On 22/10/2005, at 9:52 AM, Tim Bray wrote:
On Oct 22, 2005, at 8:40 AM, Mark Nottingham wrote:
You seem to be saying that because link/@rel="self" was designed
for a specific purpose, and even though its defi
link and/or a "first" link
that is not equal to "self". As for finding the subscribtion URI
itself - that should just be the "first" link shouldn't it?
I don't want to get dragged back into a long argument on this so if
you think this is a stupid
n would be usable in both archived and "dynamic" feed
documents (in the latter case, it would be the same as "self").
On 21/10/2005, at 11:25 PM, Tim Bray wrote:
On Oct 21, 2005, at 5:03 PM, Mark Nottingham wrote:
How about:
- Description: A URI that refers to a f
the "self" relation was designed for a similar purpose, but is
not suitable for that use in other feeds, whereas this relation can
be used in those situations.
On 21/10/2005, at 4:16 PM, Tim Bray wrote:
On Oct 21, 2005, at 3:13 PM, Mark Nottingham wrote:
- Description: A URI
access to a specific point of time inside the feed "pages".
Each "archived set of entries" could for example cover one or two
week, so a user could navigate through the "feed state" or "feed
history" not only by going from pages to pages but also by
accessing archived chunks via an "index" or "table of contents".
--
Thomas Broyer
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
--
Mark Nottingham http://www.mnot.net/
ot self-evident. I would think that the
usefulness of this thing would be improved by a few words of
explanation for those who come upon it without knowing the history.
-Tim
--
Mark Nottingham http://www.mnot.net/
informed of the actual
URI they are subscribing to, and subscription should only take place
when it is explicitly requested.
--
Mark Nottingham http://www.mnot.net/
l="history", or define a @rel="previous-archive" if you
really want
to navigate directly to the other feed without having to go through a
"table of contents" feed.
If some people here prefers "next-chunk" or "next-page" to just
"next",
why not, my mind is open…
--
Thomas Broyer
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
--
Mark Nottingham http://www.mnot.net/
Please disambiguate "original."
On 18/10/2005, at 12:49 PM, James M Snell wrote:
+1 on all of Roberts comments. While I'm ok with the current
version, I was much happier with the original.
Robert Sayre wrote:
On 10/18/05, Mark Nottingham <[EMAIL PROTECTED]> wrote:
, so I'm trying to accommodate that.
3.) I don't think the notion of "fixed section" is helpful.
is good, that means "don't subscribe"... I get that.
It characterises the nature of the feed that's being linked to.
--
Mark Nottingham http://www.mnot.net/
y relative.
On 18/10/2005, at 12:14 PM, Robert Sayre wrote:
On 10/18/05, Mark Nottingham <[EMAIL PROTECTED]> wrote:
On 18/10/2005, at 11:38 AM, Robert Sayre wrote:
OK, well, I'm not terribly fussed by who registers them, but they
need to be carefully defined, and it wasn&#x
re.
Could you elaborate?
Thanks,
--
Mark Nottingham http://www.mnot.net/
e would
align with Amazon OpenSearch. In any case, I think it would be unwise
for the IETF to duplicate APP navigation.
--
Mark Nottingham http://www.mnot.net/
implementations. In fact, I
pointed this out way back in April 2005. I don't think anything has
changed.
In <http://www.mnot.net/blog/2005/04/12/feed_state> Mark Nottingham
wrote:
Way back when I put the first Atom drafts together, I included a
placeholder for
a section that I hoped
ng to, and subscription should only take
place when it is explicitly requested.
One other thought; what about "first-entries", "next-entries",
"previous-entries", "last-entries"?
--
Mark Nottingham http://www.mnot.net/
+1
On 17/10/2005, at 7:57 PM, Eric Scheid wrote:
On 18/10/05 9:53 AM, "Mark Nottingham" <[EMAIL PROTECTED]>
wrote:
So what happens when you need the rel="self" (as currently defined)
of an archive feed?
The current definition being ...
The value &qu
ev-entries?) is starting to look better, as
is .
On 17/10/2005, at 9:17 PM, James M Snell wrote:
In other words,
this does not imply a feed history thing...
...
this does...
...
true
--
Mark Nottingham http://www.mnot.net/
rels should not specify any
restrictions on how the contents of the feeds should or should not
be updated. If a specific use of these link rels wishes to impose
such a restriction (e.g. for feed history), then great, so-be-it,
but the link rels themselves should not.
--
Mark Nottingham http://www.mnot.net/
ing wrong with having an overlap like this, because
they don't
always overlap. Consider the 'subscribe' link to nature.com/nm/
which I
described earlier - two different URIs, but the same eventual
document.
e.
--
Mark Nottingham Principal Technologist
Office of the
Oh, no. I'd never sink to *those* depths!
On 17/10/2005, at 4:19 PM, James M Snell wrote:
Mark Nottingham wrote:
They seem similar. But, what if you want to have more than one
paging semantic applied to a single feed, and those uses of
paging don't align? I.e., there's
a very non-obvious
name for what's happening.
Otherwise, +0.5, because it seems to overlap @rel="first" (or
"last"?) – or I missed something…
I think we're kind of short on use cases for first and last, but
people seem to want them. 'subscribe' is more explicit; as they're
written, 'first' and 'last' should definately NOT be subscribed to
(because the set of entries in them won't change).
Cheers,
--
Mark Nottingham http://www.mnot.net/
it you
don't understand? I do think your addition of an indicator that the
feed is an archive is a good idea. I have to disagree with your
characterization of deployment. Most AtomAPI implementations work this
way--see for example typepad.com.
--
Mark Nottingham http://www.mnot.net/
:incremental extension (fh:incremental
will just change newsreaders behavior, not the paging concept).
It seems James is having the same feeling…
--
Mark Nottingham http://www.mnot.net/
Good point.
On 17/10/2005, at 2:54 PM, James M Snell wrote:
+1. An additional security concern would be the potential for
circular references
--
Mark Nottingham http://www.mnot.net/
r else may come up, then I would favor
the use of the generic mechanism assuming that the basic function
is the same.
--
Mark Nottingham http://www.mnot.net/
rpret -- and use -- them differently.
This is why I'm leaning towards "prev-archive".
On 17/10/2005, at 1:15 PM, Robert Sayre wrote:
On 10/17/05, Mark Nottingham <[EMAIL PROTECTED]> wrote:
I already get the same results with just one link relation -- 'prev-
archive&#
d subscription should only take
place when it is explicitly requested.
I have one concern about this approach, which I'll outline separately
(in response to Robert).
--
Mark Nottingham http://www.mnot.net/
ent that the entries in a feed (or
even the feed documents themselves) have to be in a specific order
in order to reconstruct the history. The minimum requirement is
only that we're able to find the feed documents we need. The Atom
processor can figure the rest out from ther
tal=no would explicitly tell them not to do so.
--
Thomas Broyer
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
BEAWorld 2005: coming to a city near you. Everything you nee
use of
'first/next/prev/last' with chapters or sections rendered in HTML.
I'm starting to think that the way to fix this is to make it more
specific, so that it doesn't get conflated with other uses; e.g.,
"prev-archive".
--
Mark Nottingham http://www.mnot.net/
OK, but that still leaves us with the question below -- who's doing
the paging, and why is it useful to have multiple ways around the thing?
On 15/10/2005, at 7:25 PM, Eric Scheid wrote:
On 16/10/05 6:54 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:
Can you
is actively harmful if it implies a
closed set, and misleading if it doesn't, and "next" and "first" are
mostly harmless, but don't really have supporting use cases and add
complexity to both the spec and implementations. I'd really like to
keep it simple. Are there any other use cases?
--
Mark Nottingham http://www.mnot.net/
link rel would point to the feed that should be
subscribed to -- regardless of whether the subscription feed
appears at the start or end of the set.
What would the algorithm be for assuring that you have the complete
state of the feed, without necessitating traversal of the entire feed
every time?
Cheers,
--
Mark Nottingham http://www.mnot.net/
h
would need to be supported (and optimised) by implementations, which
isn't so great unless there's a compelling need for it.
--
Mark Nottingham http://www.mnot.net/
u "last")
- link/@rel="subscribe" has a semantic of "if you want to
subscribe to this feed, use the linked document, not this one."
The reconstruction algorithm is pretty much the same as in -04.
The only dangling point is "first." I'm not especia
t
is the previous feed in the linked list
is the last feed in the linked list.
Terms like "top", "bottom", "up", "down", etc are meaningless in
this model as they imply an ordering of the contents.
For feed history, it would work something like:
...
uot;previous" and "next" is
both an advantage and a disadvantage. I think the question is
whether it's an advantage in a significant majority of cases or
not. What orderings would those terms not work well for?
--
Mark Nottingham Principal Technologist
Office of the CTO
st to just define a new link relation.
On 14/10/2005, at 10:28 AM, Thomas Broyer wrote:
Mark Nottingham wrote:
How about:
?
I always thought this was the role of @rel="self" to give the URI
you should subscribe to, though re-reading the -11 it deals with "a
resource
an only occur in archive documents, it
obviates the need for a separate fh:archive flag, which in turn means
that you don't have to declare two namespaces to use fh in RSS
archive documents -- which was one of the things making me reluctant
to switch over to atom:link.
How about:
?
--
Mark Nottingham http://www.mnot.net/
lso rename "next" and "previous" (or is it "previous" and "next"?)
to "down" and "up". There's SOME chance of that getting confused
with hierarchical levels, but I could live with that.
--
Mark Nottingham Principal Technol
future?
Another issue worth noting is that their example RSS feed is also
using atom:link to provide this functionality.
Robert Sayre wrote:
No, but Amazon OpenSearch has been threatening to register it,
FWIW. :)
--
Mark Nottingham Principal Technologist
Office of th
Yeah, that kind of tears it for me; we could profile it, but I'm less
than convinced that the potential reuse is worth it (esp. when it's
so trivial to map age:expires into dcterms:valid).
+1 to age:expires.
On 09/10/2005, at 10:21 AM, Phil Ringnalda wrote:
Mark Nottin
is pending IETF
registration". Does that mean they've actually started some kind of
registration process or they're just hoping to do so at some point
in the future?
--
Mark Nottingham http://www.mnot.net/
aken.
It's in there:
http://bitworking.org/projects/atom/draft-
gregorio-09.html#rfc.section.5.4.1
So -1 to draft-nottingham-atompub-feed-history-04.txt for not using
a link tag of rel="prev".
-joe
--
Joe Gregorio http://bitworking.org
--
Mark Nottingham Pri
this
element when used in Atom, it *could* lead to a bunch of extra work
for consumers to parse and process those dates. I prefer very
crisply defined elements. Then again, reusing an existing
namespace is Goodness.
So what do y'all think?
- James
Mark Nottingham wrote:
FWIW, the
rom that article to his archives
on diveintomark.org which actually include next and prev links in
the feed. I'm almost inclined to add support for that just so I can
access those old posts. There used to be some excellent articles on
his site.
--
Mark Nottingham Principal Te
n be found here:
http://dublincore.org/usage/meetings/2005/09/madrid/files/
2005-07-29.date-comment.txt
Personally I think that makes the idea of using dublin core for
this extension a whole lot more palatable.
--
Mark Nottingham http://www.mnot.net/
x you use in most of the document is "fh" while the
one in all the examples is "history". Technically still valid, but
I figure you'd probably want them all to be the same.
I did that on purpose :)
Cheers,
--
Mark Nottingham http://www.mnot.net/
n Gutierrez - [EMAIL PROTECTED] - http://engrm.com/blogometer/
--
Mark Nottingham http://www.mnot.net/
NTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is
subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Ac
ful if we could agree on an
extension name space
that all accepted extensions would use, in order to reduce name
space clutter.
Henry
On 7 Sep 2005, at 01:18, Mark Nottingham wrote:
Feed History -04 is out, at:
http://www.ietf.org/internet-drafts/draft-nottingham-atompu
ure that's as interesting.
--
Mark Nottingham http://www.mnot.net/
nted, this extension wouldn't be safe to deploy
without must-understand extensions, which Atom 1.0 doesn't support.
That would be another way to go, but people didn't want mU.
Cheers,
--
Mark Nottingham http://www.mnot.net/
he feed (e.g. prior
top-ten-lists). This could be accomplished by allowing fh:prev
elements in a feed with fh:incremental set to false.
...
false
http://www.example.com/oldfeed
means that http://www.example.com/oldfeed is the previous (I hate
to use the word) "version" of th
out
- more explicit white space handling
- Acknowledgements section
More information, including implementation details, at:
http://www.mnot.net/blog/2005/09/05/feed_history
--
Mark Nottingham http://www.mnot.net/
esday, August 30, 2005 5:10 PM
To: 'Mark Nottingham'
Cc: atom-syntax@imc.org
Subject: RE: "Top 10" and other lists should be entries, not feeds.
Mark Nottingham wrote:
Are you saying that when/if Netflix switches over to Atom, they
shouldn't use it for the Queue?
just
an entry that gets updated regularly. There's absolutely no reason
for Netflix to create an individual entry for each DVD. It's a hack
that makes it look better in most aggregators. Nothing more.
--
Mark Nottingham http://www.mnot.net/
r hands off the feeds. Feeds aren’t
lists – they are feeds.
bob wyman
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
--
Mark Nottingham http://www.mnot.net/
bit evocative of time, which I'd like to avoid (despite the use of
'history' in the document title :-/).
(BTW, "incremental" isn't my term; it was suggested privately by an
implementor)
--
Mark Nottingham http://www.mnot.net/
or Firefox.
Thanks for pointing this out. :-)
:-)
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
On 25/08/2005, at 3:00 AM, Stefan Eissing wrote:
Am 25.08.2005 um 00:07 schrieb Mark Nottingham:
Just bouncing an idea around; it seems that there's a fair amount
of confusion / fuzziness caused by the term 'stateful'. Would
people prefer the term 'incremental&
1 - 100 of 218 matches
Mail list logo
