Re: Atom Bidi Draft Update - Informal Last Call

Yeah, I know, but I personally have a preference towards having more implementations available... especially since we're talking about a draft that updates the core Atom spec with a new attribute. - James Martin Duerst wrote: > At 02:25 07/03/23, James M Snell wrote: >> It is not

Re: Atom Bidi Draft Update - Informal Last Call

t;Draft" stage and issue a call for implementations? The > future of the draft should be based on the implementation reports received. > > Franklin > > - Original Message - > From: "Martin Duerst" <[EMAIL PROTECTED]> > To: "James M Snell&qu

Re: Atom Bidi Draft Update - Informal Last Call

t, but not a Proposed Standard? > > Franklin Tse > > - Original Message - > From: "James M Snell" <[EMAIL PROTECTED]> > To: "atom-syntax" ; "atom-protocol" <[EMAIL PROTECTED]> > Sent: Friday, March 23, 2007 00:59 > Subje

Atom Bidi Draft Update - Informal Last Call

I have posted an updated version of the Atom Bidi Draft. The only significant difference is a notice about direction guess algorithms. http://www.ietf.org/internet-drafts/draft-snell-atompub-bidi-03.txt I have implemented support for this specification in Abdera and in IBM's updated internal

Re: Autodiscovery Draft

John Panzer wrote: > [snip] > Also, is there a standard way to discover the collection associated with > a feed? (Given that, if there is an IETF or WHAT-WG way to discover > feeds, there's an obvious way to discover collections... but I'm not > clear on what that would be. I do think that col

Re: Autodiscovery Draft

On 19.03.2007, at 20:50, James M Snell wrote: > >> >> I'm assuming that since there was no additional expressed interest in >> moving forward with the Atom autodiscovery draft that it's not going to >> go anywhere. My current intention is to go ahead

Autodiscovery Draft

I'm assuming that since there was no additional expressed interest in moving forward with the Atom autodiscovery draft that it's not going to go anywhere. My current intention is to go ahead and let it expire again without any further modifications. - James

Re: Representing bookmarks

For Lotus Connections we're representing bookmarks as ... ... ... ... ... This works for everything we need. - James Brendan Taylor wrote: > I'd like to represent bookmarks using Atom, so that I can manipulate > them using the Publishing Protocol. > > I discussed this br

Re: Current and permalink link rel values

Last I had checked (last spring) it was a mess. Some readers picked the first alternate link in the document; some readers picked the last alternate link in the document; some readers picked the first link in the document regardless of it's rel value; some readers picked the last link in the docu

Re: Current and permalink link rel values

+1. Antone Roundy wrote: > [snip] > So you couldn't keep both as "alternate" links. In my opinion, you > should use the second one (the longer lasting one) only, and omit the > first (which is going to become invalid as soon as the entry falls off > the page anyway -- anyone who used it to get t

IBM IPR Disclosure

All, As a general FYI, IBM just filed a blanket IPR disclosure [1] relating to the activity of the Atompub WG. Before any misinformation starts going around about this I thought it would be a good idea to give y'all a heads up. As of right now IBM has NO KNOWN patents or applications for patent

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

I was going to say ship it but I noticed one major problem: the app:categories element is defined twice: once in section 7 and again in 8.2.5. I realize that these are different contexts (e.g. categories as a standalone doc vs. an element in the service doc) but it's entirely unnecessary to define

Re: Query re: support of Media RSS extensions inside Atom feeds

I'd be all for it assuming it didn't go off in the weeds. - James Ernest Prabhakar wrote: > >> On Feb 9, 2007, at 9:23 PM, John Panzer wrote: >>> Does anyone know of any issues with placing Yahoo! Media RSS >>> extensions (which seem to fit the requirments for Atom extensions to >>> me) inside

Re: Query re: support of Media RSS extensions inside Atom feeds

That's a big assumption. The only reason I added it to Abdera was to prove a point about being able to support RSS extensions in Atom. I haven't come across any implementation that makes use of the extensions. - James James Holderness wrote: > [snip] > That said, I know there are feed librarie

Re: Query re: support of Media RSS extensions inside Atom feeds

I'm not sure if there are any feed readers that support MRSS in Atom but I don't see any reason why it wouldn't work. A while back I implemented minimal support for the MRSS extensions in Abdera with very little difficulty. - James John Panzer wrote: > Does anyone know of any issues with placin

Re: Best practice for linking to child feeds

RFC 4685 - http://www.ietf.org/rfc/rfc4685.txt - James Becker, Matthew R wrote: > Given a feed of discussion board topics, how do you show that an Atom > entry representing a topic has a related child feed representing the > posts for that topic? I was looking at the rel attribute of the link >

Re: Quoting type parameter value allowed? - Was: I-D ACTION:draft-ietf-atompub-typeparam-00.txt

+1. The way I read it the quotes do not matter. - James Bob Wyman wrote: > On 1/19/07, *Andreas Sewe* <[EMAIL PROTECTED] > > wrote: >> So, it looks like that quoting the type parameter's values is no >> longer allowed; > Are the quotes part of the parameter value? Or, a

Re: Inheritance of license grants by entries in a feed

In the current draft, license links *are* inherited. Thomas Roessler wrote: > On 2007-01-14 20:04:12 +, David Powell wrote: > > [snip] > Be that as it may -- the atom:rights element *is* inherited, and I'd > expect some major confusion if a atom:license element wasn't. >

Atom license extension - final stages

All, The Atom license extension is continuing to move forward. Based on some last call comments that were received, I have decided to add two additional items to the spec: 1. An equivalence rule for license URIs 2. A IANA registry for common license URIs Over the next week I'll be working u

Re: I-D ACTION:draft-ietf-atompub-typeparam-00.txt

+1 Andreas Sewe wrote: > > Sylvain Hellegouarch wrote: >> Hugh Winkler wrote: >>> The draft makes no mention of file extensions. >>> >>> Server software responsible for inserting correct Content-type header >>> can *possibly* set the correct value when serving a file, if the >>> type="entry" and

Re: Type parameter implementation

I've added very preliminary support for it to Abdera. Nothing major, just a bit that detects the root node and outputs the media type according and a bit that checks to see if the media type specifically identifies an entry. Once we're a bit further down the path towards finalizing the spec, I'l

Re: Fwd: Atom format interpretation question

Ahhh... a slight ambiguity presents itself. The treatment of text/ types in RFC 4287 is a bit underspecified. I've always worked off the assumption that text/* types do not require base64 encoding (that's what Abdera expects). - James James Holderness wrote: > > Sam Ruby w

Atom Bidi Attribute - *Unofficial* Last Call

The Atom Bidi Attribute specification [1] updates RFC 4287 by adding a new 'dir' attribute to the set of atomCommonAttributes. The purpose is to provide a means of defining the base directionality of direction-neutral characters in Language-Sensitive text. The rationale is that direction-guessin

Re: Fwd: Atom format interpretation question

If it's well-formed XML then I'd think dropping it into atom:content using type="application/xml" would be acceptable. You'd just end up losing that bit of semantic metadata that tells you exactly what kind of XML it is. If you want to use the text/vnd.IPTC.NewsML media type to identify the type

Re: I-D ACTION:draft-ietf-atompub-typeparam-00.txt

Hey Bob, I have no problem with the rewording. Just waiting to see what others may have to say about it. - James Bob Wyman wrote: > > This document looks good on an initial quick read -- with one possible > exception. It says: > >> Atom processors that do recognize the parameter SHOULD >> det

Re: Additional 'namespace' attribute on content element?

Jan Algermissen wrote: > Hi, > > on the NewsML list, an issue came up that due to they lack of a MIME type > for NewsML using NewsML as Atom content is somewhat problematic[1]; I think > this is the case with most of the more interesting XML applications out there. > > Is there any chance to

Re: within HTML content

-1. If there's anything we can learn from the mess that is RSS, at a certain point feed consumers should be allowed to say simply that a buggy feed is a buggy feed and that it falls on the responsibility of the feed publisher to get things right. - James James Holderness wrote: > [snip] > Do you

Re: Atom Entry docs

Ok, so we've had more than just a few people put up their hands and say "what Bob said". This week I'll go ahead write up an initial draft of this using the type param option while we wait for the co-chairs to do their hasty consensus grab :-) - James Tim Bray wrote: > [snip] > In case you have

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

Quite frankly it doesn't matter what we call anything right now. The server gets to determine what pieces of data it's willing to handle. Period. If you want anything more than that, use webdav. - James Eric Scheid wrote: > On 17/12/06 1:13 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote: > >> *

Re: License Draft: Tortured text re obligations...

+1. Another good edit. I've started working on draft 11 with these edits. - James Bob Wyman wrote: > There is, I think a bit of tortured text in James Snell's otherwise > useful License ID[1]. > > 1.3. Terminology > ... > The term "license" refers to a potentially machine-readable

Re: Inheritance of license grants by entries in a feed

Bob, As always, thanks for the feedback. These are excellent suggestions. I'll work them into the next draft. - James Bob Wyman wrote: > In general, I think the latest version of James Snell's license ID [1] > is much better than earlier versions. I am particularly pleased that > this draft on

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

The moral of the story is simple: clients need to know what they're getting into. 1. Servers can accept or reject whatever they want. 2. it's really nice if servers let client's know up front what they intend to accept or reject 3. at this point there's no need for any kind of handshake protoc

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

Tim Bray wrote: > [snip] > We think that APP as specified allows very good interoperability for > basic Web-centric publish/edit operations with low overhead, and low > demands for complexity in the client and sever implementations. Adding > the requirement for client-side extensibility would

Re: Atom Entry Documents

+1 many times over. Lisa Dusseault wrote: > I don't feel that changing parts of RFC4287 is appropriate for an > individual draft, particularly when the WG that did RFC4287 exists. > Certainly in order to update RFC4287 it would *have* to be Proposed > Standard. What constitutes an update or cha

Re: Atom Entry Documents

Quite a few folks seemed to have a preference to a separate doc. - James Asbjørn Ulsberg wrote: > On Tue, 12 Dec 2006 08:39:25 +0100, James M Snell <[EMAIL PROTECTED]> > wrote: > >> Ideally, I would much rather this be a WG draft. I pinged Tim about it >> the other

Re: Atom Entry docs

I've found the arguments in favor of the type param to be more convincing than those in favor of the new media type... ...so +1 to what Bob said. - James Tim Bray wrote: > > Bob Wyman wrote: >> There is, I think, a compromise position here which will avoid >> breaking those existing implementa

Re: Atom Entry docs

Sylvain Hellegouarch wrote: >> [snip] >> The GData server implementation requires a Content-Type value of >> "application/atom+xml" when POSTing or PUTting an Atom entry to a >> collection >> (for all non-media collections). It will respond with a 400 (Bad Request) >> http error on any other c

Re: Atom Entry docs

Very helpful. Thank you. - James Martin Duerst wrote: > At 13:14 06/12/13, James M Snell wrote: >> I think atom.entry and atom-entry are equally ugly; atom.entry would, >> however, appear to be more consistent with typical mime conventions. > > The dot is used for prefi

Re: Atom Entry docs

I think atom.entry and atom-entry are equally ugly; atom.entry would, however, appear to be more consistent with typical mime conventions. - James Tim Bray wrote: > > [snip] > (James, did you really mean "atom.entry" with the ugly dot?) > > -Tim > >

Re: Atom Entry Documents

t; 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/ > >

Re: Atom Entry Documents

Sure you can. Adding this to mime.types... application/atom+xmlatom application/atom+xml;type=entry entry application/atom+xml;type=feed feed works just fine in apache2. Ask for a static file *.atom, and you get application/ato

Re: Atom Entry Documents

Mark Baker wrote: > On 12/10/06, James M Snell <[EMAIL PROTECTED]> 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? &g

Re: Fwd: PaceEntryMediatype

Bob Wyman wrote: >[snip] > What you seem to be implying is that the majority of applications > that process Atom Feed documents are not, in fact, supporting extremely > important parts of the atom specification. I believe that any properly >[snip] Not quite. What I'm implying is that not a

Re: Fwd: PaceEntryMediatype

I'm fine with the type parameter approach so long as it is effective. By effective I mean: Will existing implementations actually take the time to update their behavior to properly handle the optional type parameter. - James Bob Wyman wrote: >[snip] > James suggests: "the type parameter is

Re: PaceEntryMediatype

Content types are only useful when they help to differentiate how a document is to processed. If it was all about the format we could have just used application/xml all along. IMHO, There is already sufficient evidence that entry documents and feed documents are processed differently and thus de

Atom Bidi Update

FYI, I've posted an update to the proposed Atom bidi spec. http://www.ietf.org/internet-drafts/draft-snell-atompub-bidi-02.txt Refresher: this adds a dir attribute to Atom Common Attributes that is used to specify the base direction of text in Atom documents. Changes: this draft has two sign

Re: feeds: what does atom:id denote?

Depends... is the client expected to process each discreet set of entries as part of a single logical set or is each discreet set expected to be processed as it's own complete set? The former would be equivalent to the way most feed readers work today. The latter would be equivalent to subscribi

Re: PaceEntryMediatype

I certainly hope you're kidding about dropping entry docs. Let's just label 'em differently and move on. - James Jan Algermissen wrote: > > On Dec 6, 2006, at 11:30 PM, James M Snell wrote: > >> >> >> Jan Algermissen wrote: >>> [snip] >

Re: PaceEntryMediatype

Jan Algermissen wrote: > [snip] > So they should be fixed, should they not? They seem to only have > implemented half a media type. > The half they're interested in. Why aren't they interested in the other half? - James

Re: PaceEntryMediatype

Andreas Sewe wrote: > [snip] > Applications which adhere to RFC 4287 and accept both Feed and Entry > Documents labeled as "application/atom+xml" won't recognize > "application/atomentry+xml"; they will have to be updated. > In consider that a feature. - James

Re: PaceEntryMediatype

ately. - James Andreas Sewe wrote: > James M Snell wrote: >> Actually, for the form "application/atom+xml;type=entry" it's more >> likely that browsers will completely ignore the type param as they do >> currently. > > Well, if a browser ignores a medi

Re: PaceEntryMediatype

Actually, for the form "application/atom+xml;type=entry" it's more likely that browsers will completely ignore the type param as they do currently. - James fantasai wrote: > [snip] > That means rel="feed" won't be implied on an Atom Entry document whether > the > new MIME type syntax is chosen t

Re: PaceEntryMediatype

Eric Scheid wrote: > [snip] > If an agent found an entry document, should it assume that it's a feed with > one entry (so far) and allocate resources accordingly (ie. allow for > cardinality of n++)? > No. In particular, if an atom:source element is not included there is no way of knowing anyth

Re: PaceEntryMediatype

Mark Baker wrote: > [snip] > Isn't that just a case of people not implementing the whole spec > though? FWIW, if that practice is widespread, then I think the group > should consider deprecating entry documents. Minting a new media type > won't help. > The interesting question is *why* haven

Re: PaceEntryMediatype

Mark Baker wrote: > [snip] > Ok, but I don't see that this would necessitate a new media type. > It's just an entry without a feed. You'd use the same code path to > process that entry whether it were found in an entry or feed document, > right? > Not necessarily. Sure, it might be the same

Re: PaceEntryMediatype

Indeed. The application was written to expect a feed because of the content-type but gets an entry instead and blows up. - James Jan Algermissen wrote: > > On Dec 5, 2006, at 9:15 PM, James M Snell wrote: > >> >> When I process this entry, >> >> http://www.

Re: PaceEntryMediatype

a logical feed is implied but absent any other evidence, this is a standalone entry document that can be processed without any assumption that a feed exists. - James Mark Baker wrote: > On 12/4/06, James M Snell <[EMAIL PROTECTED]> wrote: >> All I can go on is evidence of how fol

Re: PaceEntryMediatype

as, and acts like an alias ... 8-) > > Mark. > > On 12/4/06, James M Snell <[EMAIL PROTECTED]> wrote: >> And therein lies the problem: entry documents are NOT aliases for >> single-entry feeds. >> >> - James >> >> Mark Baker wrote: >> > [snip] &g

Re: PaceEntryMediatype

And therein lies the problem: entry documents are NOT aliases for single-entry feeds. - James Mark Baker wrote: > [snip] > True, but if entry documents are more or less aliases for single-entry > feeds, why would anybody need to negotiate for one or the other? I > suggest that would have to be

Re: PaceEntryMediatype

Jan Algermissen wrote: > [snip] > Is there any other media type that covers more than one document type > (root element in the case of XML, but could also be non-XML mime types)? > application/xml > It would be interesting to see how those (if any) deal with the issue. > An example would mayb

Re: PaceEntryMediatype

I could but after the discussions this week I'm not sure its worth it. Yes, everything can be done using different rel values; the content-type thing is more just an annoyance than anything else. I'll just make sure that I never link my Atom entry documents using "alternate" (even tho that's what

Re: PaceEntryMediatype

You're right that the differentiation in the content-type is of less importance but without it there's no way for me to unambiguously indicate that a resource has both an Atom Feed representation and an Atom Entry representation. The best I could do is say "This things has two Atom representation

Re: PaceEntryMediatype

Kyle Marvin wrote: > [snip] > I expect that if you associated a 'rel' value with links that point to > "application/atom+xml", whether it is expected to be a feed or an entry > would probably be part of the 'rel' description and thus not ambiguous > at all. I think the discussion started becaus

Re: [rss-public] Autodiscovery IPR and Process Concerns

The AD was kind enough to point out that this statement is likely a bit too vague. The intended meaning was that I have no involvement in, or awareness of, IPR that is in any way relevant to the atom work. And, as far as I am aware, there's nothing I am required to disclose. - James Ja

Re: PaceEntryMediatype

Excellent summarization Antone, thank you. Antone Roundy wrote: > [snip] > ? I haven't been following development of the APP, so forgive my > ignorance, but can parameters be included in the accept element? > I'd have to double check the definition of "media-range" but the original intent was t

Re: PaceEntryMediatype

Bill de hOra wrote: > > "Well it's all octets so in one sense the processing is the same." > [snip] Btw, My apologies if my original comment about the xml parsing came across as being snarky; that was not the intention. The point I was making was that how these things are "processed" depends

Re: PaceEntryMediatype

Mark Baker wrote: > [snip] > If HTML 5 (and current practice) doesn't change, but we defer to them > for the specification of autodiscovery, then a new media type would be > one way forward. But it should be reusable for all non-"feed" (i.e. > from a user POV, as above) Atom documents, not just

Re: PaceEntryMediatype

Jan Algermissen wrote: > [snip] > Are there other problems you had in mind when writing the Pace? > Well, there are the issues that came up with regards to the APP accept element; the issues regarding whether Atom Feeds can be posted to an APP collection; the issue in the "collection of collect

Re: PaceEntryMediatype

The key problem with "application/atom+xml;type=entry" is that at least one major browser (Firefox 2.0) still treats it as a feed and shows the "subscribe" link. So while the type parameter is a potentially more elegant solution, the new media type approach would likely be far less disruptive. -

Re: PaceEntryMediatype

es > of documents are interpreted. > > How does your processing of an entry document differ from the > processing of a feed containing (only) that same entry? If processing > the entry is a subset of processing the feed, then you probably don't > need a new media type. >

Re: PaceEntryMediatype

John Panzer wrote: > [snip] > +1 to doing this outside of APP (but concerned about deprecating...) > [snip] An I-D / RFC can update another RFC without deprecating the entire thing. In this case the hypothetical new document would deprecate only the use of the application/atom+xml media type f

Re: PaceEntryMediatype

Mark Baker wrote: > [snip] > Yes, but more than that. An entry document is, AFAICT, little more > than shorthand for a feed with one entry, minus the feed-specific > metadata. It's processing is a subset of feed processing. If the > processing or content model of entry is extended, it applies

Re: [rss-public] Autodiscovery IPR and Process Concerns

Robert Sayre wrote: > [snip] > 1.) IP Protections > > This is interesting for a couple of reasons. One is that Mr. Snell > previously claimed that the document has "nothing to do with my day > job" [1]. The second is the complete absurdity of worrying about IP > protections on HTML tags that mak

Re: PaceEntryMediatype

I'm fine either way. Wouldn't take that long for me to write up a draft. - James Tim Bray wrote: > On Nov 29, 2006, at 8:16 AM, James M Snell wrote: > >> http://www.intertwingly.net/wiki/pie/PaceEntryMediatype >> >> #pragma section-numbers off >> >

Re: PaceEntryMediatype

One such problem occurs in atom:link and atom:content elements. Specifically: Given no other information I have no way of knowing whether these are references to Feed or Entry documents. - James Mark Baker wrote: > -1 > > - there's nothing special about an entry document > - AFAICT (bec

PaceEntryMediatype

http://www.intertwingly.net/wiki/pie/PaceEntryMediatype #pragma section-numbers off == Abstract == For the current Atom Publishing Protocol draft... Create a new media type for Atom Entry Documents: application/atomentry+xml Deprecate the use of application/atom+xml for Entry Documents. ==

Re: [whatwg] Alternate link clarifications [was Re: PaceAutoDiscoveryDraftIsPointless]

Ian Hickson wrote: > [snip] > Here, while the last three are also valid feeds, it is the first one that > should be considered the default when doing auto-discovery. This isn't to > say that the feed UA should ignore the other three, or that it should only > show them if the user goes out of

Alternate link clarifications [was Re: [whatwg] PaceAutoDiscoveryDraftIsPointless]

Ian Hickson wrote: >> [snip] >> 1. Is the order of alternate link rels in a document significant? > > Good question. The draft hadn't covered that. I've now fixed the spec to > say that the order is important in one respect: the first , , or > element whose rel="" attribute has the keyword

Re: PaceAutoDiscoveryDraftIsPointless

Hello, Over on the IETF Atom Syntax mailing list we're discussing whether or not to pursue the autodiscovery draft that had previously been put on the table [1] or to simply point to the HTML5 work and be done with it. While reviewing the HTML5 draft and comparing that to the Atom auto-discovery

WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)

The problem I have with the WHAT-WG definition of the alternate and feed relations is the unintended conflict that occurs when the alternate representation of a page happens to be an Atom Entry Document. The HTML5 draft says, "If the alternate keyword is used with the type attribute set

Re: PaceAutoDiscoveryDraftIsPointless

Ted, Please correct me if I get any of this incorrect, but for the sake of the discussion I wanted to summarize the HTML5 [1][2] definitions here: The following three links are equivalent to one another and specify that the linked feed is an alternate representation of the page. This mea

Re: PaceMakeAutodiscoveryInformational

Ok, so given that I think this is the fifth or sixth note in which you've said exactly the same thing, I think your position has been well established. What would be excellent is if you'd give others the opportunity to weigh in on it before trying so hard to filibuster it. - James Robert Sayre

Re: PaceAutoDiscoveryDraftIsPointless

Heh.. I probably should not have been taking a drink when I read this last sentence :-). You do know that we're talking about the *syndication community* right? - James Edward O'Connor wrote: > [snip] ... feed autodiscovery in a way that makes everybody happy. > > > Ted >

PaceRecommendFullURIsForAutodiscovery

http://www.intertwingly.net/wiki/pie/PaceRecommendFullURIsForAutodiscovery Definite -1 on this one. Buggy implementations just need to be fixed. Writing specs to bugs is silly at best. - James

Re: PaceAutoDiscoveryDraftIsPointless

+0. I have no particular agenda on this other than helping to move it forward if that's what folks want. I will note, however, that the overall response to PaceResurrectAutodiscovery was positive and there seemed (to me at least) to be interest in at least discussing the future of the draft. So p

Re: PaceMakeAutodiscoveryInformational

y has been noted. Thanks for the input. - James Robert Sayre wrote: > James M Snell wrote: >> I didn't write the doc so please don't complain to me about what's in >> there. If there is something that needs to be changed write up a pace. >> > > Uh,

Re: PaceMakeAutodiscoveryInformational

Robert Sayre wrote: >> [snip] >> To document best practice as it relates specifically to syndication >> feeds. > > The draft makes several requirements. That's not documenting best > practice. > [snip] If the doc is changed to informative, the normative requirements in the draft would need to be

Re: PaceMakeAutodiscoveryInformational

Lachlan Hunt wrote: >[snip] >> Move Autodiscovery forward as an Informational RFC > > But if it were published as an informational RFC, what purpose would it > serve? > To document best practice as it relates specifically to syndication feeds. For example, HTML5 says nothing about whether th

Restrict Rel and Type Values For Autodiscovery

http://www.intertwingly.net/wiki/pie/PaceRestrictRelValuesForAutodiscovery http://www.intertwingly.net/wiki/pie/PaceRestrictTypeValuesForAutodiscovery While I definitely understand the rationale behind this, it's unlikely that the spec will actually lead to any change in behavior for the various

PaceMakeAutodiscoveryInformational

http://www.intertwingly.net/wiki/pie/PaceMakeAutodiscoveryInformational #pragma section-numbers off == Abstract == Move Autodiscovery forward as an Informational RFC == Status == Proposed == Rationale == At this point there seems to be very little reason for the autodiscovery draft to be on

Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]

Rogers, Thanks for taking a look. Some comments. Rogers Cadenhead wrote: > [snip] > Our original spec said that it could be used with RSS > 1.0, RSS 2.0 and Atom, but the Atom guidance was > removed to get out of your way as your spec is being > drafted. > After going through and reviewing the

Re: Author element best practice

I personally just think it's way too early for us to really be able to say much about it. So far the APP implementations that have actually been deployed seem to work rather consistently in that I can get a single client (e.g. Abdera) to work with each with very little effort and only minor varia

Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]

Robert Sayre wrote: >>[snip] >> I dunno... you're the one that that writes browser code, you tell me. >> > I don't think it's a problem worth solving, absent any evidence to the > contrary. Mozilla doesn't seem to get many bug reports on this matter. > >> You certainly seemed to think it was

Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]

Robert Sayre wrote: > James M Snell wrote: >> The process for moving forward on this spec will be the same as with >> Atom and APP. > > No, it won't. It's not a WG document. > Ok, to be absolutely pedantic about it: the process will be as close as possible

Re: feed id's and paged/archive feeds

Abdera has basic support for the extension elements and the paging links (including prev-archive and next-archive). It does not yet include an implementation of the feed reconstruction algorithm but will shortly. The implementation is part of the optional extensions module. - James Mark Notting

Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]

Because I resubmitted the draft with no changes from its previous version. I intend to update references with the next iteration of the draft. - James Tse Shing Chi (Franklin/Whale) wrote: > Why is one of the normative references in draft > "draft-ietf-atompub-format-11" instead of "RFC4287"?

[Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]

All: With Phil Rignalda's permission, I have taken over the role of editor for the Autodiscovery draft and at Lisa and Paul's suggestion I have resubmitted the draft as an **individual** submission (as opposed to a Working Group Draft). Phil has requested that his name be removed from the draft.

Re: autodiscovery draft vs namespaces

Kornel, thanks for the input. In the next rev of the draft (following the initial reboot that should publish in a day or so) I'll see what I can do to clarifying some of these issues. As always, suggested spec text is helpful and encouraged. I will do my best to incorporate all editorial changes

Re: Author element best practice

-1. The current spec is fine as is. It currently does not say anything about whether or not the post entry MUST be valid although that is, indeed the spirit of the spec. The spec does not say that servers MUST reject entries that are not valid. Servers are free to accept or reject entries as th

Re: feed id's and paged/archive feeds

Mark Nottingham wrote: > [snip] > I think they do, although the draft is silent on it. > [snip] Good enough for me. Also, the latest draft looks good to me. Ship it! Thanks Mark. - James

  1   2   3   4   5   6   7   >