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/
?
- 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, rather than extension
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 Nottingham
determine the atom:id of the logical feed?
- James
--
Mark Nottingham http://www.mnot.net/
: [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/
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/
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 anyone
want to see things move in this direction?
Cheers,
On 2006
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 discovered when
, 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. Wouldn't it
be nice
,2006:archives/200609.xml /
fh:complete /
fh:archive /
link rel=self href=200609.xml /
link rel=prev-archive href=200608.xml /
...
/feed
- 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
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
feeds will always be different is incorrect and dangerous.
--
Mark Nottingham 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 that process, I'm
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/
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/
/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 testing.
- James
Mark Nottingham wrote
/mailman/listinfo/i-d-announce
--
Mark Nottingham http://www.mnot.net/
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 fh:archive / element
Fixed; thanks (and to Stefan as well).
--
Mark Nottingham http://www.mnot.net/
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/
, or am I (happily) mistaken?
--
Mark Nottingham http://www.mnot.net/
to be more
for machine-machine communication, or for browsing a result set.
--
Mark Nottingham http://www.mnot.net/
relation for implementing the
incremental approach needs to have the stability semantics baked in
and explicit.
--
Mark Nottingham http://www.mnot.net/
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 maintain
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. Can you paint out your proposal
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/
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 History.
Please describe the scenario where you'd
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=5num=10
changing the directionality of next and previous will not make
what you're doing compatible with feed history.
Such URIs have a much
administrative domains (e.g. the URI has a
different
authority than the current document)
===
Example;
link rel=archive href=http://example.org/archive?
when=2006/04 /
- James
David Powell wrote:
Wednesday, May 3, 2006, 6:48:55 AM, Mark Nottingham wrote:
If you use URIs like
http
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/
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://journals.aol.com/panzerjohn
love to see if there are any
interoperability problems.
--
Mark Nottingham http://www.mnot.net/
,
--
John Panzer
System Architect
http://abstractioneer.org
--
Mark Nottingham http://www.mnot.net/
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 date.
Cheers,
--
Mark
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 wrote:
That is true
,--Mark Nottingham http://www.mnot.net/
James
--
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 definition is quite
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/
. 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/
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
--
Mark Nottingham http://www.mnot.net/
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 that refers to a feed document
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/
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 would allow
OpenSearch. In any case, I think it would be unwise
for the IETF to duplicate APP navigation.
--
Mark Nottingham http://www.mnot.net/
elaborate?
Thanks,
--
Mark Nottingham http://www.mnot.net/
.
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't at all clear
trying to accommodate that.
3.) I don't think the notion of fixed section is helpful.
fh:archive 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/
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:
I'm confused
' 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/
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 need for SOA and
enterprise infrastructure
(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 there.
- James
Mark Nottingham wrote:
Exactly
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/
change newsreaders behavior, not the paging concept).
It seems James is having the same feeling…
--
Mark Nottingham http://www.mnot.net/
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/
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/
document.
e.
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
BEAWorld 2005: coming to a city near you. Everything you need for SOA and
enterprise infrastructure success
--
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 self signifies that the IRI
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 walk me through a use case
with that.
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
BEAWorld 2005: coming to a city near you. Everything you need for SOA and
enterprise infrastructure success.
Register
was one of the things making me reluctant
to switch over to atom:link.
How about:
atom:link rel=subscription href=.../
?
--
Mark Nottingham http://www.mnot.net/
, Thomas Broyer wrote:
Mark Nottingham wrote:
How about:
atom:link rel=subscription href=.../
?
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 equivalent to the containing element.
1. Isn't a resource
majority of cases or
not. What orderings would those terms not work well for?
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
BEAWorld 2005: coming to a city near you. Everything you
=previous href=...feed2 /
link rel=first href=...feed1 /
...
/feed
- James
Mark Nottingham wrote:
At first I really liked this proposal, but I think that the kind
of confusion you're concerned about is unavoidable; the terms you
refer to suffer bottom-up vs. top-down.
I think
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 especially against it,
but what's the use case?
On 14/10/2005, at 4:53 PM, Mark Nottingham wrote:
Right. A few
great unless there's a compelling need for it.
--
Mark Nottingham http://www.mnot.net/
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/
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 the CTO BEA Systems
--
Mark
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 Technologist
Office of the CTO BEA Systems
--
Mark
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/
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 Nottingham wrote
:
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/
PROTECTED] - http://engrm.com/blogometer/
--
Mark Nottingham http://www.mnot.net/
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/
their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Snell Expires March 5, 2006
[Page 5]
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
--
Mark Nottingham
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-atompub-
feed-history-04.txt
Changes:
- fh:stateful - fh:incremental
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/
as interesting.
--
Mark Nottingham http://www.mnot.net/
of the feed.
thoughts?
- James
Mark Nottingham wrote:
Feed History -04 is out, at:
http://www.ietf.org/internet-drafts/draft-nottingham-atompub-
feed- history-04.txt
Changes:
- fh:stateful - fh:incremental, with appropriate changes in text
- more explicit cardinality information
- 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/
, 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?
No. I'm saying that if Netflix
lists – they are feeds.
bob wyman
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
--
Mark Nottingham http://www.mnot.net/
by an
implementor)
--
Mark Nottingham http://www.mnot.net/
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'?
I.e., instead
). And it does not give me anything
very intersting when I look at it in either Safari or Firefox.
Thanks for pointing this out. :-)
:-)
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
it?
--
Mark Nottingham http://www.mnot.net/
, the stream from there on out
would
be identical.
- Sam Ruby
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
, are very hard to keep open permanently or
for a very
long period of time. One is often considered lucky if you can keep
an HTTP
connection open for 5 minutes without having to re-initialize...
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
=./
archives/archive1.atom
Henry Story
[1] http://www.imc.org/atom-syntax/mail-archive/msg16643.html
On 15 Aug 2005, at 22:31, Mark Nottingham wrote:
Draft -03 of feed history is now available, at:
http://www.ietf.org/internet-drafts/draft-nottingham-atompub-
feed-history-03.txt
an
archive is would necessitate ruling some types of archives out, and
that wasn't my main use case for this; rather, it was to make sure
that archive feeds (as defined for the purposes of this spec)
wouldn't be accidentally subscribed to.
Cheers,
--
Mark Nottingham http://www.mnot.net/
the
applicability of context based on the presence or absence of other
markup isn't good practice, and will lead to practical problems.
E.g., what if I want to have an optional attribute on an empty
element? Is it simple or complex?
This interpretation of extensions seems very fragile to me.
--
Mark
and otherwise helped so
far. Sorry!
--
Mark Nottingham http://www.mnot.net/
.
Speaking *strictly* about cache control of Atom documents, +1. No
document level mechanisms for cache control are necessary.
- James
Mark Nottingham wrote:
HTTP isn't a transport protocol, it's a transfer protocol; i.e.,
the caching information (and other entity metadata) are *part
of the data (the archive feed).
E.g.,
atom:feed
...
archive:yes_im_an_archive/
/atom:feed
By (current) definition, anything that history:prev points to is an
archive.
Cheers,
--
Mark Nottingham http://www.mnot.net/
and HTTP. It is helpful to have a transport
independent expiration/max-age mechanism whose semantics operate on
the application layer rather than the transport layer.
- James
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
. As a
consequence, it is recommended that protocol designers provide
specific guidelines to address white space handling within
protocols
that use XML.
--
Mark Nottingham http://www.mnot.net/
to resources. It is that general.
Both require coding effort.
e.
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
(e.g., ordering, deletion, exact
semantics of an archive feed, etc.), so that they could be separately
defined.
Cheers,
--
Mark Nottingham http://www.mnot.net/
the entire feed (which I agree
would be a problem).
Cheers,
--
Mark Nottingham http://www.mnot.net/
thought about the comments on the plane yesterday, and I agree.
However, I'm wary of special URI values; also, I want to preserve
stateful=false.
So, what about saying that you can omit fh:stateful *if* fh:prev is
in the feed?
--
Mark Nottingham http://www.mnot.net/
1 - 100 of 167 matches
Mail list logo
