Fwd: Atom format interpretation question

Begin forwarded message: From: John Cowan <[EMAIL PROTECTED]> Date: January 4, 2007 8:08:06 AM PST (CA) To: [EMAIL PROTECTED] Subject: Atom format interpretation question Am I right in thinking that content which is in fact in XML but is labeled with a media type that is neither generic XML no

Re: AD Evaluation of draft-ietf-atompub-protocol-11

On Dec 15, 2006, at 5:00 PM, Lisa Dusseault wrote: I guess I'm assuming that one would want clients to be able to extend Atom unilaterally. That doesn't seem to have been a design goal for the WG. To the extent that the issue never came up in the discussion. The choices that I highlight

Re: AD Evaluation of draft-ietf-atompub-protocol-11

Lisa Dusseault wrote: >>> Can a client modify an entry to contain a link relation element in the >>> following cases: >>> >>> - To point to a resource on a different server entirely? >> >> There is no reason to believe that any of these resource are on >> the same machine to begin with. I could

Re: Atom Entry docs

Bob Wyman wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. In case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few peo

Atom Entry docs

I seems obvious to me that Atom Feed and Entry docs are potentially quite different things which can be used for entirely different purposes. The contention that an Entry doc is somehow really the same as a one-entry Feed doc is entirely unconvincing. The Architecture of the Web (http://www

Re: Atom Entry Documents

Mark Baker wrote: Ok, the recent discussion seems to point towards a consensus towards distinctly flagging Entry Documents in the media type. Erm, isn't it up to the chairs to declare concensus? I agree that there exists sentiment in favor of there being a way to distinguish between Feed a

Re: Atom namespace really not ending with / or # ?

Anne van Kesteren wrote: Jan Algermissen <[EMAIL PROTECTED]> wrote: is it really true that the Atom namespace is http://www.w3.org/2005/Atom ? It wasn't really relevant, I'd say. (That it says "Atom" and not "atom" was a mistake.) I'd agree. Sigh. But not a big one, I think -Tim

Re: PaceEntryMediatype

On Nov 29, 2006, at 8:16 AM, James M Snell wrote: http://www.intertwingly.net/wiki/pie/PaceEntryMediatype #pragma section-numbers off == Abstract == For the current Atom Publishing Protocol draft... Irrespective of the merits of the new media type, the APP spec seems like the wrong place

Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)

On Nov 28, 2006, at 3:16 PM, Robert Sayre wrote: They already know how, in general. The WHAT-WG is the place to work out edge cases in HTML semantics. Over the course of history, a remarkable number of different groups have jumped up and down and said "*We're* the ones defining HTML!!! Li

Re: Author element best practice

On Nov 22, 2006, at 3:11 AM, Sylvain Hellegouarch wrote: Say I POST an atom:entry to a collection URI, this entry does not have an atom:author If I were implementing the server, in this scenario I'd reject the post with an error message. It's hard for me to see a scenario where the autho

URGENT: Remove atom:updated ordering requirement?

Please see the dialogue below. (Eric's point seems plausible to me; personally I'd be inclined to a +1.) Can we have some feedback from the WG ASAP? We want to take protocol-11 to the IETF. -Tim On Sep 26, 2006, at 4:59 PM, Eric Scheid wrote: On 27/9/06 8:15 AM,

Re: WG Last Call for draft-ietf-atompub-protocol

On Sep 26, 2006, at 12:34 PM, Sam Ruby wrote: Here's a list of Paces that weren't disposed of with the last consensus call: First of all, did Sam get them all? Please speak up soonest about anything that was missed and might have a realistic chance. PaceAppEdited: Lots of discussion.

Re: I-D ACTION:draft-ietf-atompub-protocol-10.txt

On Sep 12, 2006, at 1:23 PM, Joe Gregorio wrote: FYI And of course there's an HTML version at http://bitworking.org/ projects/atom/ -Tim

Re: versioning extension?

On Sep 11, 2006, at 4:39 PM, Jan Algermissen wrote: If I am not completely wrong, versioning is definitely an issue if you want to employ Atom in beyond-blogging contexts. Most people that deal with collections of items are definitely interested in keeping track of the former versions of t

Re: versioning extension?

On Sep 11, 2006, at 3:40 PM, Jan Algermissen wrote: is anybody working on (or planning to work on) a versioning extension for Atom? I am about to use Atom in two (considerably different) projects that require versioning and would be happy to join forces and contribute real (enterprise-)wor

Re: Private extensions and relation to atom elements

On Sep 11, 2006, at 7:45 AM, James Aylett wrote: Feed Validator gets upset with extension attributes - is it wrong? Be specific, please? -Tim

Re: Private extensions and relation to atom elements

On Sep 11, 2006, at 4:27 AM, James Aylett wrote: We've run across a situation where we want to annotate an atom:icon with a title. Currently we're doing the following, as something that Feed Validator is happy with, but doesn't feel right:

Re: atom:updated - not now() values?

Eric Scheid wrote: When updating an entry, is it acceptable to insert a value other than Now() into atom:updated? Clearly, since updated is defined as the time the publisher thinks it was significantly updated. Of course, the server could over-write the updated value if it chose. -Tim F

Re: Link rel test cases

On May 30, 2006, at 5:25 PM, James Holderness wrote: I agree completely, but as a content consumer I still need to know whether to use IRI::Compare or String::Compare when I do encounter some ridiculous feed that uses example (a). I'm hoping for a simple answer along the lines of "Use IRI:

Re: Feed Thread in Last Call

On May 20, 2006, at 8:49 AM, David Powell wrote: (at great length) I'm going to re-organize David's argument a little and deal with one of his last points first. Foreign attributes are bad, and are inherently less interoperable than Extension Elements. I would say that furious debates abo

Re: Fyi, Apache project proposal

On May 23, 2006, at 8:35 AM, James M Snell wrote: The goal is to have a reference implementation that is also usable. However, I do have to be careful here, the IETF doesn't really do reference implemenations so the naming of this project is a bit wrong. We really shouldn't be calling it a "ref

Re: Feed Thread in Last Call

On May 18, 2006, at 6:15 AM, David Powell wrote: What I see as a problem is that reasonable implementations will not preserve Atom documents bit-for-bit, so they will need to explicitly support this draft if they don't want to corrupt data by dropping the thr:count attributes. By the letter of

Re: Feed Thread in Last Call

On May 17, 2006, at 12:46 PM, Byrne Reese wrote: Speaking up: http://www.majordojo.com/atom/ standardizing_the_atom_thread_extension.ph p No surprise I guess, but I am a huge +1. Lock this spec down and ship it. Me too. Does something useful, does no harm, if it's broken in some way it

Re: Feed thread update

On May 4, 2006, at 7:10 PM, James M Snell wrote: At issue is whether or not authors of standardized extensions should extend elements with undefinedContent when we know full well that there are API implementations out there that have made the extremely shortsighted decision to completely ignore

Re: Feed thread update

On May 4, 2006, at 5:08 PM, A. Pagaltzis wrote: The assertion is not that atom:link may not have child elements or namespaced attributes. The assertion is that the list of locations for Metadata elements in Section 6.4 should have included atom:link. Mountain, meet molehill. If it turns out

Re: Feed thread update

On May 4, 2006, at 5:25 PM, Kyle Marvin wrote: the motivation behind sometimes using 'extensionElement' and other times 'undefinedContext' in the Relax-NG schemas for various 4287 elements is a point of confusion. Agreed. Fortunately the schema's non-normative. -Tim

Re: Feed thread update

On May 4, 2006, at 3:43 PM, Thomas Broyer wrote: Things would have been far easier if either a) atom:link were extensible This assertion that atom:link is not extensible is simply, flatly, completely, wrong. I just went and reviewed 4287 and I think it is perfectly clear on this. I sugg

Re: Does xml:base apply to type="html" content?

On Mar 30, 2006, at 9:20 PM, James M Snell wrote: I would agree that, as a best practice, the xml:base should appear on the content element, but implementations need to be prepared to use whatever the in-scope URI is (e.g. if no xml:base is specified, relative refs in the content will be re

Re: atom:name ... text or html?

On Mar 23, 2006, at 2:20 PM, Eric Scheid wrote: Oh well, now to track down a list of html entities and their corresponding unicodes ... http://www.google.com/search?q=xhtml%20entities

Re: Does xml:base apply to type="html" content?

On Mar 23, 2006, at 10:03 AM, David Powell wrote: xml:base applies to type="xhtml" content, but I'm not sure whether it is supposed to apply to escaped type="html" content? I reckon that it does. RFC4287, section 2: Any element defined by this specification MAY have an xml:base attr

Re: atom:name ... text or html?

On Mar 23, 2006, at 8:16 AM, Eric Scheid wrote: If I have an author with the name "Bertrand Café", is it acceptable to put that into atom:author like this; or should I be using the unicode numeric entity instead? The key point is that the atom:name element, described in RFC4287 3.2

Re: atom:name ... text or html?

On Mar 23, 2006, at 8:57 AM, Eric Scheid wrote: On 24/3/06 3:21 AM, "Anne van Kesteren" <[EMAIL PROTECTED]> wrote: Even if it was "HTML" you couldn't really use the entity, could you? I think you have to use a character reference or the actual character instead, yes. It's true

Re: atom:name ... text or html?

On Mar 23, 2006, at 8:01 AM, Sylvain Hellegouarch wrote: Seriously though, the atom:name element is described as "a human- readable name", Do you mean that "human-readable" is equivalent to solely English? Because as a French, having accents in names is so natural that I see it as "hu

Re: IE7 Feed Rendering Issue

On Mar 9, 2006, at 7:51 AM, Sean Lyndersay wrote: I hope this helps make the reasoning behind IE’s behaviour with feeds and stylesheets a little less murky. I don't really have an opinion as to whether this is the ideal behavior. But there is no doubt whatsoever that that Sean's software

Re: Atom logo where?

On Mar 6, 2006, at 12:43 PM, Anne van Kesteren wrote: Quoting Tim Bray <[EMAIL PROTECTED]>: Where can one go to get versions of the atom logo (the one in view at atomenabled.org) in various sizes? -Tim I guess SVG fits that definition: http://zcorpan.1go.dk/sandbox/svg/atom/.xml

Atom logo where?

Where can one go to get versions of the atom logo (the one in view at atomenabled.org) in various sizes? -Tim

Re: [rss-public] Microsoft Feeds API Enclosure Test

On Feb 24, 2006, at 3:05 PM, Sean Lyndersay wrote: I'm sure that many people -- on this list in particular -- think that the right thing to do is to normalize to Atom 1.0, instead. Yep, that's certainly one way to think about it. But then I'd be having this same discussion with Dave and wi

Re: Browser behaviour

On Jan 30, 2006, at 12:57 PM, John Panzer wrote: In other words, the application/xml content is a fallback for when users, despite our best efforts, end up looking at XML content inside a web browser. I'd also be happy to make this behaviior browser-dependent so that we serve application/

Re: Browser behaviour

On Jan 30, 2006, at 8:23 AM, James M Snell wrote: +1. Serving atom up at application/xml is perfectly acceptable It is *not*. Atom has a registered Internet media type (application/ atom+xml); using anything else is a bug. -Tim

Re: [Fwd: Approval of Atom LinkRelations Attribute Value Registrations]

On Jan 25, 2006, at 11:56 AM, James M Snell wrote: APP should use the values as registered. That is, previous, next, first, last and current. No need to modify the registrations. +1

Re: finishing autodiscovery, like now

On Jan 19, 2006, at 9:05 AM, Robert Sayre wrote: PaceAnchorSupport and PaceDifferentRelValue don't seem very useful, and they weren't proposed by implementors. The spec is extremely well-written and reflects existing behavior. Can we please un-expire this: http://philringnalda.com/rfc/draft-

Re: Reader 'updated' semantics

On Jan 10, 2006, at 9:07 AM, James M Snell wrote: In RSS there is definite confusion on what constitutes an update. In Atom it is very clear. If changes, the item has been updated. No controversy at all. Indeed. There's a word for behavior of RssBandit and Sage: WRONG. Atom provi

Re: Reader 'updated' semantics

On Jan 9, 2006, at 5:08 PM, James M Snell wrote: The updated element is used to indicate when a significant update has occurred to the entry. If you are updating the updated element when you update your entry, you are doing the right thing. If RSSBandit and FeedDemon are not picking up t

Re: Category URI's

On Jan 9, 2006, at 1:12 PM, James M Snell wrote: I'm in the process of going through a number of application scenarios with Atom and I'm coming up with a problem because I cannot associate a URI with a element. From my Atom feed: term='Technology/XML' /> The scheme is identified by a U

Re: Tag URIs

On Dec 17, 2005, at 9:01 PM, Alan Gutierrez wrote: I'm to understand that Atom has adopted the Tag URI as a a perferred. GUID for an Atom 1.0 feed. It has not. There is no preferred scheme. -Tim

Re: clarification needed: order of children of atom:entry

On Oct 26, 2005, at 9:46 PM, Eric Scheid wrote: Section 4.1.2 of the Atom Syndication Format spec states this: "This specification assigns no significance to the order of appearance of the child elements of atom:entry." Is this referring to the immediate children only of atom:entry,

Re: How to represent an authenticated identity in an tag

On Oct 25, 2005, at 5:02 PM, Byrne Reese wrote: The above is accomodated by the current spec, but the following is something we would also like to represent somehow in a standard way: * their authenticated identity (e.g. "breese") and the authenticating authority (e.g. "LiveJournal," "TypeKey,

Re: New Link Relations -- Ready to go?

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 descriptive (its definition *only* says it should be used to link to the current document; -11 says nothing

Re: New Link Relations -- Ready to go?

On Oct 22, 2005, at 3:28 AM, Eric Scheid wrote: I think you've got the special case turned around. That is, if you are looking at a representation of the active feed then the 'self' link would happen to match the 'subscribe' link, which is the exception. The defining text in the spec says

Re: New Link Relations -- Ready to go?

On Oct 21, 2005, at 5:03 PM, Mark Nottingham wrote: How about: - Description: A URI that refers to a feed document containing a set of the most recent entries in the feed. This URI is intended to be subscribed to to keep abreast of recent changes in the feed; when different from the UR

Re: New Link Relations -- Ready to go?

On Oct 21, 2005, at 3:13 PM, Mark Nottingham wrote: - Description: A URI that refers to a feed document containing a set of the most recent entries in the feed. This URI is intended to be subscribed to to keep abreast of recent changes in the feed. When different from the URI of the docu

Re: New Link Relations -- Ready to go?

On Oct 21, 2005, at 7:38 AM, James Holderness wrote: The idea being that if you were to come across an archived Atom document (however that might happen), the presence of this link would, (a) let you know that it was an archive document and thus shouldn't be subscribed to, and (b) provide

Re: New Link Relations -- Ready to go?

On Oct 20, 2005, at 4:52 PM, Mark Nottingham wrote: - Attribute Value: subscribe I'm puzzled by this one. I thought that if you wanted to subscribe to a feed then, well, you would subscribe to a feed. I must have missed the discussion. Could someone provide a pointer to the archive

Re: Question about [EMAIL PROTECTED]

On Oct 7, 2005, at 10:20 AM, Byrne Reese wrote: Are there any good examples of how the [EMAIL PROTECTED] attribute is used? Over at 'ongoing', I have my own set of categories, so my category elements look like Remember, it's optional, both for the producer and for the consumer (Techno

Re: Atom 1.0 ootb with MT3.2

On Sep 9, 2005, at 5:03 AM, Bill de hÓra wrote: Here's the feedvalidator results for my journal served up as Atom1.0 as per MT3.2's Atom1.0 template http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.dehora.net% 2Fjournal%2Fatom.xml I'm getting a 404 on that (or rather the feedVa

Re: "Top 10" and other lists should be entries, not feeds.

On Aug 30, 2005, at 3:08 PM, Walter Underwood wrote: That is one kind of order. Other kinds are relevance to a search term (A9 OpenSearch), editorial importance (BBC News feeds), or datetime of original publication (nearly all blog feeds, not the same as last update). Well put. It's obviou

Re: If you want "Fat Pings" just use Atom!

On Aug 22, 2005, at 9:56 PM, Bjoern Hoehrmann wrote: If you encounter a busted tag on the Nth entry, per the XML spec that's a fatal error and you can't process any more. That's a bit misleading, a fatal error just means that the XML processor must report the error to the application and that

Re: If you want "Fat Pings" just use Atom!

On Aug 22, 2005, at 9:27 PM, A. Pagaltzis wrote: It's got another advantage. You connect and ask for the feed. You get http://www.w3.org/2005/Atom";> ... goes on forever and none of the entry documents need to redeclare the Atom namespace, which saves quite a few bytes after th

Re: If you want "Fat Pings" just use Atom!

On Aug 23, 2005, at 6:57 AM, Bjoern Hoehrmann wrote: That's a bit misleading, a fatal error just means that the XML processor must report the error to the application and that the processor is not required by the XML specification to continue processing; doing so is however an optional feature.

Re: If you want "Fat Pings" just use Atom!

On Aug 22, 2005, at 6:15 PM, Justin Fletcher wrote: Ah; I misread that in the specification. Thanks. It's just the lack of well-formedness that is an issue in my head then. If you encounter a busted tag on the Nth entry, per the XML spec that's a fatal error and you can't process any more.

Re: If you want "Fat Pings" just use Atom!

On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote: Essentially, LiveJournal is making this data available to anybody who wishes to access it, without any need to register or to invent a unique API. Ahh, I had thought this was a more dedicated ping traffic stream. The never ending Atom documen

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

On Aug 21, 2005, at 1:42 PM, A. Pagaltzis wrote: * Paul Hoffman <[EMAIL PROTECTED]> [2005-08-21 21:55]: Ah, I had missed that. This leads to a question for the mailing list. Does an informative extension that appears at the feed level (as compared to in entries) indicate: d) completely unk

Re: Feed History -03

On Aug 17, 2005, at 4:10 AM, Henry Story wrote: Yes. I agree the problem also exists for complex extensions. My question is the following: How can a parser that parses atom and unknown extensions, know when to apply the xml base to an extension element automatically? It can't. Anyway t

Re: xml:base abuse

On Aug 15, 2005, at 7:28 AM, Tim Bray wrote: The way Tim Bray's feed and the examples from James Snell on developerWorks use xml:base is what Roy T. Fielding calls an abuse. I disagree with Roy, but agree that the way my links were set up was a little surprising to the eye, so I tw

Re: xml:base abuse

On Aug 15, 2005, at 6:20 AM, Sjoerd Visscher wrote: Hi, A while ago we had a discussion about how xml:base should be used. We didn't reach a conclusion, but I think we need to act. The way Tim Bray's feed and the examples from James Snell on developerWorks use xml:base is what Roy T. Fiel

Re: Spec explanations for Pebble?

On Aug 13, 2005, at 1:34 AM, Simon Brown wrote: Just to quote an example, Tim is currently using URL based Atom IDs, such as : http://www.tbray.org/ongoing/ http://www.tbray.org/ongoing/When/200x/2005/08/09/Web-2.0 If Tim *moves* his blog to www.timbray.com/ongoing, would you expect his A

Re: Spec explanations for Pebble?

On Aug 12, 2005, at 1:55 AM, Graham Parks wrote: "categorization scheme" means the system used to categorize entries. Presumably each blog has its own system for doing so, so the scheme attribute should be the same for all posts from the same blog, and unique to the blog. Mostly agree.

Re: More about Extensions

On Aug 9, 2005, at 5:11 PM, David Powell wrote: No, we just need to warn publishers (and extension authors) that the base URI of Simple Extension elements is not significant, and that they must not expect it to be preserved. Either the software understands the foreign markup, in which case it

Re: spec bug: can we fix for draft-11?

On Aug 3, 2005, at 6:04 AM, Sam Ruby wrote: To an Infoset person, this following is a completely different stream from the example above (please ignore any line breaks that your email client may insert): http://exam ;ple.com/fooatom:id> I believe this is incorrect, see http://www.w3.org/TR/

Re: spec bug: can we fix for draft-11?

On Aug 7, 2005, at 5:41 PM, Bill de hÓra wrote: Exclusive canonicalization (which is the one we care about here) like canonicalization keeps whitespace inside element content significant. Those bytes are counted. I take that as meaning in the dsig case, trimming is broken. The c14n/dsig imple

Re: spec bug: can we fix for draft-11?

On Aug 4, 2005, at 1:04 PM, Sam Ruby wrote: Tim Bray wrote: I'm getting increasingly grumpy and "just fail" is looking better and better. The current normative text, "The element's content MUST be an IRI", is clear and simple and supported by other

Re: Simple Extensions and xml:base

On Aug 5, 2005, at 5:59 AM, David Powell wrote: We say that Simple Extension Elements are not language sensitive, but They *are* affected by xml:base. xml:base establishes the base URI for wherever it's in-scope, with a specific callout to RFC3986 for the semantics. Anytime you see somethin

Re: Comments Draft

On Aug 4, 2005, at 10:59 PM, Eric Scheid wrote: http://www.example.com/atom"; type="application/atom+xml" thread:idref="urn:foo:1" /> this way processors that have a basic understanding of what a is can still do something useful. Uh, consider http://example.org/e

Re: spec bug: can we fix for draft-11?

On Aug 4, 2005, at 7:24 PM, Robert Sayre wrote: Leading and trailing whitespace input for these fields should be discarded by a robust scanner, and doing so proposes no risk to compliant feeds, unlike guessing the "true meaning" of an ampersand in an RSS feed. So, it will be my recommendation t

Re: Simple Extensions and xml:base

On Aug 4, 2005, at 11:21 PM, David Powell wrote: We say that Simple Extension Elements are not language sensitive, but we don't say that Simple Extension constructs aren't affected by xml:base. I think that the implication is that they are not, but it is not very explicit: They *are* affecte

Re: spec bug: can we fix for draft-11?

On Aug 4, 2005, at 6:53 AM, Robert Sayre wrote: I propose trying harder, but I am open to "just fail". As am I. I am not OK with a long treatise on whitespace, like the one Tim suggested. If there is a MUST-breaking error in a feed, that's not an Atom document and I don't want to talk about

Re: spec bug: can we fix for draft-11?

On Aug 4, 2005, at 3:25 AM, Paul Hoffman wrote: At 7:37 PM -0400 8/2/05, Robert Sayre wrote: One way of saying this would be "Atom Processors MAY ignore leading and trailing whitespace in _." That works for me. Another idea is "Atom Processors MAY ignore leading and/or trai

Re: spec bug: can we fix for draft-11?

On Aug 2, 2005, at 4:37 PM, Robert Sayre wrote: One way of saying this would be "Atom Processors MAY ignore leading and trailing whitespace in _." That is, no existing software is buggy, but if you want to be sure your document is processed accurately, you should trim the space your

Re: Atom 1.0 xml:base/URI funnies

discussed it? I wonder how many people are aware of it. I wonder if we managed to convince any readers on the atom list at all. Tim Bray hasn't responded yet, so I guess he is still in doubt. Yeah, still thinking, haven't had time enough to think about all this correspondence. -Tim

Re: Atom 1.0 xml:base/URI funnies

On Jul 17, 2005, at 8:16 AM, Sam Ruby wrote: Upon further reading of 3986, I'm convinced that Tim's current feed is correct. I think so too, but I'm worried how XML-reader implementations will do supporting all this base-URI stacking. If this kind of thing is going to cause breakage, ma

Re: Atom 1.0 xml:base/URI funnies

On Jul 16, 2005, at 11:20 AM, Tim Bray wrote: I got an email last night from a well known syndication implementor pointing out an obvious bug in my Atom feed. The feed's valid, but the stuff in was full of relative URIs which were broken because I'd borked the xml:base.

Re: Atom 1.0 xml:base/URI funnies

On Jul 16, 2005, at 1:28 PM, Sam Ruby wrote: I didn't realize that "path-empty" was a valid URI-reference. Yeah, it means "here". While it clearly shouldn't be the default behavior, longer term (i.e., sometime well after basic Atom 1.0 support is more complete), how much value do you thi

Atom 1.0 xml:base/URI funnies

right and ruthlessly pruned all the pointers. The feed looks a little weird and it's giving the (pre-alpha) validator a heartburn, but I sort of think it's right. I also think it's good practice. Check it out: ongoing rsslogo.jpg /favicon.ico 2005-07-16T11:17:23-08:00 Ti

Re: The Atomic age

On Jul 15, 2005, at 12:35 PM, Robert Sayre wrote: http://feedvalidator.org/check.cgi?url=http%3A%2F% 2Fwww.fondantfancies.com%2Fblog%2Fatom1%2F Hmm... the feed looks OK to me; I wouldn't be surprised if it's tickling a bug in the just-barely-into-beta Atom 1.0 feedvalidator code. -Tim

Re: The Atomic age

On Jul 15, 2005, at 8:56 AM, Walter Underwood wrote: --On July 14, 2005 11:37:05 PM -0700 Tim Bray <[EMAIL PROTECTED]> wrote: So, implementors... to work. Do we have a list of who is implementing it? That could be used in the "Deployment" section of <http://www

The Atomic age

Paul assures me that the remaining IETF process steps will not introduce material technical changes, and so format-10 is appropriate as a basis for implementors to go to work. So, implementors... to work. And everyone, now is a good time to tell the world. -Tim

Re: The Atom namespace, etc.

On Jul 14, 2005, at 12:58 PM, Paul Hoffman wrote: And, the two Security Area Directors have signed off on the Security Considerations section in -10. Which is to say, we need one more sign-off and a couple of bureaucratic buttons pushed, and Atom will be an IETF "proposed standard", an

Atom format progress

The Atom Format draft was considered by the IESG today, and there remain some outstanding DISCUSS issues, see: https://datatracker.ietf.org/public/pidtracker.cgi? command=print_ballot&ballot_id=1681&filename=draft-ietf-atompub-format https://datatracker.ietf.org/public/pidtracker.cgi? comm

Re: Major backtracking on canonicalization

On Jul 6, 2005, at 3:28 PM, Paul Hoffman wrote: Greetings again. I gravely misunderstood XML Canonicalization, and as it has been explained to me now, XML Canonicalization would be a disaster for Atom: what we want is Exclusive XML Canonicalization. Urgh, I should have caught this. Cor

Re: Roll-up of proposed changes to atompub-format section 5

On Jul 5, 2005, at 4:08 PM, Paul Hoffman wrote: Intermediaries such as aggregators may need to add an atom:source element to an entry that does not contain its own atom:source element. If such an entry was signed, the addition will break the signature. Thus, a publisher of individually-si

Re: Roll-up of proposed changes to atompub-format section 5

On Jul 5, 2005, at 1:05 PM, David Powell wrote: Will we still be fixing some of bugs raised since the last draft though? Definitely. A number of things have been pointed out as bugs, there's been no WG pushback on any of them, and since we were going to have to have a -10 draft anyhow fo

Re: Roll-up of proposed changes to atompub-format section 5

On Jul 5, 2005, at 12:50 PM, Walter Underwood wrote: I'm fine with the delay. Two or three weeks on top of 18 months is not a big deal. I am *not*. It's not "two or three weeks", it's "some uncontrollable time in the future" versus "now". We have spent way too long already. -Tim

Re: Roll-up of proposed changes to atompub-format section 5

On Jul 5, 2005, at 9:54 AM, Antone Roundy wrote: "When signing individual entries that do not contain an atom:source element, be aware that aggregators inserting an atom:source element will be unable to retain the signature. For this reason, publishers might consider including an atom:sour

Re: Roll-up of proposed changes to atompub-format section 5

On Jul 5, 2005, at 9:27 AM, James M Snell wrote: Huh?! Pardon my ignorance, could you please provide an explanation for the simple-minded as to how the absence of a source element in a signed entry will lead to signatures being discarded? Also, it would be helpful to sketch in some of

Re: Roll-up of proposed changes to atompub-format section 5

On Jul 5, 2005, at 8:58 AM, Bob Wyman wrote: We can debate what it means to have an "interoperability" issue, however, my personal feeling is that if systems are forced to break and discard signatures in order to perform usual and customary processing on entries that falls very close to

Re: Roll-up of proposed changes to atompub-format section 5

On Jul 4, 2005, at 7:38 PM, Bob Wyman wrote: I believe it would be very useful to specify that signed entries should include a source element. This can/should be considered part of entry canonicalization. -1. Leave it to the market. I suspect that you're right, but I'd be unsurp

Re: Clearing a "discuss" vote on the Atom format

On Jun 30, 2005, at 6:26 PM, Paul Hoffman wrote: Greetings again. Russ Housley, one of the two Security Area Directors, has placed a "discuss" vote on the Atom format document. You can read it at >. Fortun

Re: IESG defers discussion of the format document for two weeks

On Jun 23, 2005, at 9:12 AM, Eric Scheid wrote: If there are problems that require repair, I don't want to wait two more weeks to find out about them. This is very disappointing. -Tim we can start with these two...

Re: IESG defers discussion of the format document for two weeks

On Jun 23, 2005, at 7:18 AM, Paul Hoffman wrote: In other words, this isn't bad news, just a delay. Fully disagree. The world has many implementors eagerly awaiting the arrival of Atom so they can start using it. If there are problems that require repair, I don't want to wait two more

Re: Signature wording

On Jun 22, 2005, at 12:03 PM, James M Snell wrote: I'm planning to write a separate Internet-Draft that discusses digital signing of Atom feeds and entries. Some parts of that document will includes mandates; other parts will include recommendations. We can describe for entry producers a

  1   2   3   4   >