all of the snapshots back in
time)
Best leave it up to the client.
I don't think this follows, for reasons explained above. Only the
server can determine what a complete set of entries is.
Cheers,
--
Mark Nottingham http://www.mnot.net/
FYI, I've put 'this' and 'prev' elements on my RSS feed as a
proof-of-concept on the server side; see
http://www.mnot.net/blog/index.rdf
This was done with templates only on stock Moveable Type 2.6.
--
Mark Nottingham http://www.mnot.net/
Not to advocate one position or another, but RFC 3987 doesn't obsolete
RFC 3986; we have a choice.
On Jan 24, 2005, at 4:17 PM, Tim Bray wrote:
If there were no further discussion: It's hard to see how to avoid
adopting this now that IRIs are standards-track RFC. -Tim
--
Mark Nottingham
The atom:info Element -- If it's not considered meaningful for
processors, why does there need to be a standard element for it? At the
very least, some sort of information about its semantics should be
documented. My preference would be to drop it.
--
Mark Nottingham http://www.mnot.net/
On Jan 30, 2005, at 9:07 AM, Robert Sayre wrote:
Mark Nottingham wrote:
My gut feeling is that removing the markup from these elements will
make the spec much simpler and easier to implement, without
sacrificing many (if any) use cases. If I'm not aware of someone's
use case here, I'm sorry
terms? -Tim
--
Mark Nottingham http://www.mnot.net/
to the entry or
feed.
Cheers,
On Jan 30, 2005, at 3:58 PM, Bill de hÓra wrote:
Robert Sayre wrote:
Mark Nottingham wrote:
* 4.11 The atom:host Element -- I'm surprised to see this in an
IETF specification; people are going to make bad assumptions about
the content of this, and violate layering
links.
Cheers,
On Jan 30, 2005, at 2:57 PM, Sam Ruby wrote:
Here is a live example of atom:info in use:
http://www.shellen.com/atom.xml
View source. View in your favorite browser.
- Sam Rubys
--
Mark Nottingham http://www.mnot.net/
Documents
** 10 Security Considerations
proposal: Perhaps we can move everything security related into section
10 and drop section 6. (pace forthingcoming)
Sounds like a good idea, but I don't feel strongly about it if anyone
wants it the way it is.
Cheers,
--
Mark Nottingham http://www.mnot.net/
On Jan 30, 2005, at 7:03 PM, Graham wrote:
On 31 Jan 2005, at 2:40 am, Mark Nottingham wrote:
which is the same feed, but with atom:info replaced by a 'foo'
element.
Even better, you can drop foo and put the xhtml div as a direct child
of feed. Then use feed div as the selector.
Nice
a section with this name is asking for
trouble.
We could change it to Not Dereferencing Identity Constructs...
How about Dereferencability of Identity Constructs?
--
Mark Nottingham http://www.mnot.net/
, at 7:53 PM, Robert Sayre wrote:
Mark Nottingham wrote:
So, the relevant question seems to be whether any browsers do
something interesting with +xml media types;
No, the relevant question is whether +xml media types can be reliably
dispatched without any knowledge of a specific scheme. I don't
to specify and
enforce).
If the concern about multiple content is solely that it will result in
more bandwidth use, I think it's misplaced; people who are concerned
about bandwidth won't publish multiple representations inline; forcing
them not to by legislation is misguided.
--
Mark
of this specification, but may be defined by an extension to
Atom.
]]]
So, if we drop PaceFeedState, I propose the text above.
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
this
idea, and I meant to update the draft. Would anyone be upset if I
updated the draft to say an aspect ratio of 2 (horizontal) to 1
(vertical)? -Tim
--
Mark Nottingham http://www.mnot.net/
elements within the feed. Processors MAY present entries in
a different order to which they are appear in an Atom Feed Document.
--
Mark Nottingham http://www.mnot.net/
/| things.--Oliver Wendell Holmes
--
Mark Nottingham http://www.mnot.net/
. In the threads on
atom:info, it seems I am playing the role of solo raving loony. So,
let's have the process take over.
Robert Sayre
--
Mark Nottingham http://www.mnot.net/
.
--Paul Hoffman, Director
--Internet Mail Consortium
--
Walter Underwood
Principal Architect, Verity
--
Mark Nottingham http://www.mnot.net/
This is now PaceNoFeedState;
http://www.intertwingly.net/wiki/pie/PaceNoFeedState
On Jan 31, 2005, at 3:46 PM, Mark Nottingham wrote:
x. Managing Feed State
Atom Processors MAY keep state (e.g., metadata in atom:head, entries)
sourced from Atom Feed Documents and combine them with other Atom
the complete state of a feed
-joe
On Mon, 24 Jan 2005 16:17:42 -0800, Tim Bray [EMAIL PROTECTED]
wrote:
If there were no further discussion: Like PaceSupersede, this model of
publishing does not (so far) enjoy consensus support. -Tim
--
Joe Gregoriohttp://bitworking.org
--
Mark
to a
typical human mental model. The word feed has entered the
vocabulary, even the non-geek vocabulary, and the notion that there
are things (entries, stories, items, whatever) in feeds likewise.
--
Mark Nottingham http://www.mnot.net/
flexible approach - it moves us away from agents coordinating
together to agents enforcing policy on one another via a profiling
mechanism.
--
Mark Nottingham http://www.mnot.net/
, this will seem quite natural. If you want to only
see one instance of an atom:id's content in the set of all entries ever
published in any feed, you need to say that explicitly.
--
Mark Nottingham http://www.mnot.net/
?
On Feb 3, 2005, at 11:27 PM, Tim Bray wrote:
On Feb 3, 2005, at 8:17 PM, Mark Nottingham wrote:
This specification describes Atom's XML markup vocabulary.
Markup from
other vocabularies (foreign markup) can be used in Atom in
a variety of
ways. Text Constructs may contain
.
I've said my piece on this one; I'm interested in responses to my other
questions and points.
Cheers,
On Feb 4, 2005, at 2:15 PM, Robert Sayre wrote:
Mark Nottingham wrote:
It certainly gives the impression that there's a preference; it's
like saying The language of the feed SHOULD be English
When you talk about characters being the same or different, are you
saying in the entry, or in the id?
On Feb 4, 2005, at 2:18 PM, Graham wrote:
On 4 Feb 2005, at 10:09 pm, Mark Nottingham wrote:
The term version seems out of place here. What you're saying, in
effect, is that the ID acts
monitoring or blog entry? How would a UA present this?
On Feb 4, 2005, at 8:15 AM, Bill de hÓra wrote:
Mark Nottingham wrote:
Bill,
I'm sorry, I don't think I get what you're saying; the words all make
sense, but I don't know how you got here.
[../]
The Pace doesn't place any requirements on Atom
to display more than one
version of each resource.
Comments? Preferences? Better ideas? Is it ready for a Pace?
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
On Feb 5, 2005, at 6:26 AM, Joe Gregorio wrote:
On Thu, 3 Feb 2005 20:25:50 -0800, Mark Nottingham [EMAIL PROTECTED]
wrote:
My preference would be something like
This specification assigns no significance to the order of atom:entry
elements within an Atom Feed Document. Atom Processors MAY
interested in archiving all the entries,
then any new feed
be it an old one or a new one will be of interest: it will just be
added to the database.
+1
--
Mark Nottingham http://www.mnot.net/
, in the form When
present, atom:title MUST occur exactly once. Profiles only constrain
what metadata elements are required in the feed.
Regards,
--
Mark Nottingham http://www.mnot.net/
On Feb 13, 2005, at 2:52 AM, Eric Scheid wrote:
On 13/2/05 11:49 AM, Mark Nottingham [EMAIL PROTECTED] wrote:
The biggest change from the previous approach is that cardinality of
metadata elements is specified by those elements, in the form When
present, atom:title MUST occur exactly once
On Feb 13, 2005, at 2:03 AM, Anne van Kesteren wrote:
Mark Nottingham wrote:
Apologies for the delay; I've been sick since Monday.
I've revised PaceProfile to make it more complete, as requested.
http://www.intertwingly.net/wiki/pie/PaceProfile
The biggest change from the previous approach
it, but are not
required to do so.
I'll beef this text up to be more explicit, along the lines above.
Thanks!
--
Mark Nottingham http://www.mnot.net/
for inclusion, rather than doing it via attribute/element name
choice. Note that the deferencability of identifiers changes over time,
as infrastructure is deployed (or rots away); eg. DOIs, gopher:, java:
URIs...
Dan
--
Mark Nottingham http://www.mnot.net/
-Draft with a media type registration
would
register the type, yes. Whether we should try to register application/
rss+xml is a different question though.
D'oh, Randy wanted rss+xml, not atom+xml. Missed the point. -Tim
--
Mark Nottingham http://www.mnot.net/
it's more an issue of whether the CC Attribution + ShareAlike 1.0
license terms are satisified by the I-D boilerplate. I've just asked CC
that very question...
On Mar 29, 2005, at 10:01 PM, Robert Sayre wrote:
Mark Nottingham wrote:
I tried; the official response [1] was that the IESG wanted
On Mar 31, 2005, at 10:07 AM, Henry Story wrote:
The value alternate signifies that the containing element is an
alternative
representation of the IRI in the value of the href attribute.
...an alternate representation of the resource identified by the IRI in
the value...?
--
Mark Nottingham
this earlier).
Finally, has someone doubled-checked with IANA that the
http://www.iana.org/assignments/relation/; URI is available and
appropriate?
--
Mark Nottingham http://www.mnot.net/
. 60561
http://www.tbray.org/ongoing/ AIM: MarkupPedant
--
Mark Nottingham http://www.mnot.net/
the request ASAP.
--
Mark Nottingham http://www.mnot.net/
approach is to change it so that IETF Consensus,
rather than IESG approval, is required to register a link relation).
Anybody have thoughts?
On Apr 6, 2005, at 5:13 PM, Mark Nottingham wrote:
Section 1.2: please reference draft-crocker-abnf-rfc2234bis-00.txt
instead
of RFC 2234 and confirm
Oops; I meant draft-freed-media-type-reg.
On Apr 6, 2005, at 5:13 PM, Mark Nottingham wrote:
Section 4: RFC 2045 is referenced. 2045 is on its way to being
obsoleted by
draft-freed-mime-p4 (in the RFC Editor queue) and
draft-freed-media-type-reg
(in last call). Can the more recent documents
Is media type an accurate term for us to use?
I'm asking this because I really don't know whether parameters are
supposed to be allowed in the type attribute or not.
--
Dave
--
Mark Nottingham http://www.mnot.net/
knowledgeable people ;)
--
Mark Nottingham http://www.mnot.net/
, I noticed something else that I missed my first time through ...
On Wed, Apr 06, 2005 at 08:41:08PM -0700, Mark Nottingham wrote:
Additional information:
Magic number(s): As specified for application/xml in [RFC3023],
section 3.2.
Based on my understanding of the purpose of magic numbers
+1
On Apr 25, 2005, at 5:10 PM, Tim Bray wrote:
On Apr 25, 2005, at 3:49 PM, Mark Nottingham wrote:
Comments on the media type template.
He's got a point on the namespace being mentioned, which creates some
semi-circular dependencies, sigh. As to whether it's currently in
use, largely due
valuable like atom:title, it should be a MUST.
--Paul Hoffman, Director
--Internet Mail Consortium
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
markup
from the Atom vocabulary will be considered foreign markup.
== Impacts ==
== Notes ==
--
Mark Nottingham http://www.mnot.net/
.
___
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce
--
Mark Nottingham http://www.mnot.net/
to reconstruct the full state of the
feed, and SHOULD warn the user.
Also, I just noticed that in some places, the word representation
is used, and in some places instance is used, apparently to mean
the same thing. In my opinion, instance is better.
I'll take a look.
Thanks again!
--
Mark
Thanks Garrett, I'll take this into account if I do another draft.
Cheers,
On 28/06/2005, at 1:39 PM, Garrett Rooney wrote:
Mark Nottingham wrote:
A New Internet-Draft is available from the on-line Internet-
Drafts directories.
Title : Feed History: Enabling Stateful
all the
work, and especially assuming a batches of 15 sort of model, the
this link seems likely to end up pointing to a document that's
going to disappear soon 14 times out of 15.
--
Mark Nottingham http://www.mnot.net/
reviews, because it requires a lot of work to maintain, and can be a
bandwidth hog. I'm of two minds about it.
--
Mark Nottingham http://www.mnot.net/
. Would not that be as reliable
as checking the this link?
On Wednesday, June 29, 2005, at 12:10 AM, Mark Nottingham wrote:
You need to be able to figure out which documents you've seen
before and which ones you haven't, so you don't recurse down the
entire stack. Although you can come up
:
atomex:treatAsstateful list/atomex:treatAs
Indicates that the feed should be treated as a list whose past
states can be queried using the kind of mechanism you've defined.
That seems like an awfully heavyweight solution. What does defining
the container and an IANA registry add?
--
Mark Nottingham
lifetime where
vendors and individuals have to experiment to figure out what's
valuable, and let the market sort out what becomes commonly deployed.
It's not pretty, but it works pretty well in the long run.
Cheers,
--
Mark Nottingham http://www.mnot.net/
it in the format?
Regards,
--
Mark Nottingham http://www.mnot.net/
on the receiver. That would change the wording to:
Atom Processors that verify signed Atom Documents MUST
be able to canonicalize with Canonical XML.
--Paul Hoffman, Director
--Internet Mail Consortium
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
Consortium
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
On 07/07/2005, at 11:36 AM, Paul Hoffman wrote:
At 10:23 AM -0400 7/7/05, Mark Nottingham wrote:
Are we specifying exclusive c14n with or without comments? My
preference would be without.
Without. That is explicitly the default for http://www.w3.org/TR/
2002/REC-xml-exc-c14n-20020718
with all
SHOULDs. In particular, the feed SHOULD contain a link with a
rel='self'.
If I find other deviations from the recommended practices, I'll
note them here.
- Sam Ruby
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
--
Mark Nottingham http
] http://www.joseki.org/protocol.html
[9] http://sw.nokia.com/uriqa/URIQA.html
--
http://dannyayers.com
--
Mark Nottingham http://www.mnot.net/
as to gather
implementation feedback.
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/
documents
never change once created. Then a client can terminate the sync
once it sees a URI it already knows. And most clients would not do
more lookups than they are doing now...
--
Mark Nottingham http://www.mnot.net/
: fh:historyfh:none//fh:history
Hmm. My thinking was that allowing stateful to be omitted would be
concise and unambiguous; to compare,
stateful feed: fh:prevhttp://example.org/thingie1.1/fh:prev
stateful initial feed: fh:statefultrue/fh:stateful
stateless feed: fh:statefulfalse/fh:stateful
--
Mark
(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/
. 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
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
.
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
and otherwise helped so
far. Sorry!
--
Mark Nottingham http://www.mnot.net/
=./
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
, 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
it?
--
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
by an
implementor)
--
Mark Nottingham http://www.mnot.net/
lists – they are feeds.
bob wyman
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
--
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
- 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/
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
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/
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
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
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/
:
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/
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
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
1 - 100 of 167 matches
Mail list logo
