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
as to gather
implementation feedback.
Cheers,
--
Mark Nottingham http://www.mnot.net/
] http://www.joseki.org/protocol.html
[9] http://sw.nokia.com/uriqa/URIQA.html
--
http://dannyayers.com
--
Mark Nottingham http://www.mnot.net/
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
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
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
:
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/
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
.
___
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
markup
from the Atom vocabulary will be considered foreign markup.
== Impacts ==
== Notes ==
--
Mark Nottingham http://www.mnot.net/
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
+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
, 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
knowledgeable people ;)
--
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/
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/
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
-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
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/
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/
, 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 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/
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
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/
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
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
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
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/
101 - 167 of 167 matches
Mail list logo
