Re: For review: application/atom+xml
+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 to lobbying from us, recent releases of both Apache and IIS tie the application/atom+xml media type to the .atom extension, so if people are creating 0.3 files and calling them whatever.atom, this could be right. Having said that, I think we should push back. Because any such current usage is unlicensed by any spec, & because we plan to aggressively deprecate Atom 0.3 once we get 1.0 out and since I suspect that 90% of 0.3 feeds come from one place we should have some success. -Tim Begin forwarded message: From: Mark Baker <[EMAIL PROTECTED]> Date: April 20, 2005 11:13:54 AM PDT To: [EMAIL PROTECTED] Cc: iesg@ietf.org Subject: Re: For review: application/atom+xml [ CC: IESG, since I suppose this counts as a last call comment ] Mark, Congrats on going to last call with the atompub format! - http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt But I note that my comment[1] on the lack of any mention of the existing use of application/atom+xml with the incompatible Atom 0.3 content didn't make it in. Though not widespread, my understanding (though I'd be happy to be corrected!), at least at the time that you first drew up this media type[2], was that it was in use[3]. I certainly don't feel that this is a big enough problem to warrant a new media type, but I do think it should be flagged to implementors. Also, 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, I think referencing another spec's magic number algorithm to be prima facie incorrect. What I think should be there is information that, as uniquely as possible, identifies Atom documents, and RFC 3023 can, of course, only help with identifying XML documents. So I'd suggest either adding something about the root namespace value (if indeed the spec requires that the root element always be from the Atom namespace?) as I did for XHTML[4], or else just saying "Magic Number: None" (as we did for SOAP[5], in effect, by not providing an algorithm). Cheers, [1] http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/ 000678.html [2] http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html [3] http://diveintomark.org/archives/2003/12/13/atom03 [4] http://www.ietf.org/rfc/rfc3236.txt [5] http://www.ietf.org/rfc/rfc3902.txt Mark. -- Mark Baker. Ottawa, Ontario, CANADA.http://www.markbaker.ca -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems - Tim Bray, Director of Web Technologies, Sun Microsystems +1-877-305-0889 Sun ext. 60561 http://www.tbray.org/ongoing/ AIM: MarkupPedant -- Mark Nottingham http://www.mnot.net/
Re: PaceOptionalSummary
Robert Sayre wrote: On 4/26/05, Sam Ruby <[EMAIL PROTECTED]> wrote: Graham wrote: The pace as written newly allows the omission of a summary and content on the whim of the publisher. That's right. I'm within my rights as a consumer to reject title-only feeds as not worth bothering with (before you condemn this as an arbitrary decision, bear in mind the current Atom spec makes the same judgement). It is arbitrary. My point is that the spec does not reflect consensus in this working group or help interop. You're within your rights to reject anything, you just want the spec to back you up, and that's ridiculous. The atom spec would not give publishers fair warning of this. This is why I think it makes more sense as a "SHOULD" requirement. Well stated. I'd also add that apparently summary SHOULD be non empty in all of the cases where it is currently required as well as one new case: the case where the content is empty. Nonsense. Never. There are plenty of people here disagreeing with you. If you attempt to syndicate a contentless and summaryless entry, there will be people who drop it on the floor. It doesn't matter how many people write software that behaves otherwise, it is a reality that some will behave this way. From RFC 2119: SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I am willing to concede that there are valid reasons in particular circumstances to ignore the requirement for a summary. Are you willing to concede that there are implications to such a decision that must be understood and carefully weighed before chosing to omit a summary? - Sam Ruby
Re: PaceOptionalSummary
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: DSig (was: Comments on atompub-format-08 (Modified by Tim Bray))
At 10:02 PM -0400 4/26/05, Bob Wyman wrote: Paul Hoffman wrote: The intermediary can, however, add a signed extension that says "this message was earlier signed by Xyzzy, and we verified that signature before we changed things." Forgive me if I'm missing something obvious... While I understand that such a statement could be generated in theory, it is not obvious to me what the precise syntax for writing such a statement would be given just what is said about signatures in the Atom draft. It seems to me that we would have to either adopt additional syntax from some currently not-referenced spec, or we'd have to define a new extension. What would you propose is the correct way to get interoperable statements such as the ones you suggest in your note? The latter (an extension). Sorry if I didn't make that clear. >> One other *significant* limitation in Atom's support for signatures is that there is no way for an intermediary to add to or otherwise modify an Atom entry without breaking the signature. That's a purposeful design property of digital signatures. The exact same issue has long affected secure mail forwarders using S/MIME or OpenPGP. But, the problem is slightly less painful in S/MIME applications since you can wrap a signed message in an attachment while providing additional data in the envelope. Atom doesn't provide a similar mechanism. Correct, but the pain is certainly still there for S/MIME and OpenPGP. --Paul Hoffman, Director --Internet Mail Consortium
Re: PaceOptionalSummary
On 4/26/05, Sam Ruby <[EMAIL PROTECTED]> wrote: > > Graham wrote: > > > > The pace as written newly allows the omission of a summary and content > > on the whim of the publisher. That's right. > > I'm within my rights as a > > consumer to reject title-only feeds as not worth bothering with (before > > you condemn this as an arbitrary decision, bear in mind the current Atom > > spec makes the same judgement). It is arbitrary. My point is that the spec does not reflect consensus in this working group or help interop. You're within your rights to reject anything, you just want the spec to back you up, and that's ridiculous. > > The atom spec would not give publishers > > fair warning of this. This is why I think it makes more sense as a > > "SHOULD" requirement. > > Well stated. I'd also add that apparently summary SHOULD be non empty > in all of the cases where it is currently required as well as one new > case: the case where the content is empty. Nonsense. Never. There are plenty of people here disagreeing with you. Robert Sayre
Re: PaceOptionalSummary
Graham wrote: This argument has a got a bit sidetracked. My position is: a) I think title-only feeds should be allowed where there's nothing sensible to put in the summary or content elements. b) Under all other circumstances, a summary of some kind should be required when atom-based textual content is absent. The pace as written newly allows the omission of a summary and content on the whim of the publisher. It also allows its omission when the content of the entry has been placed in a non-atom container. My first problem is that neither of these consequences seem intended. My second is that it is the interopability issue. I'm within my rights as a consumer to reject title-only feeds as not worth bothering with (before you condemn this as an arbitrary decision, bear in mind the current Atom spec makes the same judgement). The atom spec would not give publishers fair warning of this. This is why I think it makes more sense as a "SHOULD" requirement. Well stated. I'd also add that apparently summary SHOULD be non empty in all of the cases where it is currently required as well as one new case: the case where the content is empty. - Sam Ruby
RE: DSig (was: Comments on atompub-format-08 (Modified by Tim Bray))
Paul Hoffman wrote: > The intermediary can, however, add a signed extension that > says "this message was earlier signed by Xyzzy, and we verified that > signature before we changed things." Forgive me if I'm missing something obvious... While I understand that such a statement could be generated in theory, it is not obvious to me what the precise syntax for writing such a statement would be given just what is said about signatures in the Atom draft. It seems to me that we would have to either adopt additional syntax from some currently not-referenced spec, or we'd have to define a new extension. What would you propose is the correct way to get interoperable statements such as the ones you suggest in your note? >> One other *significant* limitation in Atom's support for signatures >> is that there is no way for an intermediary to add to or otherwise modify >> an Atom entry without breaking the signature. > That's a purposeful design property of digital signatures. The exact > same issue has long affected secure mail forwarders using S/MIME or > OpenPGP. But, the problem is slightly less painful in S/MIME applications since you can wrap a signed message in an attachment while providing additional data in the envelope. Atom doesn't provide a similar mechanism. bob wyman
Re: PaceOptionalSummary
This argument has a got a bit sidetracked. My position is: a) I think title-only feeds should be allowed where there's nothing sensible to put in the summary or content elements. b) Under all other circumstances, a summary of some kind should be required when atom-based textual content is absent. The pace as written newly allows the omission of a summary and content on the whim of the publisher. It also allows its omission when the content of the entry has been placed in a non-atom container. My first problem is that neither of these consequences seem intended. My second is that it is the interopability issue. I'm within my rights as a consumer to reject title-only feeds as not worth bothering with (before you condemn this as an arbitrary decision, bear in mind the current Atom spec makes the same judgement). The atom spec would not give publishers fair warning of this. This is why I think it makes more sense as a "SHOULD" requirement. (btw The list of scenarios reprinted in the Pace doesn't mention whether you MAY include atom:summary outside the MUST cases) Graham
Re: PaceOptionalSummary
On 4/26/05, Roger B. <[EMAIL PROTECTED]> wrote: > And so on... I honestly can't think of a single child of atom:entry > that is required for interop. Yeah, I agree. The WG does not, however. They do happen to agree with me on this issue. > No one needs Atom for producing a title-and-link feed. It's overkill, > and pointless. The juice in Atom is in the handling of content... > providing for explicit summaries, and clearly defined payload types. The juice in Atom has little to do with the syndication format. IDs and dates are big, though. Robert Sayre
Re: PaceOptionalSummary
On Tuesday, April 26, 2005, at 05:48 PM, Roger B. wrote: That's not good enough. You have to demonstrate an interop problem to say SHOULD or MUST. Interop with *what*, Robert? What's the baseline? Interop with other Atom processing software. The spec is the baseline. The requirements of the spec are (hoepfully!) based on what's needed to enable apps to share feeds in a useful way. Let's see how losing an element other than summary might affect interop--atom:id. If entries don't have atom:id, then consumers will have to jump through all sorts of hoops to determine whether one entry is the same as one seen before, or an updated version of one seen before, or something completely new. Any actions that depend on whether Entry A == Entry B or not would be at the mercy of an app's ability to correctly divine whether they're the same entry or not. Dropping the requirement for atom:id would clearly have a negative impact on interoperability. How would an entry not having neither atom:summary nor atom:content cause problems? "Apps that expect all feeds to have a summary or content would choke" isn't a convincing argument because it's circular. If title and link feeds are allowed by the spec, then apps that can't handle them are broken. When their author's become aware that title and link feeds are possible, I can't fathom they'd have too much trouble fixing their apps. No one needs Atom for producing a title-and-link feed. It's overkill, and pointless. The juice in Atom is in the handling of content... providing for explicit summaries, and clearly defined payload types. So if you don't want to provide a summary or content, go away. RSS can have you? Atom is only overkill if we require a lot of elements that aren't needed for interop.
Re: PaceOptionalSummary
* Tim Bray <[EMAIL PROTECTED]> [2005-04-25 20:35]: > I decided it would help if there was an actual Pace: > http://www.intertwingly.net/wiki/pie/PaceOptionalSummary So far I havenât seen a cogent explanation of the significant semantics offered by an empty atom:summary inside an otherwise valid minimum atom:entry (with an atom:id, atom:title, and atom:[EMAIL PROTECTED]'alternate']). Near as I can tell, there is no discernible difference between an empty and an absent summary (given the presence of the mandatory other information!). Tentatively +1. I also suggest that any cogent explanation would need to be put on record in the spec, to alert implementors to the issues and guide them to an educated choice. Otherwise, they are likely to disregard this issue either wilfully or out of negligence. Regards, -- Aristotle
Re: PaceOptionalSummary
> That's not good enough. You have to demonstrate an interop problem to > say SHOULD or MUST. Interop with *what*, Robert? What's the baseline? No aggregator *requires* a title... one can be synthesized. No aggregator *requires* an id... links, hashes, and so on do the job sufficiently for most purposes. No aggregator *requires* a date... if one's not attached, we can just slap on the date we acquired the entry. And so on... I honestly can't think of a single child of atom:entry that is required for interop. In which case, the only MUST in the spec would be "atom:entry MUST contain at least one child element of some kind. Have fun with that." No one needs Atom for producing a title-and-link feed. It's overkill, and pointless. The juice in Atom is in the handling of content... providing for explicit summaries, and clearly defined payload types. -- Roger Benningfield
Re: PaceOptionalSummary
Graham wrote: On 26 Apr 2005, at 9:53 pm, Robert Sayre wrote: On 4/26/05, Graham <[EMAIL PROTECTED]> wrote: Without knowing this (which it wouldn't under Tim's proposal), my app can't reliably interoperate with yours. I have no idea what you're talking about. Do the feeds on craigslist.org interoperate? Yes or No? Interoperate with what? If I write an app that needs to know whether an entry had a body that was removed or is a title-only feed, it cannot interoperate with Atom feeds under Tim's proposal because there is no difference between them. This is totally an interoperability issue. I'm not sure what you're saying is sensible. If you wrote that app, you've gone beyond anything Atom format mandates. Getting on board with your app would induce bug compatability, not interop. cheers Bill
Re: PaceOptionalSummary
On 4/26/05, Graham <[EMAIL PROTECTED]> wrote: > If I write an app that needs to know whether an entry had a body that > was removed or is a title-only feed, uh, what's the difference. > it cannot interoperate with Atom > feeds under Tim's proposal because there is no difference between them. > This is totally an interoperability issue. Nonsense. None of Atom's elements communicate that information, and there is no requirement to do so. Next. Robert Sayre
Re: PaceOptionalSummary
On 26 Apr 2005, at 9:53 pm, Robert Sayre wrote: On 4/26/05, Graham <[EMAIL PROTECTED]> wrote: Without knowing this (which it wouldn't under Tim's proposal), my app can't reliably interoperate with yours. I have no idea what you're talking about. Do the feeds on craigslist.org interoperate? Yes or No? Interoperate with what? If I write an app that needs to know whether an entry had a body that was removed or is a title-only feed, it cannot interoperate with Atom feeds under Tim's proposal because there is no difference between them. This is totally an interoperability issue. Graham
Re: PaceOptionalSummary
On Tuesday, April 26, 2005, at 02:49 PM, Graham wrote: So your app sends me an Atom document that looks like this: whetever So Caleb is Lindsey's father What does this mean? a) A title only feed b) A full entry with the summary missing. Without knowing this (which it wouldn't under Tim's proposal), my app can't reliably interoperate with yours. What if you get this: whetever So Caleb is Lindsey's father DNA testing has proven Caleb is Lindsey's father What does this mean? a) a title and summary only entry b) a full content entry with the content missing c) a summary and extension element entry with dc:modified missing etc. etc. etc. As long as an entry meets the requirements of the spec, if an element isn't there, the consumer (unless it has some special out-of-band knowledge) has to assume that the entry is complete. If anything that the publisher intended to have there is missing, then their software has a bug or they've misconfigured it, and ensuring that their buggy or incorrectly configured software interoperates well is beyond the scope of the spec, is it not?
Re: PaceOptionalSummary
* Graham <[EMAIL PROTECTED]> [2005-04-26 23:00]: > So your app sends me an Atom document that looks like this: > > > whetever > So Caleb is Lindsey's father > > > What does this mean? Thatâs invalid, since itâs missing both an atom:content as well as an atom:[EMAIL PROTECTED]'alternate']. It must have one or the other. > a) A title only feed > b) A full entry with the summary missing. > > Without knowing this (which it wouldn't under Tim's proposal), > my app can't reliably interoperate with yours. How would supplying a token change anything about the meaning? Regards, -- Aristotle
Re: PaceOptionalSummary
On 26 Apr 2005, at 8:54 pm, Robert Sayre wrote: On 4/26/05, Roger B. <[EMAIL PROTECTED]> wrote: I'd be willing give a +1 to SHOULD language regarding summary/content. That's not good enough. You have to demonstrate an interop problem to say SHOULD or MUST. So your app sends me an Atom document that looks like this: whetever So Caleb is Lindsey's father What does this mean? a) A title only feed b) A full entry with the summary missing. Without knowing this (which it wouldn't under Tim's proposal), my app can't reliably interoperate with yours. (Why does my app need to know? None of our business) Graham
Re: PaceOptionalSummary
On 4/26/05, Roger B. <[EMAIL PROTECTED]> wrote: > > I'd be willing give a +1 to SHOULD language regarding summary/content. That's not good enough. You have to demonstrate an interop problem to say SHOULD or MUST. > I'd prefer one or the other be required for a weblog-centric format > like Atom, but I'll just do what I already do with title-only RSS > feeds... have my code reject them as inadequate. Just like it would reject an entry containing , since it means the same thing, right? You yourself send them: http://www.imc.org/atom-syntax/mail-archive/msg14147.html They are clearly adequate for some class of applications, so please demonstrate the interoperability problems they cause. Robert Sayre
Re: PaceOptionalSummary
> Do the following messages mean the same thing? Robert: In my app? Yep, exactly the same. -- Roger Benningfield
Re: PaceOptionalSummary
I'd be willing give a +1 to SHOULD language regarding summary/content. I'd prefer one or the other be required for a weblog-centric format like Atom, but I'll just do what I already do with title-only RSS feeds... have my code reject them as inadequate. -- Roger Benningfield
Re: PaceOptionalSummary
Does much of this debate come down simply to whether there is a distinction between an empty summary and an absence of a summary? I am in favour of an optional summary because if there is no summary, I would rather not see I can understand that people that don't have a problem with meaning "no summary" would not see any reason to make it optional. James -- James Tauber http://jtauber.com/ journeyman of somehttp://jtauber.com/blog/
Re: PaceOptionalSummary
> The feedvalidator catches silly, boring corner-cases every day. > > I hesitate to bring it up again as it has proven to incite adhominen > attacks from within this workgroup, but we have an example of a > respected journalist who has published a book in which he specifically > called out this. So? What does that have to do with interop? > > And we have the experience from RSS 2.0 (motto: everything is optional! > and extensible!) whereby Don Box introduced xhtml:body into his feed in > place of description, something that most aggregators support today. Yes, and he just might stick xaml:body in there next year. We can't stop him. > On the other hand, what we have is arguments that entries with empty > summaries is not possible with the current format - something that is > blatantly incorrect. Well, the argument was originally that people don't like title-only feeds, so we shouldn't even worry about them (see journalist point above). > > We also had a very complex and delicate negotiation a while back that > seems to have been forgotten. It is quite possible to produce feeds > with content that is base64 encoded binary or out of band. What is > desired in such circumstances is precisely akin to specifications that > require alt attributes for img tags. It atom's case, it is a summary. I've edited Tim's Pace to show what the resulting text would look like, since a summary would still be required in such circumstances. Hopefully, the resulting requirements are clear now. Robert Sayre
Re: PaceOptionalSummary
Tim Bray wrote: I was driving to the airport with Lauren, whom some of you will know, she's technical but hasn't been following Atom. I explained the debate we are having over the required-ness of , and she said "Don't you have anything better to talk about?" I suspect she has a point. Suppose we leave it the way it is... people who don't want to include a summary can use , so it's just silly to say that there's an example of a current feed that would be ruled out. For that matter, Graham's body-only feeds can be done with . I can see Sam's arguments, but on the other hand, the errors that might get caught by requiring summary are probably boring corner-cases anyhow. Which is to say, it doesn't matter very much. Which is to say, 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. -Tim The feedvalidator catches silly, boring corner-cases every day. I hesitate to bring it up again as it has proven to incite adhominen attacks from within this workgroup, but we have an example of a respected journalist who has published a book in which he specifically called out this. And we have the experience from RSS 2.0 (motto: everything is optional! and extensible!) whereby Don Box introduced xhtml:body into his feed in place of description, something that most aggregators support today. On the other hand, what we have is arguments that entries with empty summaries is not possible with the current format - something that is blatantly incorrect. We also had a very complex and delicate negotiation a while back that seems to have been forgotten. It is quite possible to produce feeds with content that is base64 encoded binary or out of band. What is desired in such circumstances is precisely akin to specifications that require alt attributes for img tags. It atom's case, it is a summary. If you want to push through this pace, I suggest that we revisit and reopen those discussions. Schedule be damned. - Sam Ruby
Re: PaceOptionalSummary
On 4/26/05, Tim Bray <[EMAIL PROTECTED]> wrote: > she said > "Don't you have anything better to talk about?" I suspect she has a > point. Welcome to atom-syntax. :) > Suppose we leave it the way it is... people who don't want to > include a summary can use , so it's just silly to say that > there's an example of a current feed that would be ruled out. Consider a message from client to server using the Atom Protocol. Do the following messages mean the same thing? ... ... ... ... ... ... ... ... ... I have my thoughts, but the WG hasn't decided. Robert Sayre
Re: PaceOptionalSummary
Tim Bray wrote: http://www.intertwingly.net/wiki/pie/PaceOptionalSummary 0 As editor of the one the protocols cited in favour (HTTPLR) I'd like to clarify this position, especially as the debate around this issue has imo been emotionally charged; most recently there's been talk of inappropriateness and steamrolling. That encourages me to stay neutral. The absence or otherwise of atom:summary causes no interoperability problems for that protocol; HTTPLR agents are not licensed to process summaries. The use of Atom in HTTPLR is arguably not a common usecase (today at least). Of the people I know implementing it, atom:summary has not come up as an issue. It appears to make no odds one way or another if atom:summary there or not empty or not. Finally please note that HTTPLR is different from the other cases cited which might or might not be relevant to the IESG and ATOMPUB. First, it's a protocol, not a website. Second, it's not gone through the IETF process a la APP, though it will appear as an I-D around June of this year. cheers Bill
Re: Last Call: required summary or content?
Sam Ruby wrote: ... I will again point out that the current format allows for empty summary and/or content elements. I have seen errors that the requirement for the inclusion of such elements would have prevented. I have seen no arguments as to why placing such empty elements would impose an unreasonable burden on implementers. ... Again speaking based on experience using XML formatted protocol data: As far as I can tell, using empty elements to signal the *absence* of information is a potential source of interoperability problems. For instance, clients may behave differently based on whether some piece of data exists, but fail to handle an empty string value as "no" value. So, at a minimum, the spec would need to be clear about the fact that if something has no text content, it means "this information is missing" instead of "this information is present and has an empty string value". Also keep in mind that people *will* break rules as long at it simplifies their own work and they get away with it. It'll be hard to explain why it's necessary to marshall an element with no text content, if clients will treat the absence of this element the same way (and they will). If both notations carry the same semantics, and both are likely to be used no matter what the RFC says, it IMHO would be wise to allow both. Best regards, Julian
