Fwd: [rt.icann.org #2905] Last Call: 'The Atom Syndication Format' to Proposed Standard
Unsurprising, but good news I'd say: From: "Michelle Cotton via RT" <[EMAIL PROTECTED]> Date: April 28, 2005 8:58:51 PM PDT To: iesg@ietf.org Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [rt.icann.org #2905] Last Call: 'The Atom Syndication Format' to Proposed Standard Reply-To: [EMAIL PROTECTED] IESG: The IANA has reviewed the following Internet-Draft which is in Last Call: , and has the following with regards to the publication of this document: Upon approval of this document the IANA will register the MIME media type application/atom+xml. A Registry of Link Relations will be created and will include the five initial values described in this document. Thank you. Michelle Cotton (on behalf of IANA)
ADMINSTRIVIA: resent mail and loops
There will probably be a couple of more re-sent messages before the current storm stops. I have nuked the user who seems to be behind a stupidly-written spam filter at fault. --Paul Hoffman, Director --Internet Mail Consortium
Re: PaceOptionalSummary
I'll +1 on MAY. On 27 Apr 2005, at 04:29, Robert Sayre wrote: On 4/26/05, Tim Bray <[EMAIL PROTECTED]> wrote: Paul & I are gonna watch a little more debate and then we'll call rough consensus one way or the other, at which point I at least will become crushingly rude to anyone who wants to invest more time in this. Yeah, so now Sam and Graham are off making up requirements to add to the spec. This is over and its a waste of the WG's time. Let me summarize: MUST: Sam SHOULD: Graham, Roger Eh: Bill MAY: Myself, James T, Antone, Eric, Julian, Martin, Aristotle Robert Sayre
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
The IESG wrote: The IESG has received a request from the Atom Publishing Format and Protocol WG to consider the following document: - 'The Atom Syndication Format ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-05-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt In general the document looks good to me. Some minor comments (and few questions), mostly nitpicking below: >3.1.1.1 Text > > Example atom:title with text content: > > ... > > Less: < > > ... > > If the value is "text", the content of the Text construct MUST NOT > contain child elements. Such text is intended to be presented to > humans in a readable fashion. Thus, Atom Processors MAY collapse > white-space (including line-breaks), Ok, maybe it is just me, but what does it mean to "collapse white-space"? Does this mean to replace FWS (in RFC 2822 sense) with a single space? > and display the text using > typographic techniques such as justification and proportional fonts. >4.1.3.3 Processing Model ... > 2. If the value of "type" is "html", the content of atom:content > MUST NOT contain child elements, and SHOULD be suitable for > handling as HTML [HTML]. The HTML markup must be escaped; for Should the "must" be changed to MUST here? > example, "" as "
". The HTML markup SHOULD be such > that it could validly appear directly within an HTML > element. Atom Processors that display the content MAY use the > markup to aid in displaying it. ... > 6. For all other values of "type", the content of atom:content MUST > be a valid Base64 encoding [RFC3548], which when decoded SHOULD I have to note that the RFC 3548 has 2 base64 alphabets: in section 3 and in section 4. You probably want the more common one in section 3, but this has to be stated explicitly. >6.3 Software Processing of Foreign Markup > ... > When unknown foreign markup is encountered in a Text Contruct or > atom:content element, software SHOULD ignore the markup and process > any text content of foreign elements as though the surrounding markup > were not present. I reread this paragraph few times and I am still not quite sure what the paragraph is trying to say. Is it trying to say "if the content of a foreign element looks like XML with unrecognized schema - just strip the markup and process the text"? Regards, Alexey
PaceBriefExample posted
I'm obviously very down on normative language requiring a summary. I
am open to non-normative language explaining the syndication medium as
we see it today. I acknowledge that people who don't know what they're
doing sometimes create unhappy users by providing title-only feeds.
The examples, especially the ones at the top, should cater to people
who don't know what they're doing. Please do not take this opportunity
argue about PaceOptionalSummary. Feel free to use it as ammunition in
one of the other threads, if you must.
Abstract
Change the description of the first example, if PaceOptionalSummary is accepted.
Status
Open
Rationale
Most readers glance at examples, but don't read the rest of the spec.
They should be steered towards the set of elements they probably want
to be using.
Proposal
Change the first line of section 1.2 from
{{{ A minimal, single-entry Atom Feed Document: }}}
to
{{{ A brief, single-entry Atom Feed Document: }}}
and keep the example as it is in format-08.
Re: Cleanup phase - remaining Paces
The following Paces have not had their fate officially decided: PaceOptionalSummary (+1) PaceXmlContentWrapper (+1 -- there was plenty of opposition during the discussion of this one, but it seemed to be directed at both the current spec and the Pace, so I don't think it's clear whether people prefer the current spec or the Pace) PaceCoConstraintsAreBad (written to draft 07 but I don't think the section to be changed changed since then) PaceFeedIdOrAlternate (withdrawn by the author, so perhaps it shouldn't be listed here--written to draft 07 but the line in question hasn't changed since at least 06) PaceFeedIdOrSelf (+1 -- just updated to draft 08 by changing a "6" to an "8") Would a Pace be required to change the name of atom:image to atom:logo or could that be considered editorial? "Logo" is much more descriptive of what it's for, and would reduce confusion if somebody creates an extension for non-logo images. I assume a Pace is coming for atom:id being repeatable within a document as long as the entries in question have different source feeds? (I'd give it a +1)
Re: PaceOptionalSummary
On 4/28/05, Roger B. <[EMAIL PROTECTED]> wrote: > > > That's fine, but we're not here to tailor the format to your app. > > Robert: Seriously, dude. C'mon. > You're right, that was too snippy. > But you asked a question, and I answered it. Honestly, > straightforwardly, and without an weasel-words. I did not ask anyone > to tailor anything to anything. Try that silly crap with others if you > must, but spare me. > Again, I support a SHOULD on summary. Not just adding an empty > element... allowing publishers to drop it entirely, as long as they're > aware they're doing something that will have an impact on the primary > functionality of feed-consuming applications. Your argument is mostly consistent. I'll try to explain why SHOULD will create problems that don't exist today. Let's take del.icio.us. Sometimes, their entries have descriptions. Sometimes, they don't. Your SHOULD allows competitors to turn off their feeds at any time, and point to the spec as justification. Even worse, it could be "oh, some of their entries are buggy, so we drop those." I doubt your intent is anything nearly that malicious, and you might be right that the feeds in question suck, but using a SHOULD to back up that action is exactly what we want to avoid. It might even be possible to write a naive parser that actually malfunctioned on such feeds. Basically, if what you say is true, we don't need to enforce a summary at all. It'll take care of itself, like email and even HTML eventually did (it's possible to create an entire page in Flash, but not particularly effective in the market). If these sorts of feeds are legitimate for a certain style of application, a SHOULD is bound to bring questions my way wondering "what does that SHOULD *really* mean?". If that were to happen, the only ethical thing to do would be to refer the question to Mark Nottingham. I've begun training an email filter to forward questions to him ;) That is not a problem worth creating in return for advocating the type of feed we think is cool right now. Robert Sayre
Re: Cleanup phase
Bill:
That last objection in parens sounds like some of the positions held
around dates - that providers ought to do the right thing for some
definition of the right thing. Given that legacy, I'll claim it's
clear we're not here to police what people ought do with feeds that
could have a summary.
Graham:
Then what are we here to do? Would you support removing all of the other
requirements from the spec?
> Sam:
> First, note that this is misstating Graham's position.
> He is not arguing that summaries be made non-optional.
I support discussing requirements that can be framed operationally and
which induce a benefit. This is why I keep coming back to title-only
feeds rather than concerning myself with enforcing some sort of policy
on what people think other people ought to do with summaries. Rationales
along the lines of "we object to feeds that could have a summary
included but don't", don't work for me, and I'll try to explain why
here. I also (and this is possibly unfair to Graham) think that when
counter-factual arguments are being presented against, then the argument
against the pace are running out of steam.
And if Robert's assertion elsewhere ("Every bit of syndication code
written since my.netscape.com in 1999 can deal with title-only feed")
is remotely true , ie there's not large number of codebases that will
break, then you can add innovation through standards to my list of
objections to any position that makes summaries non-optional.
Every code base can also cope without dates or ids. We still require them.
Yes, and there we agreed not to require enforcing publishers to update
on every change and have 3 date items to support that policy. Largely
because it can't be enforced and downstream clients will end up baking
bad assumptions into their tools.
My point here is probably worth elaborating on. I feel the same way
about the must-be including summaries because you should be including
summaries position, as I did about the must be updating dates because
you should be updating dates position, that they are usefully
enforceable. I also feel the same way about insisting on empty summary
elements if that is used to obtain a compromise. I'm well aware of
SHOULDs and optionals causing interop issues, however this must have
summary approach, like must update timestamps, is not the kind of
constraint that induces useful behaviour.
I've read and re-read the -1 positions to PaceOptionalSummary and I can
neither see the harm in optional summaries nor the benefit in always
having a summary. That is, operationally, I can't see what harm is
caused by allowing title-only feeds or what the benefit of disallowing
them is. But I can see the pointlessness, if not quite harm, of making
people populate a field they either don't need or don't want to
populate. I suspect that might induce junk data unneccesarily.
I believe I understand the -1 position, but I just haven't be swayed by
the arguments for it; that leaves me at +1.
cheers
Bill
Re: Cleanup phase
Sam Ruby wrote: This is not a theoretical discussion. Quoting from RSS 0.92[1]: * All sub-elements of are optional * any 0.92 source is also a valid 2.0 source Is this really where we want to go? No, but please see my other mail replying to Graham on why I think PaceOptionalSummary does not go there. cheers Bill
Re: PaceOptionalSummary
> That's fine, but we're not here to tailor the format to your app. Robert: Seriously, dude. C'mon. I don't care what little slap-fight you want to have with Sam, or Graham, or whoever else you figure is wronging the sublime rightness of your position. That's your thing, and welcome to it. You're not the first one to feel like "consensus" led Atom somewhere it had no business going. If you want to sit around and bitch about it, I'll might even join in. I was most unhappy with how things went in the XML-RPC vs. REST debate, for example. I've moved on, but I can at least sympathize. But you asked a question, and I answered it. Honestly, straightforwardly, and without an weasel-words. I did not ask anyone to tailor anything to anything. Try that silly crap with others if you must, but spare me. > I've > gotten feedback from embedded device developers complaining that XHTML > requires them to do more parsing than their app can handle, for little > practical benefit (for them). Note that we're also giving them the > short end of the stick with this requirement. If their embedded devices can't easily produce XHTML, then they don't have to do so. If their devices can't easily consume XHTML, they can either strip it or drop it. Again, the one thing Atom actually brings to the table over RSS is that content is clearly flagged. So where's the problem? (Or did someone slip something into 08 that says summaries must be XHTML?) > This is the assertion I have a problem with, and the opinions > expressed by others echo my gripe. Which part is the assertion that's causing you trouble? 'Cause half is in the charter, and the other half is one of those obvious things that Paul referenced. > Well, now we're just back to the sorts of feeds that are supposedly > perfectly ok on the condition that they contain an empty summary > element. Again, I support a SHOULD on summary. Not just adding an empty element... allowing publishers to drop it entirely, as long as they're aware they're doing something that will have an impact on the primary functionality of feed-consuming applications. Not that I think SHOULD is a good idea in this case. I just don't see the point in arguing about it incessantly, and SHOULD covers most of the bases. -- Roger Benningfield
Re: Cleanup phase
Graham wrote:
On 28 Apr 2005, at 11:34 am, Bill de hÓra wrote:
I haven't seen any objections to "title only feeds" which you state
is my and Sam's and other's position (we object to feeds that could
have a summary included but don't).
That last objection in parens sounds like some of the positions held
around dates - that providers ought to do the right thing for some
definition of the right thing. Given that legacy, I'll claim it's
clear we're not here to police what people ought do with feeds that
could have a summary.
Then what are we here to do? Would you support removing all of the other
requirements from the spec?
And if Robert's assertion elsewhere ("Every bit of syndication code
written since my.netscape.com in 1999 can deal with title-only feed")
is remotely true , ie there's not large number of codebases that will
break, then you can add innovation through standards to my list of
objections to any position that makes summaries non-optional.
First, note that this is mistating Graham's position. He is not arguing
that summaries be made non-optional.
Every code base can also cope without dates or ids. We still require them.
This is not a theoretical discussion. Quoting from RSS 0.92[1]:
* All sub-elements of are optional
* any 0.92 source is also a valid 2.0 source
Is this really where we want to go?
- Sam Ruby
[1] http://backend.userland.com/rss092
Re: PaceOptionalSummary
> Sorry, what was your point again? Eric: The point was that the *application* drops title- or content-free entries. It never inserts them into the database. They go poof. -- Roger Benningfield
Re: Cleanup phase
On 28 Apr 2005, at 11:34 am, Bill de hÓra wrote:
I haven't seen any objections to "title only feeds" which you state
is my and Sam's and other's position (we object to feeds that could
have a summary included but don't).
That last objection in parens sounds like some of the positions held
around dates - that providers ought to do the right thing for some
definition of the right thing. Given that legacy, I'll claim it's
clear we're not here to police what people ought do with feeds that
could have a summary.
Then what are we here to do? Would you support removing all of the
other requirements from the spec?
And if Robert's assertion elsewhere ("Every bit of syndication code
written since my.netscape.com in 1999 can deal with title-only feed")
is remotely true , ie there's not large number of codebases that will
break, then you can add innovation through standards to my list of
objections to any position that makes summaries non-optional.
Every code base can also cope without dates or ids. We still require
them.
Graham Parks
Re: Cleanup phase
Graham wrote:
On 28 Apr 2005, at 10:48 am, Bill de hÓra wrote:
Tim Bray wrote:
And of course we're going to have to fish some sort of consensus out
of this horrid summary-required mess. -Tim
I can't agree with that observation. Although there are a few
strenuous objections against title only feeds, on the balance
consensus is for them. Is there something you're seeing that should
make us think the current consensus level is inadequate?
Exactly because the two sides don't understand each other.
I believe I understand the positions quite well. But maybe you can
convince me otherwise.
I haven't
seen any objections to "title only feeds" which you state is my and
Sam's and other's position (we object to feeds that could have a summary
included but don't).
That last objection in parens sounds like some of the positions held
around dates - that providers ought to do the right thing for some
definition of the right thing. Given that legacy, I'll claim it's clear
we're not here to police what people ought do with feeds that could have
a summary. The single argument along those lines that was sensible was
to accessibility, which was eventually dispensed with.
And if Robert's assertion elsewhere ("Every bit of syndication code
written since my.netscape.com in 1999 can deal with title-only feed") is
remotely true , ie there's not large number of codebases that will
break, then you can add innovation through standards to my list of
objections to any position that makes summaries non-optional.
Similarly, it's not clear whether people on your
side would equally support an alternate proposal to the current Pace.
Any number of such counter-factual arguments can be made (after all
that's largely the point of introducing them). They won't convince me,
nor are they a basis for getting our work done.
cheers
Bill
Re: Cleanup phase
On 28 Apr 2005, at 10:48 am, Bill de hÓra wrote: Tim Bray wrote: And of course we're going to have to fish some sort of consensus out of this horrid summary-required mess. -Tim I can't agree with that observation. Although there are a few strenuous objections against title only feeds, on the balance consensus is for them. Is there something you're seeing that should make us think the current consensus level is inadequate? Exactly because the two sides don't understand each other. I haven't seen any objections to "title only feeds" which you state is my and Sam's and other's position (we object to feeds that could have a summary included but don't). Similarly, it's not clear whether people on your side would equally support an alternate proposal to the current Pace. Graham
Re: Cleanup phase
Tim Bray wrote: And of course we're going to have to fish some sort of consensus out of this horrid summary-required mess. -Tim I can't agree with that observation. Although there are a few strenuous objections against title only feeds, on the balance consensus is for them. Is there something you're seeing that should make us think the current consensus level is inadequate? cheers Bill
Re: On SHOULD, MUST, and semantics
Graham wrote: On 27 Apr 2005, at 10:31 pm, Robert Sayre wrote: My opinion is that ~10 WG members are currently clearly stating their belief that summary/content are optional. You should make clear that most of those people supported a misleading Pace that didn't clearly state its side-effects beyond making feeds-where-no-title-is-available legal. Whether or not they support the general position that "summary/content are optional" is not for you to make. But yet you can make the judgement that people supported a misleading pace. This does not seem to be a reasonable or useful argument to make. cheers Bill
Re: PaceOptionalSummary
Bill de hÓra wrote: Tim Bray wrote: http://www.intertwingly.net/wiki/pie/PaceOptionalSummary 0 I think I'm the only 0 in this. After watching the debate progress over the last few days, I'm altering my position to +1. cheers Bill
Re: PaceOptionalSummary
On 4/28/05, Sam Ruby <[EMAIL PROTECTED]> wrote: > Robert: why did you ask for an example? > To find out about any technical issues, not to hear Roger repeat himself. Robert Sayre
Re: Cleanup phase
On 4/28/05, Tim Bray <[EMAIL PROTECTED]> wrote: > And of course we're going to have to fish some > sort of consensus out of this horrid summary-required mess. That shouldn't be hard. I don't think the WG has ever been more decisive. If PaceOptionalSummary received 10 negative opinions, I'm quite sure the chairs would characterize it as "drowning in -1s". Are we "drowning in +1s" yet? Every bit of syndication code written since my.netscape.com in 1999 can deal with title-only feeds. There's your running code. The IETF process is designed get work done when a vocal minority of WG members makes a lot of noise about a given issue. In this case, the WG has let the minority present a series of arguments, and some of the arguments contradict previous ones. I think perhaps we've hit bottom. I'm pretty sure Graham just wrote that I couldn't use the 7-line PaceOptionalSummary, which made summaries and content optional by striking one line from the spec, to assert that the WG wanted to make summaries optional. This is so over, I can't believe it. I cannot believe we are entertaining this tripe. Robert Sayre
Re: PaceOptionalSummary
Robert Sayre wrote: On 4/28/05, Roger B. <[EMAIL PROTECTED]> wrote: Do you have an example? Robert: I'm an example. I also drop title-free feeds (see Scripting News)... given the nature of the app, a feed without titles or content is just worthless. That's fine, but we're not here to tailor the format to your app. Robert: why did you ask for an example? - Sam Ruby
Re: PaceOptionalSummary
On 28/4/05 2:45 PM, "Roger B." <[EMAIL PROTECTED]> wrote: >> Do you have an example? > > Robert: I'm an example. I also drop title-free feeds (see Scripting > News)... given the nature of the app, a feed without titles or content > is just worthless. I'm also an example - if I discover that a feed I once loved for it's tech content is now given over to endless cat pictures, or discussion of politics, then I too will drop that feed post haste. Even if it does have a summary. Sorry, what was your point again? e.
Cleanup phase
On Apr 27, 2005, at 9:05 AM, Sam Ruby wrote (about the proposal to address Bob Wyman's dupes issue): It would help if a Pace could be written. Funny you should say that, Sam. We have another week or so to go on our IETF Last Call, but the volume of input is low enough that Paul & I think we can safely start doing our own internal-issues final cleanup. We've been following the WG discourse as best I can, but the volume is high. Thus, we think that to be fair and transparent, we require a last round of Paces for any/all changes to the format-08 draft. Sam, perhaps you could have a scan at the current set of Paces and see if any other than PaceOptionalSummary are actually up-to-date and suitable for this last round? (I'd be surprised, but you never know). I think there are quite a few little things for which I've seen evidence of consensus on the mailing list, in fact I think Rob/Mark have pounced on a couple and they're in -08; but if you're behind one and it isn't, please Pace-i-fy it and let's get with the cleanup. LAST CHANCE, we mean it. And of course we're going to have to fish some sort of consensus out of this horrid summary-required mess. -Tim
