Resolving for rel values (Was: Re: Current and permalink link rel values)
At 8:16 AM -0500 2/23/07, Elliotte Harold wrote: By the way, http://www.iana.org/assignments/relation/ is 404. This is referenced in the Atom 1.0 spec. It doesn't really need to be resolved, but it would be nice to put something there. It doesn't need to be resolved at all. Given the technical abilities of IANA, putting something there (or at http://www.iana.org/assignments/relation/self and so on) is probably worse than a definitive 404.
Re: Atom Entry docs
At 4:41 PM +0900 12/13/06, 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 prefixes like vnd. (vendor) and so on. In the case of atom entries, atom-entry is more in line with the convention in other types. +1
Robert Sayre again banned from posting to the lists for 30 days
Because of his recent ad hominem attacks, I have temporarily suspended Robert Sayre's posting privileges for the two Atompub WG mailing list for 30 days, as specified in RFC 3934. If you have questions or comments about this action, please first take them to Tim and me offline.
Re: PaceMakeAutodiscoveryInformational
At 4:56 PM -0500 11/28/06, Robert Sayre wrote: James M Snell wrote: 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. This looks like an inappropriate personal attack to me. co-chair-hat value='on'It may look like that to you, but it does not look that way to the WG Chairs. Please immediately stop posting messages such as this to the mailing list, It gets in the way of the technical discussion. If you cannot stop yourself from posting such messages, please consider not posting any more messages to the mailing list at all. /co-chair-hat
Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
At 6:16 PM -0500 11/28/06, Robert Sayre wrote: On 11/28/06, Rogers Cadenhead [EMAIL PROTECTED] wrote: I have no idea how to gauge the likelihood they'll achieve it. Or whether they'll respect current autodiscovery functionality in MSIE 7 and Firefox 2.0. My experience is that the IETF is essentially unresponsive to backward compatibility concerns, The IETF has been very good with this on some protocols, and bad on others. Even if a major vendor has deployed something, if it is technically broken or limited, the IETF will generally ignore it. If the protocol is just acceptable, we will spend a huge amount of time trying to decide between good enough and replace it, usually with silly results. to the extent that they will debate the meaning of the term MUST. It's like existential poetry. +1
Re: Forward Compatibility
At 9:48 PM +0100 11/18/06, A. Pagaltzis wrote: If future changes can be made in a backward-compatible fashion, they will go into a spec that recycles the same namespace. Existing implementations can just ignore the differences. If they cannot, they will go into a spec which revs the namespace, because trying to process documents conforming to the new spec with existing implementations can't work. Exactly right. This is another reason why Atom does not have a version attribute. +1
Re: [atom-syntax] Atom bidi
At 1:32 PM -0800 11/3/06, James M Snell wrote: Cool thx. I'll watch for it following the IETF meeting. Actually, the window opens again the first day of the meeting (Monday).
Re: Atom Syndication Format To Draft Standard?
At 3:01 AM -0400 10/2/06, Robert Sayre wrote: I think we should move the format to Draft Standard by clearing up any errata and adding two attributes: 'dir' and 'unicode-bidi', as defined in XHTML. We can't both add features and move to Draft Standard at the same time. If we add features, we would recycle at Proposed Standard. Errata that are truly that and not technical changes can be made when moving to Draft Standard.
Re: Atom Syndication Format To Draft Standard?
At 11:17 AM -0400 10/2/06, Robert Sayre wrote: Paul Hoffman wrote: At 3:01 AM -0400 10/2/06, Robert Sayre wrote: I think we should move the format to Draft Standard by clearing up any errata and adding two attributes: 'dir' and 'unicode-bidi', as defined in XHTML. We can't both add features and move to Draft Standard at the same time. Dang, where'd that rule come from? Probably RFC 2026, but if not there, it is certainly in the folklore of How Things Are Done. It would probably be easier to add them in a separate document, huh? Maybe, but that would then confuse the issue by having two docs people would expect to have read in order to do the format. Given the very marginal value of Draft Standard, we should probably just revise and recycle at Proposed rather than split into two.
Re: Atom Syndication Format To Draft Standard?
At 6:23 PM + 10/2/06, Robert Sayre wrote: That's unfortunate. A documented process is a requirement for open standards development, in the opinion of many If it is a true requirement, then I guess the IETF is an abysmal failure. Oh, well. OTOH, some folks in the IETF are trying to meet the desire by doing a better job of codifying what is and is not the process. Others, I must admit, are not trying at all. There is one mistake in the Relax NG (atom common attributes on author or something) and at least one section that is somewhat unclear around the external div in XHTML. I believe both of those would be considered clarifications, and thus not prevent the movement to Draft Standard. The i18n attributes seem needed to display text without a guess based on xml:lang. Maybe we don't even need unicode-bidi. I don't think it would be smart to take other features. needed to display is often an issue the IETF ignores, so we might avoid it if the desire is to get to Draft Standard. But Julian's second message needs to be dealt with first, and I assure you that many of those documents are not going to be going to Draft Standard any time soon (if ever) because there is no energy to test every required feature in the documents.
Very brief minutes from the Atompub WG meeting
... are at http://www3.ietf.org/proceedings/06jul/minutes/atompub.txt --Paul Hoffman, Director --Internet Mail Consortium
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
At 8:35 PM -0400 6/26/06, Robert Sayre wrote: On 6/26/06, The IESG [EMAIL PROTECTED] wrote: Working Group Summary This is not a WG draft. Nevertheless, the AtomPub WG discussion on this draft was fairly lengthy, and resulted in a number of changes to the draft. Who wrote this summary? Probably Lisa. Even Paul went on the record saying there was no consensus on several aspects of the document. Right. The statement above doesn't say anything about consensus. This summary makes it sound like it underwent a number of friendly suggestions, rather than disapproval by at least half of the commenters, interupted only by incorrect readings of RFC2026 and obfuscation by the document author. Your reading might differ from others'. --Paul Hoffman, Director --Internet Mail Consortium
Re: Feed Thread approved as a Proposed Standard
At 4:34 PM -0400 6/23/06, Robert Sayre wrote: It is surely appropriate for IETF members to suggest an alternate status for the document, no matter what the IESG eventually decides. That's one view, and an unfortunately common one. The view I prefer is follow RFC 2026 because no one is going to remember the logic for not following it after the RFC is published. Yes, I'm a bit of a priss about these things... In this case, an appeal to the rules was made, but RFC 2026 does not place limits on the sort of feedback the community may give. Correct. It is up to the IESG to decide on a case-by-case basis if there was adequate discussion. I don't feel the community has control of this document, and that bothers me. Once something is an RFC, the community has control in that an effort can be made to obsolete a document with a new one, or extend a document with a new one. That is weak control because it takes a lot of effort and elapsed time, and it might not succeed. Fortunately, anyone can form a community if they feel like doing the work; they might be listened to. (This in contrast with other standards bodies that do not allow revisions by random developers or other interested parties.) --Paul Hoffman, Director --Internet Mail Consortium
Re: Atompub WG meeting at the Montreal IETF
At 1:49 PM -0700 5/23/06, Paul Hoffman wrote: Greetings again. The Atompub WG will have our first (and maybe last!) face-to-face meeting at the upcoming IETF meeting in Montreal at the beginning of July. The timing of us having our first WG meeting may seem odd, given the fact that we completed the Atom format document long ago, and are making good progress on the publishing protocol. However, there are reasons other than moving documents forwards for WGs to meet. Lisa Dusseault, our Area Director, asked us to have a meeting so that people active in the Atompub WG can have more interaction with the IETF, and vice versa. There is interest in the Atom format from other WGs, and there may be interest in the Atom publishing protocol as well. I propose the following agenda, which should fit well into a one-hour slot: - Intro: 10 mins - Brief overview of protocol status: 10 mins - Use of Atom format in other WGs: 30 mins - draft-saintandre-atompub-notify - Overlap with calendar formats - Overlap with mail Note that we are explicitly *not* going to discuss extensions to the Atom format at this WG meeting because they are not part of the WG charter. Lisa has said that she may help arrange a BoF session on creating a new Working Group for Atom extensions, and having at least a higher-level discussion of what extensions are out there would be appropriate in that BoF. But, to use asterisks again, such discussion is *not* part of the Atompub WG meeting. See http://www.ietf.org/meetings/IETF-66.html for details about the IETF meeting. I will let the WG know when there are preliminary and near-permanent agendas for the meeting. It would be good to meet some of you there! We are tentatively scheduled for Wednesday afternoon; see https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=66. I say tentatively because the schedule will probably shift a bit for the next two weeks; my guess is that we are 80% likely to stay in the same spot. I have not received any offers to talk about Overlap with calendar formats or Overlap with mail at the BoF, but am still quite receptive to people making such offers. --Paul Hoffman, Director --Internet Mail Consortium
Atompub WG meeting at the Montreal IETF
Greetings again. The Atompub WG will have our first (and maybe last!) face-to-face meeting at the upcoming IETF meeting in Montreal at the beginning of July. The timing of us having our first WG meeting may seem odd, given the fact that we completed the Atom format document long ago, and are making good progress on the publishing protocol. However, there are reasons other than moving documents forwards for WGs to meet. Lisa Dusseault, our Area Director, asked us to have a meeting so that people active in the Atompub WG can have more interaction with the IETF, and vice versa. There is interest in the Atom format from other WGs, and there may be interest in the Atom publishing protocol as well. I propose the following agenda, which should fit well into a one-hour slot: - Intro: 10 mins - Brief overview of protocol status: 10 mins - Use of Atom format in other WGs: 30 mins - draft-saintandre-atompub-notify - Overlap with calendar formats - Overlap with mail Note that we are explicitly *not* going to discuss extensions to the Atom format at this WG meeting because they are not part of the WG charter. Lisa has said that she may help arrange a BoF session on creating a new Working Group for Atom extensions, and having at least a higher-level discussion of what extensions are out there would be appropriate in that BoF. But, to use asterisks again, such discussion is *not* part of the Atompub WG meeting. See http://www.ietf.org/meetings/IETF-66.html for details about the IETF meeting. I will let the WG know when there are preliminary and near-permanent agendas for the meeting. It would be good to meet some of you there! --Paul Hoffman, Director --Internet Mail Consortium
Re: Feed Thread in Last Call
At 8:39 PM +0100 5/23/06, Sylvain Hellegouarch wrote: At the end of the day, the marketplace will work within the constraints of what 4287 allows; my feeling is that there are going to be a ton of extensions that will attach unforeseen metadata at arbitrary points with Atom documents, and implementations that fail to store these and make them retrievable will quickly be seen as broken. -Tim Sounds about right. Where do we stop then? If the marketplace decides, is there a need to submit the FTE to the IETF? Will any extensions need to be submitted? Only Atom per see needed to be standardised in such a case. Welcome to the messy world of standards. There might be a need for an updated FTE RFC. On the other hand, if the market gives a big yawn, there is probably no need to update the RFC if no one is using it. On the third hand, it doesn't hurt to have it updated anyway; there are lots of RFCs that have barely any implementations. There is probably a fourth hand consideration as well. There is no clear delineation point for when an extension should become an RFC. The IETF plays it by ear. For some protocols, lots of extensions as RFCs has been a boon; for others, just a bother. We won't know where the Atom format fits in that range for a few years. --Paul Hoffman, Director --Internet Mail Consortium
Re: Atompub WG meeting at the Montreal IETF
At 2:31 PM -0700 5/23/06, James M Snell wrote: This sounds good so long as we can get the extensions BOF scheduled the on the same day as the WG meeting. Good point. The fact that the WG meeting is one hour strongly suggests that we will be on Tuesday afternoon, the traditional time for one-hour slots. If Lisa's BoF is also one hour, it is very likely to be that day as well. If she goes for an informal Bar BoF, it could be lunch or dinner that day. Also, it would be great if we could get together for some face-to-face interop testing before and/or after the WG meeting. That can be arranged for the weekend before; I'll be in Montreal early. Depending on the number of people, we could just get together in a hallway somewhere, or maybe in someone's Montreal office, or something. --Paul Hoffman, Director --Internet Mail Consortium
Re: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard
At 1:58 AM +0200 5/19/06, Robert Sayre wrote: On 5/19/06, Lisa Dusseault [EMAIL PROTECTED] wrote: This announcement is for a document that will obsolete RFC3548, which is referenced by a couple APPS area RFCs: XMPP (RFC3920) and Atom Syntax (RFC4287). Yep, this definitely breaks RFC4287 in the way Joe predicted. Time for a revision. I'm confused. What breaks? --Paul Hoffman, Director --Internet Mail Consortium
Re: Feed Thread in Last Call
At 4:33 AM +0200 5/16/06, Robert Sayre wrote: I thought the working group was fairly clear about the dubious value and placement of these attributes, For the benefit of Lisa, who is the sponsoring AD for this document, please list links to those messages. So you don't think they're important or needed, and then WG doesn't have consensus on them. Quite true, but it is true because there has never been a call for consensus on the document, and there won't be in the future. In the IETF, individuals can submit documents to become RFCs without those documents being Working Group items. This document (and all of the other format extension documents out there) fall into that category. If the author asks an Area Director to have the document published as a standards-track RFC, the AD will most likely ask for input on any relevant mailing list, including any existing WG mailing lists. You don't have to listen to the WG, but if one or two WG members are going to deploy and then standardize whatever they've done, that's an informational document. That is not true. If it is a protocol or a format, standards track is also appropriate. --Paul Hoffman, Director --Internet Mail Consortium
Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))
At 1:20 AM +0100 5/17/06, Bill de hÓra wrote: I'm -0 this becoming a Proposed Standard. I think this is really cool, has room for interop problems, probably has security issues, and thus is arguably premature/innovative and could be considered informational. These are not reasons to make something an Informational RFC. In the minds of developers, there is no difference between Informational and standards-track RFCs. The IETF's differentiation between types of RFCs has always been confusing, but that is not a reason for us to niggle on a particular document. This document describes an extension to an existing standards-track document: it should either be on standards track or it should not be an RFC. If the document has room for interop problems, and/or security issues, they should be stated so that the sponsoring AD, and the IESG as a whole, can decide whether or not the document is ready to be an RFC, regardless of the type of RFC it will become. --Paul Hoffman, Director --Internet Mail Consortium
Re: wiki mime type
At 8:55 AM -0800 3/7/06, Walter Underwood wrote: Don't use x-, either. Register a real type. +1 --Paul Hoffman, Director --Internet Mail Consortium
Re: AtomPubIssuesList for 2005/11/30
There has been a surprisingly small number of posts about these Paces. Or milestone is drifting into the barely-seeable past. More comments on the Paces, sooner rather than later, would be appreciated. --Paul Hoffman, Director --Internet Mail Consortium
Re: Spec wording bug?
At 1:43 PM +0200 10/14/05, Danny Ayers wrote: In draft-ietf-atompub-format-11 under 4.2.7 The atom:link Element, compare and contrast: [[ 4.2.7.4 The hreflang Attribute The hreflang attribute's content describes the language of the resource pointed to by the href attribute. ... 4.2.7.6 The length Attribute The length attribute indicates an advisory length of the linked content in octets; it is a hint about the content length of the representation returned when the IRI in the href attribute is mapped to a URI and dereferenced. ]] I believe the language of the resource for hreflang makes no sense - it will be the *representations* that are associated with languages, I think that's being way too picky. It makes sense that content (the generic term) might have a language associated with it. and the implies a single language - there may be more than one. That's true. And it matches the XML 1.0 spec exactly. --Paul Hoffman, Director --Internet Mail Consortium
On individual submissions for standards-track RFCs
At 8:21 AM -0700 9/26/05, James M Snell wrote: Over the past couple of weeks I've been working on a number of proposed Atom extensions that I am moving forward with as standards-track RFC's through individual submission. Thank you for asking for these unofficial last calls. This is a very good way to work the process. For the WG's benefit: The IETF is quite open to individually-submitted standards-track RFCs, particularly if they have been discussed in the open among those interested in the field. When James takes his Internet Drafts to the relevant IETF Area Director (that is, Scott Hollenbeck), James can point to the discussion threads on the mailing list, and Scott can use that to guage whether there has been enough discussion before taking the proposals to IETF-wide last call. Note that there is always an IETF-wide last call on standards-track documents such as this. Those are initiated by the relevant Area Director. At their conclusion, the AD decides what to do, and normally then takes the drafts plus a summary of the discussion to the IESG. One sad side-effect of this process is that, after the IESG approves the document to become a standards-track document, it will languish in the RFC Editor's queue for a very long time. Because the current RFC Editor has such a long backup, they normally tend to put WG-sponsored documents higher in the queue than individually-sponsored documents. Fortunately for us, we don't have to call the new standard by its RFC number, but instead by its extension name. Having said all that, please review any extension documents carefully and post your responses to the mailing list. This helps both the author and the IETF decide whether to make them standards. --Paul Hoffman, Director --Internet Mail Consortium
RE: Don't Aggregrate Me
At 10:22 AM -0400 8/25/05, Bob Wyman wrote: James M Snell wrote: Does the following work? feed ... x:aggregateno/x:aggregate /feed I think it is important to recognize that there are at least two kinds of aggregator. The most common is the desktop end-point aggregator that consumes feeds from various sources and then presents or processes them locally. The second kind of aggregator would be something like PubSub -- a channel intermediary that serves as an aggregating (and potentially caching) router that forwards messages on toward end-point aggregators. Your syntax seems only focused on the end-point aggregators. Without clarifying the expected behavior of intermediary aggregators, your proposal would tend to cause some significant confusion in the system. Should PubSub aggregate and/or route entries that come from feeds marked no-aggregate? If not, why not? From the publisher's point of view, an intermediary aggregator like PubSub should be indistinguishable from the channel itself. +1 to Bob's comments. I can see reasons why I would want my firmware updates aggregated through an intermediary. --Paul Hoffman, Director --Internet Mail Consortium
Re: geolocation in atom:author?
At 12:17 AM +1000 8/22/05, Eric Scheid wrote: In this example, can anything intelligent be said about the various different locations? Is my intent clear, or are there clear ambiguities? feed ... ... geo:coordslocation#1/geo:coords author namefoo/name geo:coordslocation#2/geo:coords /author entry author namefoo/name geo:coordslocation#3/geo:coords /author geo:coordslocation#4/geo:coords content.../content ... /entry /feed #2 through #4 seem understandable, but what the heck is #1? The place where this feed was put together? The place where this feed was originally grabbed from? --Paul Hoffman, Director --Internet Mail Consortium
Extensions at the feed level (Was: Re: geolocation in atom:author?)
At 7:24 PM +0100 8/21/05, Peter Robinson wrote: I do something similar, intending it to mean the location of the items described by this feed (when there is a single location). Ah, I had missed that. This leads to a question for the mailing list. Does an informative extension that appears at the feed level (as compared to in entries) indicate: a) this information pertains to each entry b) this information pertains to the feed itself c) this information pertains to each entry and to the feed itself d) completely unknown unless specified in the extension definition --Paul Hoffman, Director --Internet Mail Consortium
RE: Extensions at the feed level (Was: Re: geolocation in atom:author?)
At 5:10 PM -0400 8/21/05, Bob Wyman wrote: I believe the correct answer is e: e) Unless otherwise specified, this information pertains to the feed only. Er, right. Change that list to: a) this information pertains to each entry (unless otherwise specified) b) this information pertains to the feed itself (unless otherwise specified) c) this information pertains to each entry and to the feed itself (unless otherwise specified) d) completely unknown unless specified in the extension definition --Paul Hoffman, Director --Internet Mail Consortium
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
At 3:35 PM -0700 8/21/05, James M Snell wrote: IMHO, it depends entirely on how the extension is defined. The various extensions I have put together (e.g. comments, expires, etc), the metadata can be placed on the feed/source level but is only relevant on the entry level (same model as author /). One could easily imagine, however, that other extensions would apply only on the feed level. It's entirely up to the extension and implementors should make no assumptions. The crux of the question is: what happens when an extension that does not specify the scope appears at the feed level? --Paul Hoffman, Director --Internet Mail Consortium
Finishing up on whitespace in IRIs and dates
Greetings again. I think we have rough consensus on emitting with whitespace around IRIs and dates is an error and we should warn folks that people might emit errors here because this is somewhat subtle. If that is true, I propose that, just before section 3.1 (at the end of the introductory text to Common Atom Constructs) we add: Note that there MUST be no whitespace in a Date construct or in any IRI. Some XML-emitting implementations erroneously insert whitespace around values by default, and such implementations will emit invalid Atom. --Paul Hoffman, Director --Internet Mail Consortium
Re: spec bug: can we fix for draft-11?
At 7:37 PM -0400 8/2/05, Robert Sayre wrote: One way of saying this would be Atom Processors MAY ignore leading and trailing whitespace in _. That works for me. Another idea is Atom Processors MAY ignore leading and/or trailing whitespace in elements whose content does not allow leading and/or trailing whitespace, such as IRIs and . --Paul Hoffman, Director --Internet Mail Consortium
Re: spec bug: can we fix for draft-11?
At 11:43 AM +0100 8/4/05, Bill de hÓra wrote: Paul Hoffman wrote: At 7:37 PM -0400 8/2/05, Robert Sayre wrote: One way of saying this would be Atom Processors MAY ignore leading and trailing whitespace in _. That works for me. Another idea is Atom Processors MAY ignore leading and/or trailing whitespace in elements whose content does not allow leading and/or trailing whitespace, such as IRIs and . I don't understand the benefits of MAY. It sounds like this to me: whitespace is not allowed in certain elements, but you may ignore that directive by trimming the content. Exactly: that's the MAY. --Paul Hoffman, Director --Internet Mail Consortium
Re: spec bug: can we fix for draft-11?
At 2:42 PM +0200 8/4/05, Bjoern Hoehrmann wrote: * Tim Bray wrote: Implementors are advised that there is a common class of error in [...] Sorry but this is ridiculous; if we say X MUST Y even though we know that many X won't Y we are abusing RFC 2119 terminology and make it much more difficult to evangelize 100% compliance, since this allows people to argue that compliance with this particular requirement is not relevant in practise so they can worry less about compliance in general. You can't compare an IRI with a non-IRI. So, if you are handed an non-IRI (as in, an IRI-looking string that has whitespace around it), should you fail immediately or try harder? I propose trying harder, but I am open to just fail. --Paul Hoffman, Director --Internet Mail Consortium
Re: Comments Extension: IANA Registration or Not?
At 9:45 AM -0700 7/28/05, James M Snell wrote: For the comments extension, I can write the Internet Draft such that the link rels are registered with IANA or are identified by fully qualified URI's. What is the general preference of the group? I'd prefer IANA registration but that carries an obvious level of overhead. IANA registration gives you the advantage that the identifier used can be easily tied to some long-lived description of what it means. The disadvantage is the overhead of registration. Using a URI that is expected to, when resolved, describe what it means is a reasonable way to do things even if the resolution breaks at some point, as long as there is a longer-lived source of a copy of what the description was. --Paul Hoffman, Director --Internet Mail Consortium
Re: Media extensions
At 8:58 PM -0400 7/16/05, Robert Sayre wrote: I hesitate to put a number on it, but our experience included a ghastly amount of debate on field names. If I were setting up a WG for something like Media RSS, I would probably rule debate on field names out of order (realizing that people have to pick something to propose a *new* feature), and leave field names up to the editors until WG last call. We don't need a new WG: it could possibly be done in this WG if there is interest in updating the charter and willingness from Scott Hollenbeck. co-chair-hat position='on'I would only entertain a charter extension if we had a volunteer to be the document author, and expressed interest from developers. This will certainly be contentious./co-chair-hat Alternatively, someone can write an individual Internet Draft that is just discussed on this list, with no rules about how changes are made to the draft. This is definitely lighter-weight, but much more likely to bring bad feelings and lack of consensus unless the draft authors are really good at listening. Still, it is easy to do. --Paul Hoffman, Director --Internet Mail Consortium
Re: The Atom namespace, etc.
At 9:23 PM +0200 7/14/05, Bjoern Hoehrmann wrote: Hi, http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-10.txt defines http://www.w3.org/2005/Atom; as namespace for the Atom format. Is this really a good choice considering that most of the similar W3C namespaces use different casing, e.g. http://www.w3.org/1999/xhtml http://www.w3.org/1999/xlink http://www.w3.org/2000/svg http://www.w3.org/2001/vxml http://www.w3.org/2001/xml-events http://www.w3.org/2002/xforms http://www.w3.org/2004/xbl ... Though I guess it's to late now to change this... It is indeed. Given that only developers will be typing this in, and they will probably be copying-and-pasting, this seems like a really minor issue, not worth delaying over. At 9:37 PM +0200 7/14/05, Bjoern Hoehrmann wrote: I think it would be helpful if section 8 (Security Considerations) of the latest draft includes a reference to section 5 Securing Atom Documents. This is rarely done in RFCs. Further, Section 5 is clearly listed in the table of contents, and someone who intends to implement the protocol probably has at least skimmed the document before they read the details in the Security Considerations section. And, the two Security Area Directors have signed off on the Security Considerations section in -10. --Paul Hoffman, Director --Internet Mail Consortium
Request for review: language tags
[[ Be sure to send comments to the list below, not to the Atompub WG list. ]] From: Randy Presuhn [EMAIL PROTECTED] To: Working Group Chairs [EMAIL PROTECTED] Date: Thu, 14 Jul 2005 16:42:54 -0700 Hi - Language tags are used in many applications and protocols, so we'd like to get as broad a review as practical of these: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-09.txt http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt The former would replace RFC 3066 (a BCP), the later would become an informational RFC. The ltru working group last call on these concludes July 28. If you or people in your WG read either of these, we'd like to hear from you. Post to [EMAIL PROTECTED], even if all you have to say is I've read it and don't have any specific comments on it. Randy
Re: Major backtracking on canonicalization
At 2:25 PM -0400 7/11/05, Karl Dubost wrote: I read Just as with [XML-C14N] one may use the #WithComments parameter to include the serialization of XML comments. So it's a MAY, but it doesn't say that when the parameter is not here that there's a MUST NOT include them. H, that's not how I read it at all. Given that we are talking about a canonicalization spec that has to say exactly what is and is not in the converted, I would find it surprising to have something that means this may or may not appear in the output, you don't know. ok, so it's not really a default feature/behaviour but it seems something like a flag that you have to give. Agree. --Paul Hoffman, Director --Internet Mail Consortium
Re: Major backtracking on canonicalization
At 10:23 AM -0400 7/7/05, Mark Nottingham wrote: Are we specifying exclusive c14n with or without comments? My preference would be without. Without. That is explicitly the default for http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/. As I understand it, inherited xml:lang and xml:base attributes aren't signed when you're using exclusive c14n. If we ended up allowing per-entry signatures, we need to give guidance that xml:lang and xml:base should be explicitly included in the signed content if they are important. Why? We are signing bags of bits. Why add those from the outside? It may be helpful to give guidance about the usage of the InclusiveNamespaces PrefixList, especially with default namespaces. The whole purpose of using exclusive XML is to not need to guess about what is and is not in the bag of bits being hashed. --Paul Hoffman, Director --Internet Mail Consortium
Re: Major backtracking on canonicalization
At 1:56 PM -0400 7/7/05, Mark Nottingham wrote: On 07/07/2005, at 11:36 AM, Paul Hoffman wrote: At 10:23 AM -0400 7/7/05, Mark Nottingham wrote: Are we specifying exclusive c14n with or without comments? My preference would be without. Without. That is explicitly the default for http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/. Where does it state that explicitly? Just as with [XML-C14N] one may use the #WithComments parameter to include the serialization of XML comments. Meaning: if you don't include #WithComment, you don't get comments. There are two identifiers in section four; it would be best to reference the spec and the applicable identifier by name. Works for me: http://www.w3.org/2001/10/xml-exc-c14n# Imagine that you sign an entry that relies on an feed-level xml:base of http://www.example.com/;. There are zillions of external things that might affect the *interpretation* of what is signed. We saw that in the discussion of signing entries with external references. We are signing the bits only, not some interpretation of the bits. That is true for the xml:base, the xml:lang, the xml:something-else, and so on. I have no problem with the implementer's guide (or the signing-and-encrypting guide, if it happens) to talk about the dangers of interpreting things not covered by the signature, but if we start a list in the base spec, readers will assume that the list is exhaustive. We can easily tell now that it won't be. --Paul Hoffman, Director --Internet Mail Consortium
Re: Roll-up of proposed changes to atompub-format section 5
At 9:41 PM -0700 7/4/05, Tim Bray wrote: On Jul 4, 2005, at 7:38 PM, Bob Wyman wrote: I believe it would be very useful to specify that signed entries should include a source element. This can/should be considered part of entry canonicalization. -1. Leave it to the market. I suspect that you're right, but I'd be unsurprised if an application for signed un-sourced applications turned up. -Tim I'm with Tim on the -1. Bob's suggestion and explanation make good sense for the implementer's guide, but not for the base spec. There is not an interoperability issue that I can see for entries without sources being signed. --Paul Hoffman, Director --Internet Mail Consortium
Re: Roll-up of proposed changes to atompub-format section 5
At 9:16 AM -0700 7/5/05, James M Snell wrote: Are we going to be making the change specified in point 1 of [1] ? That is, specifically allow for Signature on any atom:entry element? Yipes! Good catch. That was my mistake. I rolled-up from one thread, not both of them. The beginning of 5.1 in the roll-up should have read: 5.1 Digital Signatures [[ CHANGED ]] The root of an Atom document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry Document), or any atom:entry element, MAY have an Enveloped Signature, as described by XML-Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212]. --Paul Hoffman, Director --Internet Mail Consortium
RE: Roll-up of proposed changes to atompub-format section 5
At 2:24 PM -0400 7/5/05, Bob Wyman wrote: I find it hard to imagine what harm could be done by providing this recommendation. Timing. If we change text other than because of an IESG note, there is a strong chance we will have to delay being finalized by two weeks, possibly more. --Paul Hoffman, Director --Internet Mail Consortium
Re: Roll-up of proposed changes to atompub-format section 5
OK, I'm backing off of my statement that it is too late to deal with this. Thank you to the people who pointed out that this is directly related to Russ' concern about interop of canonicalization. You are right, and I was being too narrow-minded. Does anyone object to the following exact wording being added right after the new paragraph on canonicalizing: Intermediaries such as aggregators may need to add an atom:source element to an entry that does not contain its own atom:source element. If such an entry was signed, the addition will break the signature. Thus, a publisher of individually-signed entries should strongly consider adding an atom:source element to those entries before signing them. --Paul Hoffman, Director --Internet Mail Consortium
Roll-up of proposed changes to atompub-format section 5
Greetings again. The clearing a discuss thread has been productive, but the proposed wording has changed a few times. Here is what I suggest is good final wording that covers the issues brought up. Comments are welcome. 5. Securing Atom Documents Because Atom is an XML-based format, existing XML security mechanisms can be used to secure its content. [[ NEW ]] Producers of feeds and/or entries, and intermediaries who aggregate feeds and/or entries, may have sound business reasons for signing and/or encrypting otherwise-unprotected content. For example, a merchant might digitally sign a message that contains a discount coupon for its products. A bank that uses Atom to deliver customer statements is very likely to want to sign and encrypt those messages to protect their customers' financial information and to assure the customer of their authenticity. Intermediaries may want to encrypt aggregated feeds so that a passive observer cannot tell what topics the recipient is interested in. Of course, many other examples exist as well. [[ NEW ]] The algorithm requirements in this section pertain to the Atom Processor. They require that a recipient, at a minimum, be able to handle messages that use the specified cryptographic algorithms. This does not limit the algorithms that the sender can choose: it only says that the sender can only assume the recipient can use the named algorithms unless they have other out-of-band knowledge. 5.1 Digital Signatures The root of an Atom document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry Document) MAY have an Enveloped Signature, as described by XML-Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212]. Atom Processors MUST NOT reject an Atom Document containing such a signature because they are not capable of verifying it; they MUST continue processing and MAY inform the user of their failure to validate the signature. In other words, the presence of an element with the namespace URI http://www.w3.org/2000/09/xmldsig#; and a local name of Signature as a child of the document element MUST NOT cause an Atom Processor to fail merely because of its presence. Other elements in an Atom Document MUST NOT be signed unless their definitions explicitly specify such a capability. [[ NEW ]] Section 6.5.1 of [W3C.REC-xmldsig-core-20020212] requires support for Canonical XML. Atom Processors that verify signed Atom Documents MUST be able to canonicalize with Canonical XML. [[ NEW ]] Section 4.4.2 of [W3C.REC-xmldsig-core-20020212] requires support for DSA signatures and recommends support for RSA signatures. However, because of the much greater popularity in the market of RSA versus DSA, Atom Processors that verify signed Atom Documents MUST be able to verify RSA signatures, but do not need be able to verify DSA signatures. Due to security issues that can arise if the keying material for MAC authentication is not handled properly, Atom documents SHOULD NOT use MACs for signatures. 5.2 Encryption The root of an Atom Document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry Document) MAY be encrypted, using the mechanisms described by XML Encryption Syntax and Processing [W3C.REC-xmlenc-core-20021210]. [[ NEW ]] Section 5.1 of [W3C.REC-xmlenc-core-20021210] requires support of TripleDES, AES-128, and AES-256. Atom Processors that decrypt Atom Documents MUST be able to decrypt with AES-128 in CBC mode. [[ NEW ]] Encryption based on [W3C.REC-xmlenc-core-20021210] does not assure integrity of the original document. There are known cryptographic attacks where someone who cannot decrypt a message can still change bits in a way where part or all the decrypted message makes sense but has a different meaning. Thus, Atom Processors that decrypt Atom Documents SHOULD check the integrity of the decrypted document by verifying the hash in the signature (if any) in the document, or by verifying a hash of the document within the document (if any). [[ NEW ]] 5.3 Signing and Encrypting [[ NEW ]] When an Atom Document is to be both signed and encrypted, it is generally a good idea to first sign the document, then encrypt the signed document. This provides integrity to the base document while encrypting all the information, including the identity of the entity that signed the document. Note that, if MACs are used for authentication, the order MUST be that the signed document is encrypted, and not the other way around. --Paul Hoffman, Director --Internet Mail Consortium
Re: Clearing a discuss vote on the Atom format
At 4:44 PM +0900 7/1/05, Martin Duerst wrote: At 10:26 05/07/01, Paul Hoffman wrote: To be added near the end of Section 5.1 of atompub-format: Section 6.5.1 of [W3C.REC-xmldsig-core-20020212] requires support for Canonical XML. Atom Processors that sign Atom Documents MUST use Canonical XML. The rest of your changes looked reasonable, but the MUST above looks too strong to me. Good catch. I think we can make the requirement for canonicalization like we do for encryption and signing: put the onus on the receiver. That would change the wording to: Atom Processors that verify signed Atom Documents MUST be able to canonicalize with Canonical XML. --Paul Hoffman, Director --Internet Mail Consortium
Re: Clearing a discuss vote on the Atom format
At 1:45 PM -0700 7/1/05, James M Snell wrote: Paul Hoffman wrote: Unfortunately, the complexity of XML and the variety of contexts in which it is used made it impossible for the XMLDSIG WG to come up with one set of canonicalization rules that are distinguished. By distinguished, I mean that there is exactly one way to represent the XML object. There are two canonicalization rule sets: the Canonical XML and the Exclusive XML Canonicalization. Specify which one is mandatory-to-implement. Section 5 does not provide sufficient detail for interoperability. To be added near the end of Section 5.1 of atompub-format: Section 6.5.1 of [W3C.REC-xmldsig-core-20020212] requires support for Canonical XML. Atom Processors that sign Atom Documents MUST use Canonical XML. Does this requirement restrict our ability to use exclusive c14n on individually signed entries within a feed document? No and no. My new proposed wording is: Atom Processors that verify signed Atom Documents MUST be able to canonicalize with Canonical XML. That requires that a recipient, at a minimum, be able to handle messages that are canonicalized with Canonical XML. It does not limit the kinds of canonicalization that the sender can choose: it only says that the sender can only assume the recipient can do Canonical XML unless they have other out-of-band knowledge. --Paul Hoffman, Director --Internet Mail Consortium
Re: More on Atom XML signatures and encryption
At 3:16 PM -0600 6/30/05, Antone Roundy wrote: On Thursday, June 30, 2005, at 12:58 PM, James M Snell wrote: 6. If an entry contains any enclosure links, the digital signature SHOULD cover the referenced resources. Enclosure links that are not covered are considered untrusted and pose a potential security risk Fully disagree. We are signing the bits in the document, not the outside. There is security risk, those items are simply unsigned. I tend to consider enclosures to be part of the document, even if they are included by reference. As a potential consumer of an enclosure I want to know whether or not the referenced enclosure can be trusted. Is it accepted to change the SHOULD to a MAY with a caveat outlining the security risk? Perhaps a good approach would be for the signed entry to contain a separate signature for the enclosure--so the entry's signature would cover the bits in the enclosure's signature, but not the bits in the enclosure itself. That way, the signature for the entry could be verified without having to fetch the enclosure. Where would that signature go? Did we decide that link doesn't have to be empty? If so, that might be a good place...but then I don't have any experience with signed XML, so I don't know whether there would be technical difficulties with putting it in any particular place. This is possible. It translates to I say that the bits gotten from here have a hash of value. If the hash doesn't match, you can't assume anything about the bits; if it does, the other semantic data in the message can apply to them (...and it is a picture of me, ...and it is a program that will delete your data...). --Paul Hoffman, Director --Internet Mail Consortium
Re: More on Atom XML signatures and encryption
(e.g. binary enclosures, scripts, etc) How will you assert that? Not so much a normative assertion. More of a if you know who produced this feed/entry and you decide that you can trust their signature, you can make finer grained decisions about whether or not to trust the content. Not unless you can define trust the content. All you can trust is that it is part of the assertion made by the semantic content of the signed message. That might be I saw this program, it might be I wrote this program, it might be this program erased my hard drive, and so on. I think you were suggesting that signatures over active content could be automatically parsed to mean something; that's not OK without a lot of additional words and a different type of signature. Suggestion (and only a suggestion): don't go there. --Paul Hoffman, Director --Internet Mail Consortium
Re: More on Atom XML signatures and encryption
At 12:47 PM -0700 6/29/05, James M Snell wrote: 1. After going through a bunch of potential XML encryption use cases, it really doesn't seem to make any sense at all to use XML Encryption below the document element level. The I-D will not cover anything about encryption of Atom documents as there are really no special considerations that are specific to Atom. Good. 2. The I-D will allow a KeyInfo element to included as a child of the atom:feed, atom:entry and atom:source elements. These will be used to identify the signing key. (e.g. the KeyInfo in the Signature can reference another KeyInfo contained elsewhere in the Feed). This is OK from a security standpoint, but why have it? Why not always have the signature contain all the validating information? 3. When signing complete Atom documents (atom:feed and top level atom:entry), Inclusive Canonicalization with no pre-c14n normalization is required. There seems to be many more interoperability issues with Inclusive Canonicalization than with Exclusive. What is your reasoning here? 4. The signature should cover the signing key. (e.g. if a x509 cert stored externally from the feed is used, the Signature should reference and cover that x509 cert). Failing to do so opens up a security risk. Please explain the security risk. I probably disagree with this requirement, but want to hear your risk analysis. 5. When signing individual atom:entry elements within a feed, Exclusive Canonicalization MUST be used. If a separate KeyInfo is used to identify the signing key, it MUST be contained as either a child of the entry or source elements. A source element SHOULD be included in the entry. Why is this different than #3? 6. If an entry contains any enclosure links, the digital signature SHOULD cover the referenced resources. Enclosure links that are not covered are considered untrusted and pose a potential security risk Fully disagree. We are signing the bits in the document, not the outside. There is security risk, those items are simply unsigned. 7. If an entry contains a content element that uses @src, the digital signature MUST cover the referenced resource. Fully disagree. 8. Aggregators and Intermediaries MUST NOT alter/augment the content of digitally signed entry elements. Also disagree, but for a different reason. Aggregators and intermediaries should be free to diddle bits if they strip the signatures that they have broken. 9. In addition to serving as a message authenticator, the Signature may be used by implementations to assert that potentially untrustworthy content within a feed can be trusted (e.g. binary enclosures, scripts, etc) How will you assert that? 10. The I-D will not introduce any new elements or attributes Thank you! 11. Certain types of [X]HTML content will be forbidden in unsigned feeds. e.g. frameset, frame, script, link, style, object, embed, meta, etc. Even in feeds signed with trusted keys, aggregators should handle these with care. (ref: http://diveintomark.org/archives/2003/06/12/how_to_consume_rss_safely). Disagree, for the same reasons as above. We are signing the bits only, not some representation of the universe at the time of signing. Like I said, I'll be trying to have the draft put together by this weekend. Hopefully, my comments above cause you to put discussion of your reasoning in there. Please don't read my comments as don't do this, but rather if you're going to do this, you have to justify it. That will make the document stronger and more likely to be implemented properly. --Paul Hoffman, Director --Internet Mail Consortium
Re: The atom:uri element
At 1:42 PM +0200 6/27/05, Asbjørn Ulsberg wrote: I guess we won't be nuking the atom:uri element before Atom goes gold? Correct. --Paul Hoffman, Director --Internet Mail Consortium
Re: The atom:uri element
At 12:46 PM -0700 6/27/05, James Cerra wrote: If there isn't enough time to change it Again: there isn't. The spec is in front of the IESG for consideration, and it has been for many weeks now. (although I think there is enough time left) Could you explain that? Are you proposing that we pull the spec back from the IESG, make this change, and then ask them to look again? Or something else I'm missing? --Paul Hoffman, Director --Internet Mail Consortium
IESG defers discussion of the format document for two weeks
Greetings again. So, it turns out that the IESG won't consider the Atom format document today, as we had hoped. As you can see at https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=11964rfc_flag=0, one of the Security Area Directors, Russ Housley, put a defer vote in. Procedurally, this means that he wants to wait for another telechat in order to think more about the document. Defer votes aren't common but aren't rare, and they can mean anything. And, a document can only be deferred once (that is, the IESG cannot use defer votes to keep ignoring a draft). As you can also see from the ID tracker, we have a bunch of no objection votes and a couple of discuss votes. We need to clear all the discuss votes before we are accepted as a standard, but so far, these are all reasonable things that RobJoe can do in the -10 draft. Other IESG members may have other discuss votes later on, and those can be more difficult, but we'll see when it happens. In other words, this isn't bad news, just a delay. Tim and I have already opened a line of communications with Russ and Sam about security issues, so if they want to ask questions or probe further before voting, they can. Stay tuned, and it won't be that long until we know for sure. --Paul Hoffman, Director --Internet Mail Consortium
Re: IESG defers discussion of the format document for two weeks
In my previous post, I said RobJoe when I should have said Rob and Mark. Also, I said Russ and Sam when I should have said the two Security Area Directors, Russ Housley and Sam Hartman (that is, not our WG secretary, Sam Ruby). Also, I agree with Tim that waiting two weeks unnecessarily is a bummer for anxious implementers. I guess I'm just used to much worse things happening in the IESG in the past, like really long delays. --Paul Hoffman, Director --Internet Mail Consortium
Re: Signature wording
At 10:32 AM -0700 6/22/05, James M Snell wrote: Paul Hoffman wrote: 2) What you are signing is just the set of bits in the entry, or just the set of bits in the feed, with no interpretation of them. No pre-canonicalization is needed, and none is to be expected by the validating party. I truly don't believe that any change is needed to the format document to reflect this. There is nothing in section 5 that the signature is over the bits plus everything relevant at the time of the signature. Bear in mind that because of the compulsory presence of atom:id and atom:updated in every entry, some of the benefits of canonicalization (reducing ambiguity in comparisons) are not material. Hmm... not sure about this one. We've already demonstrated via several examples that things like XML namespaces and the lack of a source element can cause problems in aggregator scenarios and that some form of atom-specific canonicalization may be required. I don't feel like you have demonstrated that. You have demonstrated that an aggregator might need to change some signed entries when they aggregate: that will inherently break the signature, and the aggregator will need to sign the entry themselves. But that's part of the aggregator's business model, not the Atom model. We found this entry, we cleaned it up so you can use it, and we sign this set of bits so you know it is exactly what we emitted. If they want, they can also include the signed-and-unchanged original. Can you expand a bit on your assertion with a few examples? Some angle brackets would really help me understand exactly where you're coming from. But that's exactly the point: no angle brackets are needed to understand the set of bits in the entry. The signature is over the exact characters being signed, not some understanding of them based on namespaces, source elements, and so on. That's the difference between bits and bits plus everything relevant at the time of the signature. --Paul Hoffman, Director --Internet Mail Consortium
Re: Signature wording
At 11:49 AM -0600 6/22/05, Antone Roundy wrote: I take it, Paul, that you're suggesting that we punt on ensuring that entries can be aggregated without breaking signatures. Exactly right. If so, we might consider suggesting some guidelines for maximizing the probability of a signature remaining valid, such as including a source element in each signed entry, using the most commonly used namespace prefixes for any namespaces used in the entry, and using UTF-8 (or whatever is most common for the language the feed is published in). Someone might want to work on a document that advises (not mandates) a way to canonicalize the heck out of an entry to reduce the likelihood that an aggregator would want to change any bits in the entry, regardless of whether or not the entry is signed. We cannot tell aggregators that they cannot change bits in an signed entry: they might choose to do so even though it would break the signature because the bits they are changing are more important than the signature. For example, the aggregator may know the end recipient can't validate the signature anyway, or the aggregator may know that the signature was broken before they got the entry. Such a document would probably be useful, or it might just be a useful entry in the implementer's guide. Getting input from some currently-active aggregators would be really useful for that, of course. --Paul Hoffman, Director --Internet Mail Consortium
Re: Polling Sucks! (was RE: Atom feed synchronization)
At 10:06 PM -0400 6/17/05, Sam Ruby wrote: P.S. Why is this on atom-sytax? Is there a concrete proposal we are talking about here? Is there likely to be? Wearing my co-chair hat: IETF WG mailing lists are normally used for creating specs that are listed in the charter. They are also used for general discussion on the topic of the WG, even if that general discussion is not covered in the charter. The latter is perfectly proper if it does not interfere with the former. This WG is now in a waiting state on the format draft, and is actively discussing the protocol draft on a different mailing list ([EMAIL PROTECTED]). Thus, discussions of things related to the use of the Atom format is fine on this list as long as it doesn't get out of hand, for some very vague definition of out of hand. Discussions that might lead to individual (non-WG) submissions of Internet Drafts are expressly encouraged at this time. That is not to say let's start adding a bunch of needless extensions and provisions, but certainly I see a need and I think I might propose a solution is a Very Good Thing for this list. --Paul Hoffman, Director --Internet Mail Consortium
Timing guide for Atom implementers
Greetings again. Some people have started asking (mostly off-list) when the Atom format would be done so they can implement and, more importantly, deploy. This message gives our best shot at answering the question. The status of the format document is that the -09 draft is in the IESG evaluation queue. This means that the IESG will consider it soon. In fact, it has been scheduled for their telechat next Thursday. (There are many documents scheduled; see http://www.ietf.org/IESG/agenda.html.) The IESG members are now reading the document in preparation for the telechat, and they may (or may not) be discussing it among themselves. Next Thursday, the IESG might [a] say this is fine as it is, no changes needed. It is much more likely that they will [b] say this will be OK after you make the following changes in the -10 draft and they will list a handful of changes that range from editorial nits to adding clarifications. There is a real chance they will [c] say This has some real technical deficiencies, please revise this and show us -10 before we make a final decision. If [a] or [b]: Because there are no technical changes requested to the document, implementers can get ready to deploy. The only significant change that will appear in -10 will be that the final Atom 1.0 namespace will be included. Tim is responsible for getting that minted, but we won't do so until we are sure that there is a technically-stable document; we don't expect the namespace creation to take much time. As soon as the namespace is minted, we'll tell the WG. (There will be other changes in -10, such as the last editorial nits, and the addition of the longer acknowledgements list. In fact, even if [a] happens, there will be a -10.) Also, after -10 is published as an Internet Draft, Scott Hollenbeck will remove the last hold on it and it will become an IETF Proposed Standard. Note that it is really a standard at that moment, *not* when it gets published as an RFC (which will be 3 or 4 months later sigh). Implementers can start shipping as soon as it is a standard, and not wait for the RFC. If [c]: However, in the case of [c], implementers should put their development on hold. If the IESG asks for a technical change, it will take at least a few weeks for the Atom WG to reply either with the change or with a stack of solid arguments why our original text was, in fact, correct. In the latter case, the IESG will probably take at least a few weeks to agree with us, or for them to say no, we really meant it. There could be multiple rounds, so the -10 might not be final. Summary: The -09 draft of the format cannot be considered final and deployable. The IESG may ask/demand changes in it before it becomes a standard, and we will not give it a final namespace until the IESG says that it won't be changed. At that time, we will quickly get a nice namespace minted, and tell the WG what it is. There is a real chance that the document will be a standard two weeks from now; there is a real chance it will take a few months. If all this IETF process stuff is confusing, reading the Tao of the IETF (http://www.ietf.org/tao.html) might help. Also, there is a link to the IETF status of the document on the wiki (http://www.intertwingly.net/wiki/pie/FrontPage). --Paul Hoffman, Director --Internet Mail Consortium
Re: Acknowledgements in the format draft
This is a second call for people who would like to be listed in the acknowledgements. There are a number of you who contributed greatly to this effort who didn't respond to my first request, and it seems almost silly to not have those people listed. We will add the acknowledgements list in Appendix A after the IESG review. Please respond to me off-list. Thanks! At 1:23 PM -0700 5/19/05, Paul Hoffman wrote: Greetings again. The nearly-nearly-complete format draft has a short list of contributors in Appendix A. This WG has been phenomenally active, and much of that activity is reflected in the specific text in the document. Wearing my co-chair hat, I can think of at least a dozen more people who should be listed in Appendix A because they helped shape the final output. Having said that, some people who have actively contributed to the spec may not want their names listed. If you would like to be listed in Appendix A because you have helped create the format document, please drop me a note. It is unlikely that we will get this into the next draft, but we have another shot after the IESG review, and I can't imagine that the IESG will mind adding more to this section. --Paul Hoffman, Director --Internet Mail Consortium --Paul Hoffman, Director --Internet Mail Consortium
draft-ietf-atompub-format-09.txt is ready for IESG review
Greetings again. As the shepherd for this document, I would like to ask you to bring it to the IESG for final review. The WG has worked hard on this document after IETF Last Call, and made many changes that incorporate the WG rough consensus on issues that were brought up during and after IETF Last Call. Some members of the Working Group remain unenthusiastic about some sections of the document, but we strongly believe that there is rough (or better) consensus in support of the document as a whole. For some of the parts with the most contention, there cannot be more than very rough consensus due to basic differences in the way people would design parts of the format, particularly given that we have many models in existence with the different flavors of RSS. For some parts of the document, there is contention about whether or not a particular item should or should not be in the Atom core versus being an extension. For some parts, there is contention whether there should be MUST/SHOULD/MAY leeway for content creators in the presence or absence of an element, or the semantic content of an element; we really pushed RFC 2119 around during the past few months. The length of the mailing list archive is anomalous in the IETF, but so is the large number of regular active contributors and the breadth of parts of the document to which they contributed. This huge amount of input has caused the document to be more seriously reviewed, by more eyes, than a typical IETF document, but it has also caused more opportunity for disagreement along the way. Yet we still ended up with a format that meets the goals of the charter and the general agreement of most of the participants in the Working Group. Please let us know how if the IESG has any concerns with the document during their review. --Paul Hoffman, Director --Internet Mail Consortium
Re: Review of Section 6
At 12:31 AM +0100 6/10/05, David Powell wrote: Thursday, June 9, 2005, 5:51:57 PM, Tim Bray wrote: On the other hand, a general re-organization of section 6 is right out; it is our finding that the format-09 draft (modulo errors) reflects the rough consensus of the WG. If you disagree, the IETF provides appeal procedures. Last week I thought about how to rework Section 6. Wearing my co-chair hat: we have no opportunity to rework any section of the document unless the IESG asks us to. If we find technical errors, we will of course fix them. If you think that Tim and I have made administrative errors in preventing this reorganization, you can appeal that decision. Although some of this reworking might be not acceptable now, *All* reworking is not acceptable now. I'll post it anyway. It might be that there are some actual ambiguities in the current draft; if so, then I guess that ambiguities might be considered to be bugs, that still need fixing. There is a large difference between suggesting a bunch of reworking and pointing out specific ambiguities. Please do the latter if you find them. --Paul Hoffman, Director --Internet Mail Consortium
Re: atom, xslt processors (Re: atom:type, xsl:output)
At 4:54 PM +0200 5/30/05, A. Pagaltzis wrote: Atom is a transport envelope for potentially a multitude of documents. Saying that the enveloped documents should be preprocessed before they are unfolded from the envelope is like saying that a part of a multipart/mime document which has a Content-Encoding: gzip header should be uncompressed in situ *before* it is extracted from the multipart envelope. That doesn't make any sense. +1 --Paul Hoffman, Director --Internet Mail Consortium
Re: [Fwd: Re: Signatures - I blog, therefore I am...]
At 3:07 PM -0600 5/27/05, The Purple Streak, Hilarie Orman wrote: The Key Info is part of the XMLDigSig, but it is not required. Because it tells you where and how to obtain the pertinent certificate, it could be a boon for this particular application. There is no need to keep the signer secret, so I'd think it should be required. This is the kind of thing we can do in the implementer's guidelines. It doesn't solve the chain-of-trust problem, though. Nothing does :-) . Or is that :-( ? --Paul Hoffman, Director --Internet Mail Consortium
Re: [Fwd: Re: Signatures - I blog, therefore I am...]
At 12:57 PM -0600 5/27/05, The Purple Streak, Hilarie Orman wrote: Do you intend to require Keyinfo in the Signature element? Any requirements on that? In the base format spec, we are simply relying on XMLDigSig. If that turns out to be insufficient, we'll certainly add advice about what signed feeds and entries should do. --Paul Hoffman, Director --Internet Mail Consortium
Re: Signatures - I blog, therefore I am...
At 7:16 PM -0400 5/26/05, Bob Wyman wrote: The only mechanism that we would need in order to allow feeds to sign their content would be a means to associate a signing key with a feed or set of feeds. This could be done in one of two ways: * The traditional indirect manner of having a certificate authority create a certificate for someone once they prove administrative control over a feed. * The much simpler method of the feed including an extension element that identifies its signing keys -- it could either point to a file or to a key server. Much simpler, but completely insecure. :-) It's a self-signed attestation that has to be verified by out-of-band means that, from a security standpoint, are equivalent to the first if done right and horribly dangerous if done wrong. Having said that, I support the latter more than the former, and believe that 90% of signed feeds that people actually use will follow that model. The second method above has the downside that one would either have to be familiar with the feed and thus have memory of its statements concerning keys or one would have to fetch the feed as part of the signature verification process. However, the fact that the second method dispenses with the need for a certificate authority may make it appear quite appealing... Also, the second method allows one to do things like replace, expire, and cancel keys simply by changing the associations in the feed. And, to do any of those securely, you need to do the same things you did to get the keys in the first place, using the same security mechanism. One of the really interesting side-effects of having feeds, not people, be the owners of keys... Wait, stop. There is no such thing as an owner of a key. There are things that control the private key of a key pair. That is *always* a computer of some sort, and that computer is *always* controllable by at least one person. If you're careful/lucky, everyone who has access to the private key is someone who should have access. It is much better to say ..having feeds, not people, be associated with keys That is, the identifier that is associated with the key is a URI of the feed, not a person or company name. is that we might then find that it makes sense to allow feeds to issue certificates to their owners. (Yes, I know that this probably sounds odd...) Basically, the idea is that instead of giving keys to a person and then doing things to associate the feed with the person, we might turn things around and give keys to the feed and then associate the person with the feed. An intriguing aspect of doing this is that any measures of the authority of the feed could be passed on to the owner of the feed. Your personal authority, popularity, identity, etc. might be derived from your feed... So, instead of having to go through the sometimes great nuisance of presenting birth certificates, SSNs, and other evidence of personhood to a certificate authority, we could simply assert our personal existence by linking to the blogs we own... I blog, therefore I am. Stated another way, the anchor of the key hierarchy is identified by the URI of a feed, and the leaves might be identified by human names. A different method would be to have multiple identities associated with keys. My key might be identified with Paul Hoffman and http://lookit.proper.com; and http://saladwithsteve.com/osx/; and so on. Another interesting question would be what is that role of intermediaries like PubSub or search engines in signing things? Some such services might be trusted when they make statements like I found this entry in the feed identified in the source element. If this is the case, there could be value in having such trusted services sign the entries that that pass on. Then, if you found a copy of an entry that carried such a signature, you could have just as much faith in its correctness as if you had retrieved the entry directly from the intermediary rather than from someone who had copied it from the intermediary. Exactly right. Intermediary validation is what drives security folks crazy (witness the more-than-five-year history of SCVP in the PKIX WG), but it is exactly what most people use every day. There are a number of interesting possibilities here +1 --Paul Hoffman, Director --Internet Mail Consortium
Re: ByLines, NewsML and interop with other syndication formats
At 2:38 PM -0400 5/25/05, Bob Wyman wrote: I'd like to suggest that we explicitly invite the IPTC folk to propose a set of Atom extensions (that would include ByLine) with the intention that these extensions would incorporate their detailed knowledge of the publishing world and facilitate the interchange or translation of documents between NewsML, NITF, etc. formats and Atom. The IETF can't formally do this, but wearing my co-chair hat I'll happily +1 that. --Paul Hoffman, Director --Internet Mail Consortium
Re: extension elements inside link elements?
At 6:22 PM +1000 5/24/05, Eric Scheid wrote: 4.2.9 The atom:link Element The atom:link element is an empty element that defines a reference from an entry or feed to a Web resource. did we want to prevent expressions like this: link href=.. type=.. rel=.. title=.. ext:foo .../ /link I read empty as always empty, so the XML novice in me would say that the above expression in inherently wrong. --Paul Hoffman, Director --Internet Mail Consortium
Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines
I am completely unclear why this discussion is going on. Is there a desire on the part of the W3C to take the Atom work into the W3C? If so, talking to the W3C/IETF liaison pair would be more appropriate than this mailing list. If not, then suggesting that our document should be more W3C-like seems fairly out-of-scope for an IETF WG. Could you clarify? --Paul Hoffman, Director --Internet Mail Consortium
Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines
At 2:51 PM -0400 5/24/05, Karl Dubost wrote: Are you insecure? Well, I do sometimes worry my protocols aren't as long as those from other Working Groups, but I try not to think about it. Where did you read, imagine such a thing? The case has been settled for a long time by choice of the Atom Community. No trouble. OK, good. So why are we discussing where the Atom format document doesn't match up to W3C test specification guidelines? Did you miss an email? No. [[[I have done the review of Atom 0.8 to ___test___ W3C QA Specification Guidelines with an external technical document and I thought it could be also useful to the Atom community. ]]] - http://www.imc.org/atom-syntax/mail-archive/msg15675.html Right. You didn't say why you thought it would be useful, and then... and the rest, I'm replying to the questions. :) That's the part that is confusing. Your responses sound a great deal like we should be making changes to our documents based on W3C test guidelines. For what purpose? --Paul Hoffman, Director --Internet Mail Consortium
Re: Atom 08 - HTML Version
At 4:20 PM -0400 5/23/05, Karl Dubost wrote: Hi, I will use the HTML version http://ietf.levkowetz.com/tools/rfcmarkup/rfcmarkup.cgi?url=http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub-format-08.txt for something specific. Is it fine, or do people recommend another HTML Version of [[[ Expires: October 20, 2005 April 18, 2005 The Atom Syndication Format draft-ietf-atompub-format-08 ]]] - http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt The latter, definitely. The former makes good guesses about HTMLizing, but may have errors introduced by the automated guessing process. --Paul Hoffman, Director --Internet Mail Consortium
Re: atom:author clarification
At 9:35 AM +1000 5/24/05, Eric Scheid wrote: Tim/Paul/Others: is there any process or such where we could take the time to get clueful outsiders to read over the spec and relate to us which parts are confusing. Ideally this should happen once we've run out of issues to distract us. That was the IETF-wide last call, last month. The announcement was made on the IETF-Announce mailing list, and brought in a few folks. In addition, Tim and I pestered a number of people we know who we thought might not be following the document and asked them to look in. --Paul Hoffman, Director --Internet Mail Consortium
Re: Close the Atompub WG? (was: PROCESS QUESTION: are we done yet?)
At 6:41 PM -0400 5/21/05, Robert Sayre wrote: Discussion since you sent this email indicates that the people who currently think they constitute the Atompub WG don't think they need to respect any previous consensus. s/any/some/. Agree. Sometimes people change their mind. (s/Sometimes/Quite often/ ...) The people sending emails after last call are, by and large, not the same people who were posting in October (when we settled the dates issues). I suggest we seriously consider closing the WG if basic decisions cannot respected or declared out of order. Fully disagree. This WG has made the basic spec much stronger and more complete than any individually-submitted RFC could possibly be. Why shouldn't the IETF close this WG down? Because it is still improving on a specification that is important to the IETF. --Paul Hoffman, Director --Internet Mail Consortium
RE: multiple ids
At 2:11 AM -0400 5/21/05, Bob Wyman wrote: Tim Bray directs the editors to insert the following words: If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry and Atom Processors MUST treat them as such. It is a long standing and valued tradition in the IETF that Standards Track RFC's MUST NOT impose constraints on applications unless such constraints relate to issues of interoperability. Thus, while it is entirely appropriate for the specification to state that multiple atom:entry elements with the same atom:id ... describe the same entry it is NOT appropriate to state how Atom Processors must treat such elements. The text should read simply: If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry. +1. I can live with Tim's original wording because the phrase that Bob removes is impossible to measure or enforce, but Bob's wording is cleaner for the same result. --Paul Hoffman, Director --Internet Mail Consortium
RE: Compulsory feed ID?
At 2:30 AM -0400 5/21/05, Bob Wyman wrote: I think it would be both wise and appropriate to provide text in a Security Concerns section that describes the vulnerability of systems that rely on Atom documents to this particular attack. That's why we have signed documents, which are described fully in the document already. It is fine to add text to the signatures section explaining why they are useful against this attack, and a short mention in the Security Considerations section pointing back to that one. Please note that every format that the IETF has ever come out with that isn't inherently signed has either this exact problem or one very close to it. The fact that the format document specifies a signing mechanism in the document itself instead of in a companion document that is read by only 25% of the implementers is a giant leap forward. --Paul Hoffman, Director --Internet Mail Consortium
RE: Last Call: required summary or content?
At 7:56 AM -0400 5/12/05, Scott Hollenbeck wrote: It would be helpful if you could address the The current draft fails to satisfy the second bullet point allegation. -Scott- -Original Message- From: Robert Sayre [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 11, 2005 2:00 PM To: iesg@ietf.org Cc: Robert Sayre; Sam Hartman; Atom-Syntax Subject: 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. I don't see how. The current document certainly shows how to create entries with enclosed content (the entry can contain an atom:content element), and it certainly shows how to create entries with no enclosed content (the entry can contain no atom:content elements). 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 Those two personal opinions, neither of which appears in the current draft, do not relate to the charter-level description of enclosed content. In the case of the charter, enclosed content means an atom:content element, no other parts of the entry. If we took this too the extreme Rob wants, we would have to allow completely null entries because titles, dates, and even IDs could be considered content. --Paul Hoffman, Director --Internet Mail Consortium
Re: Fetch Me A Rock
Thus spake RFC 2119: 3. 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. At 11:18 PM -0400 5/11/05, Robert Sayre wrote: My interpretation is correct. That's impossible to assess because you haven't said which wording you are applying your interpretation to. Please be specific: is it the current draft, a particular Pace, or a particular group of Paces? At 11:38 AM -0400 5/11/05, Robert Sayre wrote: Remember, if we say SHOULD, that means implementations don't have to interoperate with people who don't provide a summary. A receiving implementation must be able to handle all defined elements, regardless if they are defined as MAY sent, SHOULD send, or MUST send, so I'm not sure what you mean by interoperate. 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. Fully disagree. SHOULD does not mean encourage. Remember that. Fully agree. I'm not going argue any more. Fully disagree. --Paul Hoffman, Director --Internet Mail Consortium
Re: Fetch Me A Rock
At 8:32 PM +0200 5/12/05, Julian Reschke wrote: Bare with me here; I'm not an implementer. What kind of pseudocode are you envisioning on the receiver side? My picture (which could easily be wrong is): # Atom 1.0 RFC says entries MUST have exactly one atom:foo1 # Atom 1.0 RFC says entries SHOULD have one atom:foo2 # Atom 1.0 RFC says entries MAY have one atom:foo3 Scan the entry. If you don't find an atom:foo1, fail. If you find more than one atom:foo1, fail. Process the atom:foo1. If you find more than one atom:foo2, fail. Process the atom:foo2. If you find more than one atom:foo3, fail. Process the atom:foo3. I agree with the analysis. So if our charter says that we should support title-only feeds, we can't make the presence of summary or content a SHOULD, right??? Why not? If the text says something to the effect of, for example, SHOULD include an atom:summary element unless there really is no summary, then title-only feeds are fine. --Paul Hoffman, Director --Internet Mail Consortium
Re: Fetch Me A Rock
At 1:07 PM -0600 5/12/05, Antone Roundy wrote: On Thursday, May 12, 2005, at 12:32 PM, Julian Reschke wrote: Paul Hoffman wrote: At 7:16 PM +0200 5/12/05, Julian Reschke wrote: A receiving implementation must be able to handle all defined elements, regardless if they are defined as MAY sent, SHOULD send, or MUST send, so I'm not sure what you mean by interoperate. Must a receiving implementation handle missing elements? I don't think as long as we say sender SHOULD include the element. Bare with me here; I'm not an implementer. What kind of pseudocode are you envisioning on the receiver side? My picture (which could easily be wrong is): # Atom 1.0 RFC says entries MUST have exactly one atom:foo1 # Atom 1.0 RFC says entries SHOULD have one atom:foo2 a) ...and MUST NOT have more than one # Atom 1.0 RFC says entries MAY have one atom:foo3 b) ...and MUST NOT have more than one Scan the entry. If you don't find an atom:foo1, fail. If you find more than one atom:foo1, fail. Process the atom:foo1. If you find more than one atom:foo2, fail. Process the atom:foo2. c) ...if it exists If you find more than one atom:foo3, fail. Process the atom:foo3. d) ...if it exists Paul, I presume a, b, c and d are what you intended? Yes, thank you. See why I'm not a developer? :-) So if our charter says that we should support title-only feeds, we can't make the presence of summary or content a SHOULD, right??? So what we're discussing here is whether: If you find more than one atom:foo2, fail. Process the atom:foo2 if it exists. ...should be this instead: If you find more than one atom:foo2, fail. If you don't find an atom:foo2, you are allowed to fail and still call yourself Atom compliant. Process the atom:foo2 if it exists. RFC 2119 isn't explicit on this point. Here's all it says about SHOULD: 3. 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. Perhaps the best we can do from that document is to attempt to divine from what it says about MAY, what it means about SHOULD, but I don't know whether this is valid or not. 5. MAY This word, or the adjective OPTIONAL, mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) So, if atom:summary is a MAY, then applications MUST be able to deal with feeds whether they have it or not. The text for SHOULD does not call out any such requirements. This omission suggests to me that the intent of SHOULD is to NOT REQUIRE implementations to interoperate with implementations that don't follow the recommendation. Otherwise, would that not have been spelled out? What are the full implications, if not the possibility of failed interoperability? Reduced functionality? I don't think so, because that is what MAY is about. You are reading *way* too much into 2119; this is a normal thing to do. The problem we have, as I pointed out earlier on the thread, is that we do not specify whether senders and receivers have the same SHOULD. I made one assumption, and Rob pointed out that I had made one different than he did. The way I read 2119 is that if a sender MAY or SHOULD include something, the receiver MUST NOT fall over if it is in what they receive, and MUST NOT fall over if it is not in what they receive. Does that clarify where I got to on this thread? --Paul Hoffman, Director --Internet Mail Consortium
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: Atom 1.0?
At 9:09 PM -0700 5/9/05, Walter Underwood wrote: Seriously, I don't mind Atom 1.0 as long as the next version is Atom 2.0. +12 --Paul Hoffman, Director --Internet Mail Consortium
RE: Last Call: 'The Atom Syndication Format' to Proposed Standard
At 8:16 AM -0700 5/10/05, Walter Underwood wrote: If publishers and subscribers have obstacles to using Atom, that sounds like a problem to me. It is a problem, of course. Everyone has this problem is not a good reason to ignore it. No one is ignoring it. This thread started because the format draft pointed out at least one aspect of the problem, which is more than most other RFCs do. Someone has to be the first to solve it, might as well be us. May I suggest that there are groups with more experience in the area than ours that would be more appropriate? In specific, since this problem affects all internationalized text, the Unicode Consortium has a much higher chance of solving the problem than an IETF Working Group who is focused on a syndication format. If you have a proposed solution to the problem (you didn't include one in your message to the WG), the Unicode Consortium is quite open to outside input on this type of thing. It is not acceptable to build formats for the English Wide Web. That doesn't exist any more. That is both grossly insulting to those of us have spent a great deal of time trying to make the Internet internationalization-friendly, and is also grossly technically inaccurate, unless you consider every written language other than Chinese, Japanese Kanji, Burmese, Khmer, Thai, Tagalog, Lao, and Tibetan to be English. (The folks who speak all the other languages might find you calling them English to be insulting too, of course.) --Paul Hoffman, Director --Internet Mail Consortium
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
At 2:14 PM -0400 5/10/05, Sam Hartman wrote: Except that we try to build deployable protocols. If there aren't content creation tools that can do the right thing then it becomes a deployment issue for atompub. True. Fortunately, there have been plenty of text editing tools that work with the no spaces between words languages for at least 20 years in the case of Chinese and Japanese Kanji (probably 15 years for the other languages). A perfectly reasonable response would be that you've thought about and understood the problem and there are sufficient tools available that can work with your proposed pipe that you don't need to care about the issue. I'll make that response. :-) --Paul Hoffman, Director --Internet Mail Consortium
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
At 9:33 AM -0400 5/9/05, Sam Hartman wrote: My personal opinion as someone who is very shortly going to have to evaluate the atom specification is that you've identified an issue (space and line breaking) for some languages that should be considered. Your proposed solution seems highly undesirable in that it requires us to understand the language of the text being displayed. In the past we've had all sorts of problems doing that. Your proposed solution also seems quite complicated. Fully agree. Please note the text in the spec we are working from: 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), and display the text using typographic techniques such as justification and proportional fonts. FWIW, this appears twice, identically, in the spec. Martin Dürst brought up CJK (well, actually CJT), saying that they don't use inter-word spacing. That's fine, but it is irrelevant to the text in the draft. If some text comes through with no spaces, there is no white space to collapse. His argument that some XML editors make long lines of text difficult to edit is clearly *way* out of scope for Atom, or any other XML-using protocol for that matter. It may well be that the solutions to this problem are worse than the problem itself. However I think it is important to specifically understand that is the case rather than failing to solve the problem because we failed to understand it. The case is that text that is supposed to be read by humans comes in many forms, with different line lengths, and so on. The paragraph from the spec says that Atom processors may alter these so that they can be presented better for the reader. Of course, they may also alter it to make it less readable, as many mail user agents do (sigh). Regardless, this says that the Atom processor is free to present things in text constructs in any fashion it deems suitable. This is particularly important for making Atom content accessible; for example, the Atom processor can use this rule to present text content by reading it aloud, by putting it on a screen greatly magnified one character at a time, and so on. At least based on the discussion the IESG has been copied on, it doesn't sound like the working group has fully considered this issue. The responses have more of the character of those found from people trying to brush aside an issue than of people who have carefully considered something and concluded there is nothing to be done. Sorry, but that's unfair. Alexy asked 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? Martin's response was orthogonal: Making this more precise is definitely desirable. But there is also an i18n issue: This works fine for languages that use spaces between words. The rest of the thread wandered into the weeds because it was hard to figure out what was being discussed. Moreover, thisn issue cannot be unique to atom: it must effect many XML based protocols both within the IETF and within other standards organizations. Any protocol that has XML that includes human-readable text has this issue. Well, the processors of that XML does; the protocols themselves do not. Anyway as someone evaluating atompub's output it would be very useful if the working group responded to this last call comment. IN my mind a response would start with a researched description of the issue: either confirm that Chinese and Japanese and Thai tools work as described or explain how they actually work. Then describe what other standards have done about this problem. Finally describe what atompub has done about the problem and why. I'm not asking for a lot of text; probably something about as long as this message. I believe that it can be a lot shorter: given the rationale above, it's not a problem for Atompub or any other XML-using protocol. For that matter, it's not really and XML problem at all: it affects text formats like HTML and RFC 2822 as well. --Paul Hoffman, Director --Internet Mail Consortium
Re: extensions -- Atom NS and unprefixed attributes
At 7:22 PM -0700 5/9/05, Tim Bray wrote: On May 9, 2005, at 6:52 PM, Robert Sayre wrote: I think we should be clearer that new elements in the Atom namespace and unprefixed attributes with parent elements in the Atom namespace can only be added by IETF consensus. Thoughts? I wonder if there's some standard IETF practice when you define a language as regards future change control? No. Nearly every protocol tries to go its own way. It's a mess. Generally -1. This spec defines what Atom 1.0 is, why try to micro-manage the future? -Tim Agree on the -1. At 10:34 PM -0400 5/9/05, Robert Sayre wrote: Fair enough. But can just anyone add stuff to the Atom namespace? If the IESG lets them, yes. We gotta trust the IESG after the WG shuts down. Fortunately, they have earned that trust over time. --Paul Hoffman, Director --Internet Mail Consortium
Re: the atom:copyright element
At 6:29 PM -0400 5/7/05, Robin Cover wrote: The publication of a new Implementation Guideline by the Open Archives Initiative (OAI) compels me to suggest once again [1], as Norm Walsh [2], Bob Wyman [3], and others have done before, that the name 'atom:rights' would be better than the (current) element name 'atom:copyright'. As before, -1. In fact, I would prefer to remove atom:copyright from the core before we make a post-last-call move to substitute a less-defined element such as atom:rights. Since this element name change is not likely to have any secondary ramifications that would affect other areas of the format design, it should be harmless. Fully disagree. Later, you suggested that the renamed element would have a URI that pointed to the rights asserted by the author. That has a *lot* of effects, including the need for someone to resolve that URI before republishing the content in another feed, and storing the resolution of that URI with a copy of the contents (so that that author can't change the contents and then come after you). That is far from harmless. Using the element name 'atom:rights', as argued below, could enhance interoperability Sorry, I didn't see anything in the rest of the post that showed how this could increase interop. Please be specific here. To me, you can't get much more interoperable than an unstructured, human-readable, free-text blob such as atom:copyright. and avoid some unforeseen and unintended legal implications that may emerge from use of the term (copyright). Legal FUD doesn't help here. The current atom:copyright entry has no properties different than allowing someone to type in whatever human-readable copyright notice they want in an HTML document. If someone is comfortable with asserting a copyright, they can; if they're not, they don't have to. Something non-legal, like 'rightsDescription=URI'. Please explain how rightsDescription is non-legal while copyright is legal. Seriously, I don't see how they can be differentiated. If you claim particular rights, that's a legal assertion of the same strength as claiming a copyright. I predict that if the Atom spec does not make this kind of accommodation to support this widely attested requirement, multiple (incompatible) ad hoc solutions will be invented, alongside widespread abuse of the 'atom:copyright' element. Surely, multiple (incompatible) ad hoc solutions will be invented ANYWAY, but providing the basic markup construct in the Atom syntax spec would point users in the right direction, rather than leaving them directionless. This goes back to the question of what goes into the core and what is done as an extension. I would strongly support the latter because, as you posit, people will disagree on how they should be able to assert rights. Coming up with a single extension structure that will keep everyone happy will take a lot of wrangling, but the effort would probably be worth it. --Paul Hoffman, Director --Internet Mail Consortium
Re: PaceCaching
-1. Having two mechanisms in two different layers is a recipe for disaster. If HTTP headers are good enough for everything else on the web, they're good enough for Atom. --Paul Hoffman, Director --Internet Mail Consortium
ADMINISTRIVIA: another mail loop
Expect to see at least a couple of more duplicates of recent messages on the list. This one comes courtesy of Xerox. The offending user has been removed from the mailing list and been told of the problem. --Paul Hoffman, Director --Internet Mail Consortium
Re: PaceTextShouldBeProvided
At 12:51 PM -0400 4/29/05, Sam Ruby wrote: Encourage interoperability and accessibility by suggesting that key textual constructs be both present and non-empty. +1 As these requirements are only SHOULDs, no feeds which are currently valid will become invalid. However, those that follow these suggestions will find that their feeds are useful to a wider audience than they would be otherwise. Folks here know that I'm not a big fan of SHOULDs where a MUST or a MAY would be better. In this case, I can see that the changes suggested fit the classical IETF definition of SHOULD. We can't force you to put in real text because there really might be nothing for you to say without just making up gibberish, but you should really try hard to say something, even if it is repetitive. You don't know which locations the recipient is going to be looking in, as we have seen from some of the WG traffic in the past week. --Paul Hoffman, Director --Internet Mail Consortium
Re: PubSub CAN NOT support Atom with existing no duplicate id constraint
At 11:48 AM -0400 4/27/05, Bob Wyman wrote: I know that nobody seems to like this issue However, I have explained on numerous occasions that the existing prohibition against duplicate ids in a feed simply cannot be supported by PubSub or any other feed aggregator. The problem is, once again, that prohibiting duplicate ids provides an easy to use attack vector for those wishing to effectively erase entries written by another author. (i.e. by publishing an entry with an id identical to one published earlier, one can force the earlier entry to be flushed from Atom feeds.) Question (not a disagreement): Why wouldn't the later entry be dropped instead of the first one being flushed? At 5:05 PM +0100 4/27/05, Bill de hÓra wrote: What will prevent people overwriting the atom:[EMAIL PROTECTED]'self'] links as well as the id? Seems like a good question. If someone is trying every avenue to erase an old entry, why wouldn't they try this as well? --Paul Hoffman, Director --Internet Mail Consortium
Re: On SHOULD, MUST, and semantics
At 6:47 PM +0100 4/27/05, Graham wrote: On 27 Apr 2005, at 5:28 pm, Paul Hoffman wrote: Proposal for thinking about: to simplify the spec, atom:summary should either be a MUST in all cases or a MAY in all cases. If it is just semantic like atom:category, it should be a MAY. If it is inherently valuable like atom:title, it should be a MUST. What isn't inherently valuable about a semantic. False dichotomy. What a load of unconstructive bollocks. False reading. I was comparing just semantic to inherently valuable. Both atom:category and atom:title are obviously both semantic, yes? --Paul Hoffman, Director --Internet Mail Consortium
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: NoIndex, again
We chose not to put things like this in the Atom core. Feel free to write an extension and discuss it here; there was certainly interest in many directions about grappling with the many intertwined issues that arise out of copyright, privacy, and so on. --Paul Hoffman, Director --Internet Mail Consortium
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
[[ wearing my IETF weenie hat, not my co-chair hat ]] At 10:10 PM +0100 4/13/05, Graham wrote: -1 I think introducing new core data types negates the point of having core, well-known data types. XHTML 2.0 is an issue we can solve now. I think it will be safe to leave any further formats to a new rev of the spec, since whatever new thing needs to be added would have to have reached similar popularity to either plain text or HTML. Fully agree with Graham. IANA registries are mostly for things that not core to actually running a spec, and the type of content seems quite core. The should this be relegated to an IANA registry or not question come up in almost every IETF WG because it is a question of what is and is not core for a developer. If a protocol has a reason to have lots of registries (such as IPsec, which has a dozen different types of transforms), then it is safer to put more core-ish things in a registry. But if it has only a few, then we should assume that most developers won't bother to look in the IANA registries, greatly reducing interoperability for things that appear only in a registry. I'm fairly certain the Atom format is in the second category. --Paul Hoffman, Director --Internet Mail Consortium
Re: IRI/URI
At 7:58 PM +1200 4/12/05, Porges wrote: ...I have a bit of a problem reading technical documents, my eyes tend to glaze over a bit... Please don't beat me too hard :) Note to everyone who feels the way Porges does: At this point in the process, having implementers who are unfamiliar with all the discussion on this mailing list reading the document is very valuable to us. It is even more valuable for you to ask questions such as Porges has. If 90% of your questions get replies such as you didn't read it correctly, that leaves 10% of the questions helping us clarify the document before it is finished. That is a Very Good Thing for us, and for the people who will become new implementers in the future when this mailing list is a historical memory. --Paul Hoffman, Director --Internet Mail Consortium
Re: next, previous
At 11:28 AM +0200 4/6/05, Henry Story wrote: Are the next and previous links that we thought may be attachable to the feed really too controversial to get into the final atom spec? It doesn't matter whether or not they are too controversial; the spec is frozen for significant technical changes. Unless, of course, the WG decides we really do want to open it all up again an take another probably four months of deciding what else we want to add and change. We can do that by amending our charter. So far, I have not heard consensus going towards that, but I could be wrong. --Paul Hoffman, Director --Internet Mail Consortium
Re: AD Review Comments and Questions: draft-ietf-atompub-format-07
At 9:26 AM -0700 4/5/05, Tim Bray wrote: Section 7.1: what process is the IESG supposed to use to review registration requests? Please see section 2 of RFC 2434/BCP 26 for mechanisms that might be used and please specify one in the document. Paul, care to take the lead on this? -Tim Nope. Scott: can you be more specific about your question? Section 7.1 seems pretty clear to me, but I'm possibly missing something. At 1:04 PM -0400 4/5/05, Scott Hollenbeck wrote: There needs to be both text explaining why IETF practice isn't being used Good. and there needs to be an identified URI. Bad. We don't need the URI *right now*, but I want it in the document BEFORE I bring the document to the IESG for review. Explanatory text will suffice for last call purposes. Just to be clear: you are asking us to get the final URI for the namespace *before* the IESG has approved of the document. That means that it is really, really likely that some implementers will write and deploy code based on the draft that is going to the IESG, not waiting to see if the IESG demands changes for the wire protocol or the MUSTs and SHOULDs. Do you really want that (he asks pejoratively)? --Paul Hoffman, Director --Internet Mail Consortium
RE: AD Review Comments and Questions: draft-ietf-atompub-format-07
At 2:25 PM -0400 4/5/05, Scott Hollenbeck wrote: As described in 2434, IESG Approval, though the IESG has discretion to request documents or other supporting materials on a case-by-case basis. Right. I'd really like to see some guidance in the document to describe what the IESG should look for. We're not atom experts, so it's going to be hard to determine what we should and shouldn't approve. Another paragraph will help future IESGs understand what they need to consider when reviewing requests. Sounds reasonable. (I was erring on the side of not micro-managing the IESG.) Rob/Mark: please take a shot at some guidance for them. At 1:04 PM -0400 4/5/05, Scott Hollenbeck wrote: There needs to be both text explaining why IETF practice isn't being used Good. and there needs to be an identified URI. Bad. We don't need the URI *right now*, but I want it in the document BEFORE I bring the document to the IESG for review. Explanatory text will suffice for last call purposes. Just to be clear: you are asking us to get the final URI for the namespace *before* the IESG has approved of the document. That means that it is really, really likely that some implementers will write and deploy code based on the draft that is going to the IESG, not waiting to see if the IESG demands changes for the wire protocol or the MUSTs and SHOULDs. Do you really want that (he asks pejoratively)? Hmm. Part of the problem is that there is no normal editing opportunity once the document is in the hands of the IESG. The editors can make changes as a result of IESG review, or in auth48, but those changes are supposed to be directed. Auth48 changes are supposed to be editorial only. This is clearly a normative situation. Correct. I was assuming that, once everything else got approved, you would put a DISCUSS vote on the document because of the lack of final namespace. We then ask the W3C for it, get it, tell you, and make the change to the n+1 version of the document (along with the editorial comments that often come out of an IESG review). Does that sound doable? The other part of the problem is that you're asking the IESG to review a specification that is incomplete without that little detail, and what's in there now looks very obviously non-standard. If you want to pursue a course of action that is similar to what was done with the IDN prefix [1] you're going to have to be a bit more clear about why the spec is incomplete. I'm fine with that. And, yes, I was modelling this process after than one. I'm OK with that, but please add text to the document to explain what needs to be done, who will do it, and when it needs to be done. Include a note that says this paragraph to be removed by the RFC Editor if appropriate. If this all means that the URI will be provided to the RFC Editor when they ask for it to finish the document, fine -- just say so. My preference is that the namespace be minted and included between the time that all other issues are cleared and when it is sent to the RFC Editor. In retrospect, we could have done that for the IDN spec as well. Does that work for you? --Paul Hoffman, Director --Internet Mail Consortium
Re: Why is alternate link a MUST?
We are creating a new protocol. We don't expect any current reader to behave well with it before it is done. Quoting from RFC 2119, which is what we are using to define MUST and SHOULD: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. Why is the alternate link actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions)? It seems like a perfect candidate for MAY, like most of the rest of the format. --Paul Hoffman, Director --Internet Mail Consortium
Re: Why is alternate link a MUST?
Not to pick on Eric; others have said things along the lines of: At 12:59 PM +1000 4/4/05, Eric Scheid wrote: I'll be happy with: self: MAY alternate: MAY id: SHOULD or possibly even: self: SHOULD alternate: SHOULD id: MUST This isn't a negotiating game. We have to have technical reasons for our assigning requirements levels. To repeat the relevant section from RFC 2119 (which is only two pages long, really): 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. What is the technical reasons for the SHOULDs and MUSTs? Where is the interoperability issues within the protocol (not with readers that don't know what the protocol looks like)? What are the potentials for causing harm? I'm not saying there are none; I'm saying let's choose our levels based on what we are supposed to be choosing from. --Paul Hoffman, Director --Internet Mail Consortium
