Re: Atom 1.0?
On May 10, 2005, at 1:27 PM, Robert Sayre wrote: If we choose a specific name, it *must* be in the RFC. Because the RFC must be a hit for that search. Marketing: Atom Technical: Atom (RFC) I was gonna suggest that too. I think RFC's are into the 4000-space these days so if we end up as RFC4321 we could call it Atom 4321 and Atom [see RFC4321]. -Tim
Re: Atom 1.0?
Marketing: Atom Technical: Atom (RFC) +1 -- http://dannyayers.com
Re: Atom 1.0?
On 5/11/05, Danny Ayers [EMAIL PROTECTED] wrote: Marketing: Atom Technical: Atom (RFC) +1 Hmm. I forgot one little detail. It might take like 4-6 months to get an RFC number after IESG approval. Robert Sayre
Re: Atom 1.0?
Marketing: Atom I'm looking forward to an article by Mark Pilgrim about the incompatible versions of Atom deceitfully marketed as one thing. :-) (Which is why I said +1 to Atom 1.0.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Atom 1.0?
Henri Sivonen wrote: Marketing: Atom I'm looking forward to an article by Mark Pilgrim about the incompatible versions of Atom deceitfully marketed as one thing. :-) (Which is why I said +1 to Atom 1.0.) ARSS, short for Atom RSS. The marketing possibilities are endless. cheers Bill
Re: Atom 1.0?
* Bill de hra [EMAIL PROTECTED] [2005-05-11 17:05]: ARSS, short for Atom RSS. The marketing possibilities are endless. How about Atom Syndication Standard? I guess the Firefox crowd can then resurrect the non-Wifi looking autodiscovery icon. Regards, -- Aristotle
Fetch Me A Rock
Fetch me a rock. No, not that one. Fetch me another. Now jump through this hoop. I think the reason there is no consensus on-list is because Sam and Graham are trying to make normative requirements without outlining the operational result they are after. I am disappointed we are putting up with it, but I am not surprised. They'll give you ten different definitions of SHOULD, but there's only one that matters. Remember, if we say SHOULD, that means implementations don't have to interoperate with people who don't provide a summary. That does not mean 'doesn't display' or 'doesn't index', despite what some would have you believe. It means the Atom Processor is allowed to fail. It doesn't matter if that's not what we meant. The document's meaning would be unambiguous. SHOULD does not mean encourage. Remember that. I'm not going argue any more. My opinion is clear, strong, and supported by many others. Robert Sayre
Re: Atom 1.0?
On Wednesday, May 11, 2005, at 09:09 AM, A. Pagaltzis wrote: * Bill de hÓra [EMAIL PROTECTED] [2005-05-11 17:05]: ARSS, short for Atom RSS. The marketing possibilities are endless. How about Atom Syndication Standard? So, ASS = Atom Syndication Standard. Or is it Atom Standard for Syndication? Or is it Atom Site Summary? ARSS = Atom Really Simple Syndication ARSS = Atom Rich Site Summary ARSS = Atom Replacement Syndication Standard ARS = Atom Reformed Syndication ARSE = Atom Revolutionary Syndication Experiment ANR = Atom is Not RSS ... I guess that should be ANR is Not RSS ANA0.3 = Atom is Not Atom 0.3, or ANA0.3 is Not Atom 0.3 Hey, maybe ATOM is an acronym and we didn't even know it. A Tired Old Metaphor. Hmm, not so good. A new Twist on an Old Method. Too many missing letters to explain away. After The Old Method. Same message, right letters. A Trick, Or Magic? From section 7. IANA Considerations: 'Magic number(s): As specified for application/xml in [RFC3023], section 3.2.'--must be magic!
Re: Last Call: required summary or content?
There's one more issue that I would like to make the IESG aware of before it evaluates the Atom Syndication Format. I don't believe the format satisfies the Atompub charter: The format must be able to represent: * a resource that is a Weblog entry or article (e.g., it has an author, date, identifier, and content) * a feed or channel of entries, with or without enclosed content * a complete archive of all entries in a feed * existing well-formed XML (especially XHTML) content * additional information in an user-extensible manner The current draft fails to satisfy the second bullet point. Robert Sayre P.S. -- Here are a couple of messages underscoring that atom:summary and atom:content both serve as enclosed content. Tim Bray: http://www.imc.org/atom-syntax/mail-archive/msg14155.html Sam Ruby: http://www.imc.org/atom-syntax/mail-archive/msg14057.html On 4/25/05, Sam Ruby [EMAIL PROTECTED] wrote: Robert Sayre wrote: * What the specification does currently In an Atom Entry, the specification currently requires a minimum set of elements: title, id, and updated. Typically, there will also be a link element. The specification includes a provision that allows its omission on the condition that there is a content element. In addition to that, the specification requires that either summary or content be present. * What you would like it to do instead I want to allow the metadata-only feeds allowed by all flavors of RSS, and the omission of the content and summary. Such feeds are commonly termed title-only feeds, because that is all that is visible to the user (the title is usually hyperlinked w/ the link element). 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. - Sam Ruby
Re: extensions -- Atom NS and unprefixed attributes
At 12:14 AM -0400 5/11/05, Robert Sayre wrote: On 5/9/05, Robert Sayre [EMAIL PROTECTED] wrote: I am fine with that. I am concerned that the current draft fails to differentiate between foreign markup and markup that requires IESG approval. I am going to try this again, because it's important. entry fooBar=true title.../title evilExtension / ... /entry Legal? Which part of the spec rules it out? Maybe I've read it too many times and I'm missing something. Common sense would seem to outlaw it, but that's not good enough. Hearing from as many people who feel that they understand the XML rules would be very good right about now... --Paul Hoffman, Director --Internet Mail Consortium
Re: Atom 1.0?
At 9:45 AM -0400 5/11/05, Robert Sayre wrote: On 5/11/05, Danny Ayers [EMAIL PROTECTED] wrote: Marketing: Atom Technical: Atom (RFC) +1 Hmm. I forgot one little detail. It might take like 4-6 months to get an RFC number after IESG approval. s/might/probably will/ --Paul Hoffman, Director --Internet Mail Consortium
Re: Last Call: required summary or content?
On 11 May 2005, at 10:58 pm, Robert Sayre wrote: I don't know what your goal is, so I'm just throwing things out there to see if they're what you want. Please explain your problems with each option, and I will try to work with you. Please note that the interests of other implementors and users may not line up with yours. The Implementor's Guide may or may not ever exist and may or may not be read by anyone, so that isn't an option. Myself and Sam, and (I think) Tim and Antone, would all like the actual spec to make an actual recommendation that entries without enclosed content include a textual summary, if at all possible. Note no one wants to ban title- only feeds if they come from title-only resources. What language would you find acceptable that covers these bases? Graham
Re: extensions -- Atom NS and unprefixed attributes
Hello Paul, Many thanks for the citations below, this is extremely clear. Going back to the original question/pace that you gave a -1, would that change if in the text IETF Consensus was replaced with IESG Approval? Regards, Martin. At 10:56 05/05/11, Paul Hoffman wrote: At 4:15 PM +0900 5/10/05, Martin Duerst wrote: What's the difference between IETF consensus (for which you gave a -1) and it's up to the IESG (which seems what you think we should let happen)? From RFC 2434: IESG Approval - New assignments must be approved by the IESG, but there is no requirement that the request be documented in an RFC (though the IESG has discretion to request documents or other supporting materials on a case-by-case basis). IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists). --Paul Hoffman, Director --Internet Mail Consortium
Re: Last Call: required summary or content?
Robert, I'm trying to include you in this discussion and you're not cooperating. You are the only person in the WG who has said there shouldn't be any recommendation in the specification. You are vastly outnumbered by people who've stated they'd be OK with it. The only question now is the wording. Graham
Re: Last Call: required summary or content?
On 5/11/05, Graham [EMAIL PROTECTED] wrote: Robert, I'm trying to include you in this discussion and you're not cooperating. You are the only person in the WG who has said there shouldn't be any recommendation in the specification. You are vastly outnumbered by people who've stated they'd be OK with it. The only question now is the wording. Is that right? I don't think it is. If you think I've stated something incorrectly, make your opinion known to the IESG. Robert Sayre
Re: Last Call: required summary or content?
On 12 May 2005, at 1:51 am, Bill de hÓra wrote: The WG has tended to punt assuming on a Fabled Implementors Guide. Why is that punt not acceptable now? I know putting things in the IG has been mentioned before, but I can't think of any actual cases where that was the outcome of the debate - things have either been put in the spec, or rejected outright. This needs to go in the spec. It's just as much of an techical/interop issue as Logos must have a 2:1 aspect ratio. Bray voiced concerns about SHOULD; I suggested MAY. No further discussion occurred. What might be wrong with a MAY requirement in this case? MAY is fine as the actual RFC term, but needs to be embellished, eg: atom:summary MAY be included, but software is encouraged to do so when atom:content is not present As I've said before, I don't know what the exact wording needs to be. Is there an RFC-compatible way to get the intention of this sentence across? This question is put mainly to the chairs and the AD, btw. Graham
