I support moving draft-nottingham-atompub-feed-history-08.txt to Proposed Standard [eom] -- Robert Sayre
Please add draft-ietf-atompub-typeparam to the charter [eom] -- Rob Sayre
-- cheers, Robert Sayre I would have written a shorter letter, but I did not have the time. http://franklinmint.fm/ http://feedautodiscovery.org/
Re: Autodiscovery IPR and Process Concerns
On 11/30/06, A. Pagaltzis [EMAIL PROTECTED] wrote: What rhetorical device is it to point out the rhetorical devices used by other participants in a discussion? Gosh, Aristotle. I'm sure I don't know. Y'all let me know when y'all figure it out. - Bobby
Re: PaceEntryMediatype
On 11/30/06, James M Snell [EMAIL PROTECTED] wrote: The key problem with application/atom+xml;type=entry is that at least one major browser (Firefox 2.0) still treats it as a feed and shows the subscribe link. Of course it does. Any program interested in consuming information is going to ignore unknown parameters. -- Robert Sayre
Re: [rss-public] Autodiscovery IPR and Process Concerns
On 11/30/06, Lachlan Hunt [EMAIL PROTECTED] wrote: The point to all this is that you shouldn't place too much weight on the status of the specification as a whole. You need to consider the stability and maturity level of each section individually. Thus, while proceeding with Autodiscovery as an RFC may yield a fully complete and endorsed specification more quickly than HTML5 Actually, the process you describe is pretty much identical to the IETF process in letter. For example, it took many years for RFC3986 to appear, describing URIs at the level of Full Standard. In practice, the WHAT-WG is more accountable, because there is a documented process for resolving disputes that actually empowers the group's participants. You'll find no such thing in the IETF, especially with an individual draft. The WHAT-WG is also much more rigorous in testing and research than the IETF, so I have to agree that there is little benefit to pursuing the Internet-Draft. Claims that the WHAT-WG is too slow are overblown at best -- getting something to Proposed Standard is not that interesting. The (active!) wiki at http://feedautodiscovery.org is rapidly eclipsing any other source on autodiscovery, and it can include information that would not be permitted in an IETF or WHAT-WG document, so it will always be more valuable and current. -- Robert Sayre
Re: [rss-public] Autodiscovery IPR and Process Concerns
On 11/30/06, James M Snell [EMAIL PROTECTED] wrote: There's absolutely nothing to disclose. Are you sure about that? I just prefer to limit my material contributions to various standards activities to organizations whose IP policies have been vetted and approved by my employer's IP lawyers or to posts on my personal weblog. Your wiki qualifies as neither. Interesting. What is the difference between your personal weblog and a wiki, in IP terms? Keep in mind that a wise man once said Anyone who uses the term 'Intellectual Property' is confused or trying to confuse you. I had originally suggested that the draft be resubmitted as a WG draft. The Area Director and the WG chairs suggested that since autodiscovery was not covered under the original charter it would be better to pursue it as an individual submission. I decided to do so only on the condition that the same open process used for the development of the Atom and APP specs would be followed -- meaning that there would be no closed door decisions and that clear consensus had to develop via open discussions on the WG mailing list before any change to the document was made. This entire paragraph is plainly false. All of the decisions you refer to were made without consulting the WG, the community, or what have you. If y'all think Ah, this is what's called innappropriately folksy. It's a common rhetorical device used when the speaker wants to appear that they're on the side of the common man or equivalent. The president of the United States makes frequent use of this device. Mission Accomplished!, Robert Sayre
Re: PaceEntryMediatype
On 11/30/06, James M Snell [EMAIL PROTECTED] wrote: John Panzer wrote: [snip] +1 to doing this outside of APP (but concerned about deprecating...) [snip] An I-D / RFC can update another RFC I think John should edit. -- Robert Sayre
Re: PaceMakeAutodiscoveryInformational
James M Snell wrote: Lachlan Hunt wrote: [snip] Move Autodiscovery forward as an Informational RFC But if it were published as an informational RFC, what purpose would it serve? To document best practice as it relates specifically to syndication feeds. The draft makes several requirements. That's not documenting best practice. For example, HTML5 says nothing about whether the relative order of feed autodiscovery links within a document is significant. The Atom autodiscovery draft, however, defines that the order is significant. Which software does that requirement concern? - Rob
Re: PaceMakeAutodiscoveryInformational
James M Snell wrote: I didn't write the doc so please don't complain to me about what's in there. If there is something that needs to be changed write up a pace. Uh, no. I don't think you should write it at all, and I resent having to waste my time following this completely redundant effort to make sure it doesn't do damage by making requirements that would break backwards compatibility with previous Firefox versions. The WHAT-WG text is fine. - Rob
PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
James M Snell wrote: I do believe that participation in this discussion is optional, as is choosing whether or not to support any particular IETF draft (informational or otherwise) so there is absolutely no need (or desire) for you to waste your time here. Nonsense. You know very well that projects I work on will get bug reports on standards compliance if you change something. So, yes, I do have to waste my time here. Since I maintain autodiscovery code people actually use, you'd think my opinion would count for something. == Abstract == Don't move forward with the autodiscovery draft. == Status == Proposed == Rationale == At this point there seems to be no reason for the autodiscovery draft to exist, since the WHAT-WG has ably covered the subject in Web Applications 1.0. http://whatwg.org/specs/web-apps/current-work/#alternate0 Reasons given for the continued existence of the IETF draft have been non-technical doubletalk. == Proposal == Stop work on the autodiscovery draft. == Impacts == Reduces mailing list traffic and standards noise.
Re: PaceAutoDiscoveryDraftIsPointless
Edward O'Connor wrote: I am worried that there are three simultaneous efforts to spec out feed autodiscovery: WA1, the RSS board's recent spec, and this draft. Ideally this stuff would get specced just once. WHAT WG seems like a neutral ground, syndication-format wise, so perhaps they're best positioned to spec feed autodiscovery in a way that makes everybody happy. Not only that, they are actually qualified to spec changes to HTML, which is what this is. -Rob
Re: PaceRecommendFullURIsForAutodiscovery
James M Snell wrote: http://www.intertwingly.net/wiki/pie/PaceRecommendFullURIsForAutodiscovery Definite -1 on this one. Buggy implementations just need to be fixed. Writing specs to bugs is silly at best. The link element is specified by HTML4/5. -Rob
Re: PaceAutoDiscoveryDraftIsPointless
James M Snell wrote: Heh.. I probably should not have been taking a drink when I read this last sentence :-). You do know that we're talking about the *syndication community* right? Actually, it's an HTML issue, so I don't see why the RSS Board or the Atom list or any incarnation of the syndication community would be an appropriate venue. -Rob
Re: PaceAutoDiscoveryDraftIsPointless
Sylvain Hellegouarch wrote: If autodiscovery is only a browser feature then indeed it has nothing to do here. But is it only meant for browsers? Browsers are surely the primary target, but bots and other HTML UAs make use of it. Both uses are covered by the people working on HTML, in the WHAT-WG and the W3C. -Rob
Re: PaceMakeAutodiscoveryInformational
Lachlan Hunt wrote: http://www.rssboard.org/news/70/vote-rss-autodiscovery-specification#discuss Like the Atom Autodiscovery draft, this spec serves no purpose. Autodiscovery is being defined in the HTML5 spec where it belongs, with both the alternate http://www.whatwg.org/specs/web-apps/current-work/#alternate0 and feed http://www.whatwg.org/specs/web-apps/current-work/#feed0 relationships. Fully agree. -Rob
Re: PaceMakeAutodiscoveryInformational
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. Huh? I'm not sure what you mean--you send way more messages than I do. I'm merely pointing out facts. I think the following entry from the WHAT-WG blog might be of use here. http://blog.whatwg.org/proposing-features Here are some key things that any proposal should include: * What is the problem you are trying to solve * What is the feature you are suggesting to help solve it? * What is the processing model for that feature, including error handling? This should be very clear, including things such as event timing if the feature involves events, how to create graphs representing the data in the case of semantic proposals, etc * Why do you think browsers would implement this feature * Why do you think authors would use this feature? - Rob
Re: PaceMakeAutodiscoveryInformational
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. Surely James has been warned about this in the past? - Rob
Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
Rogers Cadenhead wrote: My thinking was that we're accomplishing a task similar to the creators of the Robots Exclusion meta tag [1] -- put X values in element Y to achieve effect Z. Hmm, have to disagree. The behavior is already well-documented, so this isn't accomplishing much. This effort is similar to rewriting the robots exclusion meta tag document. Is there some aspect of the WHAT-WG document that bothers you? Why not provide feedback there? http://whatwg.org/mailing-list The feedback you received from WHAT-WG members on the RSS Board blog was extremely detailed and accurate. - Rob
Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
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, to the extent that they will debate the meaning of the term MUST. It's like existential poetry. In my experience, the WHAT-WG doesn't make any changes that break compatibility unless users are already having problems caused by implementation divergence. To make sure this is true, they research and make decisions based on metrics, rather than ill-defined consensus handwaving and individually-authored drafts with no support from client implementors. I've even seen it claimed that servers are clients too, in the IETF. Why not provide feedback there? I will if that's where autodiscovery goes. It is already there. Seems like a good idea to tell Atom publishers how to support autodiscovered feeds. They already know how, in general. The WHAT-WG is the place to work out edge cases in HTML semantics. Sylvain Hellegouarch wrote: there will be little harm done Actually, the proposal seems so poorly researched and poorly coordinated with WHAT-WG that I don't see how you can make that claim. When Pilgrim wrote the draft, there weren't as many existing implementations, so his approach made more sense at the time. -- Robert Sayre
Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
On 11/28/06, James M Snell [EMAIL PROTECTED] wrote: 3. We define a new media type for Atom Entry Documents, e.g. application/atomentry+xml No one relies on Atom Entry alternates now, so this is the best option. We should tack it onto the APP draft, since that will solve issues with the accept element there. And praise to mnot, who suggested we do this in RFC4287 but was overruled by the WG (including myself). -- Robert Sayre
Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
On 11/28/06, Tim Bray [EMAIL PROTECTED] wrote: On Nov 28, 2006, at 3:16 PM, Robert Sayre wrote: They already know how, in general. The WHAT-WG is the place to work out edge cases in HTML semantics. Over the course of history, a remarkable number of different groups have jumped up and down and said *We're* the ones defining HTML!!! Listen to *us*!!!. Yes, and *all* have them have done a poor job, except for the WHAT-WG. I am not a frequent participant there, but I have noticed a large leap in quality. For example, Firefox 2 is already shipping section 5.3.5 of HTML5, DOM Storage. http://www.whatwg.org/specs/web-apps/current-work/#scs-client-side I am supposed to be implementing getElementsByClassName today... instead I am posting to this list. *sigh It's foolish to draw conclusions about any HTML- related spec based either on which group is originating it Agree. But the WHAT-WG document and process are much better than the alternatives. or what anyone claims the browser engineers are going to do. Well, I've made the last 5-10 changes to the autodiscovery-related code in one popular browser, so I can go by what I've already done, rather than predicting the future. Here is the bug where I'm going to implement the 'feed' relation, as specified by the WHAT-WG: https://bugzilla.mozilla.org/show_bug.cgi?id=362156 -- Robert Sayre
Re: [whatwg] PaceAutoDiscoveryDraftIsPointless
On 11/28/06, James M Snell [EMAIL PROTECTED] wrote: 2. Are multiple alternate links with the same type attribute considered to be equivalent regardless of where those links appear in the document. What do you mean by equivalent ? -- Robert Sayre
Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]
James M Snell wrote: The process for moving forward on this spec will be the same as with Atom and APP. No, it won't. It's not a WG document. Does the draft diverge from existing browser behavior? Do browsers implement aspects of the document differently? What problems have you seen that make standardization necessary? Without some evidence that the document serves a purpose, I'm afraid I don't see the point. - Rob P.S. -- the author affiliation information in the draft appears to be inaccurate.
Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]
James M Snell wrote: Consensus calls will be posted periodically; That's not a process I can live with. Maybe this draft would be a better fit for the WHAT-WG or the W3C. Does the draft diverge from existing browser behavior? Do browsers implement aspects of the document differently? What problems have you seen that make standardization necessary? I dunno... you're the one that that writes browser code, you tell me. I don't think it's a problem worth solving, absent any evidence to the contrary. Mozilla doesn't seem to get many bug reports on this matter. You certainly seemed to think it was a good fit before. I changed my mind later on. How so? Given that my volunteering to serve as the editor of this document has nothing to do with my day job it would be inappropriate and dishonest for me to associate my employers name with the work. We all participate in the IETF as individuals. Affiliations are a professional courtesy. -Rob
Re: Forward Compatibility
James M Snell wrote: IOW, using the XHTML2 div as the child is compliant in a strictly sense but should be avoided because it will likely cause problems. An XHTML2 div is not compliant. The normative reference is to XHTML Modularization, and the accompanying XHTML1 definitions and namespace. In practice, this requirement is somewhat malleable, since XHTML's DTD requires that all elements reside in the default namespace (a flaw in XHTML), and XHTML Modularization makes some other universally-ignored requirements. XHTML2's namespace is different, though there is an open issue to change to the same namespace that XHTML1 uses. Even if the namespace were the same, Atom processors are not required expected to understand or comply with any XHTML[2] markup. In other words, Atom processors will pick up (X)HTML features as they see fit. The spec is quite specific on this point (using the markup is a MAY). In practice, (X)HTML support and security varies widely. -Rob
Re: [atom-syntax] Atom bidi
James M Snell wrote: Robert, It's been a few weeks since this came up. I was wondering if you'd be able to give some kind of estimate on when you might have a chance to document what you had in mind for mozilla/firefox/thunderbird. No pressure, of course, I just don't want this issue to stall out for lack of discussion. I still have something coming. The IETF meeting means the secretariat won't process a draft right now. -Rob
Re: [atom-syntax] Atom bidi
fwiw, I have no intention of reading the Snell bidi draft, or implementing what might be inside. As I've mentioned several times, I am already implementing a solution. I will document it and roll it onto the standards track as an update to RFC4287. -Rob James Holderness wrote: If you're going to require a separate namespace for bidi support, maybe it's best to use XHTML 1.0 and just toss out the lro and rlo values. I know I was originally pushing for those to be included, but now that I've seen how inconsistent the bdo support is in browsers I think they're probably going to be a waste of time. Nobody is going to get them right. Regards James
Re: [atom-syntax] Atom bidi
James M Snell wrote: How kind of you. Would you mind sharing some of the details with us now so that we can come to a common solution that works with more than just Firefox and Thunderbird? It'll work fine with everythign
Re: [atom-syntax] Atom bidi
James M Snell wrote: Would you mind sharing some of the details with us now so that we can come to a common solution that works with more than just Firefox and Thunderbird? That is absurd. This message has used up my atom-syntax time for the moment, so I guess you'll have to wait, or use up other people's atom-syntax time. -Rob
Re: [atom-syntax] Atom bidi
Robert Sayre wrote: fwiw, I have no intention of reading the Snell bidi draft, or implementing what might be inside. As I've mentioned several times, I am already implementing a solution. I will document it and roll it onto the standards track as an update to RFC4287. To be clear, I have no intention of ignoring input from this list, since that almost always results in improvements. I also have no intention of implementing anything that should have approval from the group, unless I have that approval. However, I don't think I'm obligated to let our more enthusiastic participants dictate the manner and pace of my personal contributions. -Rob
Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?]
Bill de hOra wrote: A. Pagaltzis wrote: I think given the above background you'll agree that the intent of the document is pretty coherent. I couldn't tell whether new Atom extensions are foreign markup, or something else to be dealt with under wrt being a forward-compatible friendly consumer. It's kind of circular. In short, I guessed and you told me I was wrong. Bill, please show us a bug? I don't think defining terms until we've got a good subset of an English dictionary will make the format more interoperable. -Rob
Re: Atom and bidi
James M Snell wrote: Yep, I'll work up a pace. I find this more than a little pushy. I found the problem, I think I have an answer, I've already written the code, and I said I would deal with it earlier today: http://www.imc.org/atom-syntax/mail-archive/msg18874.html -Rob
Re: Atom and bidi
James M Snell wrote: Robert Sayre wrote: James M Snell wrote: Yep, I'll work up a pace. I find this more than a little pushy. Cool! ??? Then write up a pace. We can compare the two options and figure out the best way to move forward. I am not sure what you are talking about. -Rob
Re: Atom and bidi
James M Snell wrote: If that's the case, it would be great if you would provide a concrete proposal that we can discuss or at least describe exactly what you're looking for. You seem to think I'm obligated to participate in a volumetocracy[1] in order to get my work done. I'm not, so there is no 'we'. -Rob [1] http://www.franklinmint.fm/blog/archives/000873.html
Atom Syndication Format To Draft Standard?
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. Thoughts? Robert Sayre
Re: Atom Syndication Format To Draft Standard?
Bjoern Hoehrmann wrote: I think that XHTML does not define an 'unicode-bidi' attribute. Do you mean, for 'unicode-bidi', as defined in CSS 2.1? Sure. Elliotte Harold wrote: Which elements would these be attached to? All of them. 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? It would probably be easier to add them in a separate document, huh? Robert Sayre
Re: Atom Syndication Format To Draft Standard?
Paul Hoffman [EMAIL PROTECTED] writes: Probably RFC 2026, but if not there, it is certainly in the folklore of How Things Are Done. That's unfortunate. A documented process is a requirement for open standards development, in the opinion of many http://blogs.sun.com/dennisding/resource/Open%20Standard%20Definition.pdf 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. 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. 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. Robert Sayre
Re: Atom Syndication Format To Draft Standard?
Paul Hoffman wrote: 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. Well, openness is only one metric. 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. Well, I figured it might make sense to advance something that pretty much works. I now see how foolish that idea was. Cycling at proposed will be fine. Robert Sayre
Re: clarification: escaped
On 7/25/06, Bill de hÓra [EMAIL PROTECTED] wrote: The RFC says that the content should be 'escaped' for type 'text/html' in 3.1.1.2, but dosn't define what that is. IIRC, WG discussion touched on this point, and the WG decided the definition wasn't important, given the example. Is there a problem you're hoping to clear up? -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Re: clarification: escaped
On 7/25/06, Bill de hÓra [EMAIL PROTECTED] wrote: It came up on django irc. I'd assumed for whatever reason that escaping was limited to the usual XML suspects, but when asked about html content I knew I didn't know for sure, especially wrt HTML character entities. And I didn't know whether Atom code could get away with escaping and . I'm not certain I understand the issue, but if the question concerns what happens when an Atom processor encounters a document with no declared entities and contains a title like this: atom:title type=htmllt;bnbsp;hmmlt;b/atom:title that is an XML fatal error, no doubt, as the ampersand before nbsp must be escaped. Concretely, Mozilla will give you a DOM with a non-breaking space if you write this: atom:title type=htmllt;bamp;nbsp;hmmlt;b/atom:title -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
On 7/19/06, Julian Reschke [EMAIL PROTECTED] wrote: What we're talking about here is not change control over the namespace or the namespace name! It's about what happens if an HTTP client dereferences that URL, which is irrelevant for the purpose of XML namespaces. It's irrelevant for the XML software, but not the implementer, which is why you want it to redirect to something. That's the problem I have with it. -- Robert Sayre
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
On 7/18/06, Lisa Dusseault [EMAIL PROTECTED] wrote: We don't have rules against such namespace choices. We could argue about whether or not we should have such rules, Well, there is a BCP about this. At this point, it's very rare to pull a document or change something like this that would affect implementations. Often the remedy at this stage is... I should hope that the IETF/IESG doesn't encounter this situation often, but that doesn't seem like a strong argument. How commonly are private namespaces used in IETF standards? The right argument to have is whether the namespace is a problem. Even the draft's author acknowledges that it is a valid concern, though he probably doesn't have the same solution in mind. -- Robert Sayre
Re: HTTP Authentication Options
On 7/17/06, Eric Rescorla [EMAIL PROTECTED] wrote: In most such systems, the passwords are stored in the password database as a one-way hash of the password. Systems that use forms will often do this as well... IMPLEMENTATION ISSUES I'm given to understand that there are ways in which the Digest spec is unclear and that implementation and interoperability is fairly spotty. ...which makes it impossible to use the existing auth database with Digest. Digest's more extensive protection options are basically unimplemented. Digest is extremely underspecified wrt to encoding of non-ascii characters. Some implementations respect the charset parameter specified in SASL Digest (RFC 2831). Others use the encoding of the page. No one is quite sure what IE does.* Mozilla uses UTF-8 all the time. * http://www.agileprogrammer.com/eightytwenty/archive/2006/05/04/14280.aspx The only thing we can reasonably say is Basic+TLS, but that's sort of silly, since many servers and some clients won't implement it. I'd rather skip the collective game of pretend. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: HTTP Authentication Options
On 7/17/06, Eric Rescorla [EMAIL PROTECTED] wrote: If by existing auth database you mean the basic or form database, this is generally correct--though one could in fact implement an auth database that would work for both. Right. But some of our server implementers couldn't implement it if they wanted to. Digest's more extensive protection options are basically unimplemented. By more extensive protection options do you mean the auth-int mode? Yes, but I believe some clients even screw up auth mode, and only work with 2069-style. Container-managed security in Java Servlet implementations often doesn't work with Digest, at least with the vendor-provided authentication classes. I'm not familiar with what HTTP implementations do, but I'll note that SIP implementations will do auth-int. Mozilla doesn't do it. Apache (mod_auth_digest) doesn't do it. Opera does. I don't know what MS libraries do these days. Feel free to take this point up with the IESG. I doubt you'll find them very sympathetic, however. Well, I'd like the document to reflect reality, but I suspect that will be no match for the IESG rules in combination with some WG members that want Basic+TLS enshrined in the document because that is what they are going to deploy. -- Robert Sayre
Re: HTTP Authentication Options
On 7/17/06, Eric Rescorla [EMAIL PROTECTED] wrote: Right. My point was merely that it's doable as a matter of programming. That's debatable, from an HTTP server's perspective, because the server must check (and temporarily store) the whole request before it can tell if the client knows the password. Not a good way to handle video uploads. Other authentication protocols, such as Amazon S3 auth, include the Content-MD5 header in the digest calculation so the server only has to check message body integrity after it has verified that the client knows the password. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Very brief minutes from the Atompub WG meeting
There is a difference between mandatory to implement and mandatory to deploy. ??? My client supports basic+tls, but none of the binaries include it -- Robert Sayre
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
On 7/11/06, Martin Duerst [EMAIL PROTECTED] wrote: At 10:43 06/07/10, Robert Sayre wrote: Hi Lisa, Thanks for the clarification. You may have missed another question I recently asked, so I'll repeat it here. I am concerned that purl.org lists the document author as the owner of the namespace URI, and I wonder how the IESG came to the conclusion that the namespace is not a problem. I see Sam Hartman raised the issue. What was the resolution? Could the draft advance to Draft- or Full-Standard in that namespace? I looked at that namespace shortly. Thanks, but I don't see how you would be able to answer any of the questions I asked above. It seems that it would be easy to change the owners to make clear that this is owned by the IETF. This can be done whenever it's needed. Actually, mnot delegates that path. Can he take it away? He's warned us about the very same thing wrt to Atom 0.3. A purl namespace in and by itself isn't any better or worse than a W3C namespace. I don't see any factual basis for that statement. For instance, the IETF has a liason relationship with W3C. -- Robert Sayre
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
On 7/4/06, Lisa Dusseault [EMAIL PROTECTED] wrote: I wrote the synopsis, in which I was careful not to state that it was a WG document. I believe it was accurate for what it said although it's very brief. I discussed explicitly with the IESG during the IESG tele-conference calls that there was some lengthy debate and disagreement over certain mechanisms in the draft. Hi Lisa, Thanks for the clarification. You may have missed another question I recently asked, so I'll repeat it here. I am concerned that purl.org lists the document author as the owner of the namespace URI, and I wonder how the IESG came to the conclusion that the namespace is not a problem. I see Sam Hartman raised the issue. What was the resolution? Could the draft advance to Draft- or Full-Standard in that namespace? -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests
On 6/28/06, James M Snell [EMAIL PROTECTED] wrote: Our default behavior will be to return the div. A separate API will provide the content without the div. So, standards-off-by-default then? Unbelievable. -- Robert Sayre
Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests
Irrelevant. The content in the entries below should be handled the same way: entry xml:lang=en xml:base=http://example.com/foo/; ... content type=xhtml xhtml:div xml:lang=fr xml:base=http://example.com/ feu/xhtml:a href=axe.htmlaxe/xhtml:a/xhtml:div /content /entry entry xml:lang=en xml:base=http://example.com/foo/; ... content type=xhtml xml:lang=fr xml:base=http://example.com/ feu/ xhtml:div xhtml:a href=axe.htmlaxe/xhtml:a/xhtml:div /content /entry On 6/28/06, Antone Roundy [EMAIL PROTECTED] wrote: On Jun 28, 2006, at 12:06 PM, A. Pagaltzis wrote: * James M Snell [EMAIL PROTECTED] [2006-06-28 20:00]: A. Pagaltzis wrote: * James M Snell [EMAIL PROTECTED] [2006-06-28 14:35]: Hiding the div completely from users of Abdera would mean potentially losing important data (e.g. the div may contain an xml:lang or xml:base) or forcing me to perform additional processing (pushing the in-scope xml:lang/xml:base down to child elements of the div. How is that any different from having to find ways to pass any in-scope xml:lang/xml:base down to API clients when the content is type=html or type=text? I hope you didn't punt on those? Our Content interface has methods for getting to that information. Then stripping the `div` is not an issue, is it? Consider this: entry xml:lang=en xml:base=http://example.com/foo/; ... content type=xhtml xhtml:div xml:lang=fr xml:base=http://example.com/ feu/xhtml:a href=axe.htmlaxe/xhtml:a/xhtml:div /content /entry Whether there's a problem depends on whether one requests the xml:base, xml:lang, or whatever for the atom:content element itself or for the CONTENT OF the atom:content element, in which case the library could return the values it got from the xhtml:div. Except in unusual cases like this, the result would be identical. Certainly a distinction could be made between how an XML library would handle this vs. how an Atom library would handle it. An Atom processing library might be expected to be able to do things like: * give me the raw contents of the atom:content element * give me the contents of the atom:content element converted to well- formed XHTML (whether it started as text, escaped tag soup, or inline xhtml) In the former case, keeping the div feels like the right thing to do-- the consuming app would have to know to remove it. In the latter case, removing the div from xhtml content feels like the right thing to do. But unless the library gives me the xml:base, for example, which applies to the content of the atom:content element (as converted to well-formed xhtml or whatever), as opposed to the xml:base which applied to the atom:content element itself, there's potential for trouble. ...now that I think about it, if the library always returns the xml:base which applies to the content of the element, that could cause trouble too: entry xml:lang=en xml:base=http://example.com/; ... content type=xhtml xhtml:div xml:lang=fr xml:base=feu/xhtml:a href=axe.htmlaxe/xhtml:a/xhtml:div /content /entry Here, if I get xml:base for the content of content, it will be http://example.com/feu/;. Then, if I get the raw content of the element, strip the div, and apply xml:base myself, I'll erroneously use http://example.com/feu/feu/; as the base URI unless I know to ignore the xml:base attribute on the div. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests
On 6/28/06, James M Snell [EMAIL PROTECTED] wrote: Actually, switch this. I realized after I sent this that I had it backwards. The default behavior will be to not return the div. A separate API will provide the content with the div. Next time, don't start out with egregious obfuscation, and then kick and scream through tons of list traffic with beyond-bogus arguments. Here's how it started: http://mail-archives.apache.org/mod_mbox/incubator-abdera-dev/200606.mbox/[EMAIL PROTECTED] It's a waste of other people's time. Once or twice is understandable, reasonable people sometimes disagree on basic things. I think we're up to 20 or 30 of these incidents with you, though. At this point, it's not something to be replied to with a smart remark. It belies contempt for your colleagues. We shouldn't have to sit here and listen to specious tripe because it sounds semi-plausible to a non-implementor. It's abusive, and it's much worse than the nasty messages so many of us have sent. -- Robert Sayre
http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests
When XHTML content is used, The XHTML div element itself MUST NOT be considered part of the content. http://atompub.org/rfc4287.html#rfc.section.4.1.3.3 This is hard to test with aggregators, but conforming libraries definitely need to get this right. http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests -- Robert Sayre
Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests
On 6/27/06, James M Snell [EMAIL PROTECTED] wrote: Please define conformance in regards to this test. That is, what is the exact behavior that a library must perform when a code library has an API like, getContent on the content element. e.g., is a parser not conformant if it passes the DIV on to the consuming application with the expectation that the application is responsible for doing the right thing with it? Don't be dense. Would the parser be conformant if it passed on the feed, entry, and div elements with that expectation? I'll file a bug on UFP and I bet you it'll get fixed without a question, because there won't be a bad-faith interpretation to fight. That's two demerits this week for you. Tsk tsk. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
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? Even Paul went on the record saying there was no consensus on several aspects of the document. 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. -- Robert Sayre
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
On 6/26/06, Paul Hoffman [EMAIL PROTECTED] wrote: Your reading might differ from others'. I've read a lot of these, so I know this synopsis differs others. Usually they stuff like WG is OK with this. It's perfectly natural to question and appropriate things that seem out of the ordinary. In the future, please save the oblique answers for someone who cares to hear them. -- Robert Sayre
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
On 6/26/06, Robert Sayre [EMAIL PROTECTED] wrote: On 6/26/06, Paul Hoffman [EMAIL PROTECTED] wrote: Your reading might differ from others'. I've read a lot of these, so I know this synopsis differs others. Usually they stuff like WG is OK with this. It's perfectly natural to question and appropriate things that seem out of the ordinary. er, a little steamed here, that's not English. It's perfectly natural to question whether things that seem out of the ordinary are appropriate. Anyway, you don't seem to have accurate answers on the process when it doesn't match the outcome you're looking for. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Feed Thread approved as a Proposed Standard
On 6/24/06, James M Snell [EMAIL PROTECTED] wrote: It's not a vendor controlled namespace; it's an individual controlled namespace Irrelevant. that I'm more than happy to delegate to the IESG. The IETF has complete change control of the spec at this point -- including changing the XML namespace used by the extension if doing so would be appropriate. I trust the IESG and the RFC editor to do whatever is deemed to be appropriate. The IESG approved it with no directions to the RFC editor. So your conjecture comes at the wrong juncture. If you were qualified to answer my message, that would be obvious. I'll note that you failed to answer a single question I asked, which tells me they were good ones. p.s. FUD is generally more effective when not based on generally false and easily refuted assumptions This is content-free flaming. But I'll note there was nothing false in my message. And you didn't refute anything either. I'd say you're just trying to intimidate people. -- Robert Sayre
Re: Feed Thread approved as a Proposed Standard
On 6/23/06, Paul Hoffman [EMAIL PROTECTED] wrote: It is not correct that they *need* to be, but there is no reason for them not to be. In general: - If a protocol is worked on in an open context, standards track is preferred The most important parts of an open context are well-documented decisions. That didn't happen here. It is surely appropriate for IETF members to suggest an alternate status for the document, no matter what the IESG eventually decides. 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. In effect, an effort was made to end the discussion, rather than address the issue. I don't feel the community has control of this document, and that bothers me. n.b. -- not inviting a rebuttal. -- Robert Sayre
Re: Feed Thread approved as a Proposed Standard
On 6/23/06, Paul Hoffman [EMAIL PROTECTED] wrote: 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, I guess those scare quotes are appropriate, but the underlying point is that I now have a Proprietary Standard designation for this document. That's a bummer, because the stewardship of RFC4287 is also in a similarly worrisome state. Open standards are not made by people paid to write mailing list posts until everyone else gives up. I know I don't have the bandwidth to cut through the brazen obfuscation anymore. -- Robert Sayre
Re: Sorry this is on-list; Robert does not seem to appreciate off-list mail
On 5/31/06, A. Pagaltzis [EMAIL PROTECTED] wrote: I have no further commentary to offer. Promise? I'm sick of getting rude mail from James after he's flown off the handle. I doubt I'll receive any more. -- Robert Sayre
Re: OT Re: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST]
On 5/31/06, Ernest Prabhakar [EMAIL PROTECTED] wrote: While I'm not entirely thrilled with James, and I believe you provide some useful perspective, if you think it is appropriate and ethical to respond by posting private email to the list, I must reluctantly conclude that this list is better off without you. James has taken private conversations on-list: [ ] yes [ ] no So please, spare me the lecture. I don't want to get nasty emails from James anymore. My problem is solved. -- Robert Sayre
Re: Link rel test cases
On 5/31/06, A. Pagaltzis [EMAIL PROTECTED] wrote: My interpretation of these facts is that string comparison is explicitly expected. Incorrect. -- Robert Sayre
Re: OT Re: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST]
On 5/31/06, A. Pagaltzis [EMAIL PROTECTED] wrote: If you hadn't dropped an asinine jab at him into a completely unrelated thread you might not have created the problem that you would then need to solve in the first place. Actually, those were just the latest two. But you didn't know that, did you? How about you go back to writing your Atom code? If you have further comments, send them somewhere else. If you send them to me, I'll be sure to put them with the other unread emails from you. -- Robert Sayre
Re: Link rel test cases
On 5/31/06, A. Pagaltzis [EMAIL PROTECTED] wrote: Hi Robert, * Robert Sayre [EMAIL PROTECTED] [2006-05-31 19:35]: On 5/31/06, A. Pagaltzis [EMAIL PROTECTED] wrote: My interpretation of these facts is that string comparison is explicitly expected. Incorrect. I don't see how If it was explicit, you wouldn't need to interpret. Thanks for playing. -- Robert Sayre
Re: Feed Thread in Last Call
On 5/30/06, Lisa Dusseault [EMAIL PROTECTED] 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 I find this to be a pretty compelling argument. I don't find Tim's argument particularly compelling. It's crystal ball stuff, and implementations are free to ignore *any* part of an Atom document. In this case, it's another case of a WG member claiming something is broken without a shred of spec text to back it up. If Tim and others want that to be true, they have an RFC to revise. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Feed Thread in Last Call
On 5/30/06, James M Snell [EMAIL PROTECTED] wrote: Robert Sayre wrote: [snip] document. In this case, it's another case of a WG member claiming something is broken without a shred of spec text to back it up. If Tim The exact same can be said of the argument that the use of extension attributes is broken. There's not a shred of spec text to back it up. I didn't say the use of extension attributes is broken. I said your extension has no reason to use them, remember? You never gave a technical reason for the change between last call and the previous version. Personally, I don't see them as broken, I just see them as extremely short-sighted. That's how I see your extension. Hey, maybe you could do RFC4287bis as an individual submission! -- Robert Sayre
Re: Link rel test cases
On 5/30/06, James Holderness [EMAIL PROTECTED] wrote: of Use IRI:Compare, Use String::Compare, or The spec doesn't say, so you may use whatever you prefer. The URI/IRI specs say use whatever you prefer. If you don't like that, have James add it to his revision of 4287. :) -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Fwd: Link rel test cases
I think James forgot to cc the list -- Forwarded message -- From: James M Snell [EMAIL PROTECTED] Date: May 30, 2006 9:38 PM Subject: Re: Link rel test cases To: Robert Sayre [EMAIL PROTECTED] Robert Sayre wrote: [snip]...have James add it to his revision of 4287. :) Pardon, what the hell are you talking about? Do you really, honestly believe that being a complete ass is a productive use of anyone's time? - James -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Link rel test cases
On 5/26/06, James Holderness [EMAIL PROTECTED] wrote: Logically I would assume the simple string comparison in section 5.3.1 of RFC3987, but I was hoping this would be documented somewhere more explicitly. An atom:id is an IRI too, but it explicitly specifies character-by-character, case-sensitive comparisons. By not doing the same for link relations the spec kind of leaves things open to interpretation. RFC3986, section 6 and RFC3987, section 5 document this procedure very well. The comparison ladder reduces false negatives in exchange for processing effort. If you think the ladder is worth climbing in this case, go for it. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Link rel test cases
On 5/26/06, David Powell [EMAIL PROTECTED] wrote: We probably should have specified the simple string comparison method; it is more satisfying to call an implementation that publishes not obviously equivalent IRIs 'wrong', rather than just 'somewhat unwise'. Huh, I personally feel that the comparison ladder is better. Sort of like, if it comes down to that, we can't help you, even for atom:id. The WG definitely felt simple string comparison was needed for atom:id, so we spent *a lot* of time on that text. I don't feel that effort would pay off here, at all. Especially since a consumer that matched HTTP://www.IANA.org:80/assignments/relation/alternate would be in error. That's ridiculous standards weenie stuff, don't you think? -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Atompub WG meeting at the Montreal IETF
On 5/23/06, Paul Hoffman [EMAIL PROTECTED] wrote: 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. We are? Pull the trigger, already. I propose the following agenda, which should fit well into a one-hour slot: Looks like that will be a very good use of time. -- Robert Sayre
Re: Fyi, Apache project proposal
On 5/23/06, James M Snell [EMAIL PROTECTED] wrote: We made a mistake calling our stuff a reference implementation It's OK. We're used to this kind of thing coming from your direction. -- Robert Sayre
Re: Feed Thread in Last Call
On 5/23/06, Tim Bray [EMAIL PROTECTED] wrote: I would vociferously resist any such claim. OTOH, there are more than a few products on the market right now that back up just such a claim. So there's an existence proof, and most of the APIs I've seen *do* make use simple vs. structured, but you may be right that the market will change that. In otherwords, there is little point in continuing this discussion... just like you and I agreed 150+ messages ago... -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Feed Thread in Last Call
On 5/19/06, Lisa Dusseault [EMAIL PROTECTED] wrote: Am I missing something in the case against the choice of location for the metadata? Yes. That location is going to cause interoperability problems in my implementation, because the draft leaves too much undefined, and in implementations who won't parse them. I think I've made that extremely clear. The previous draft addressed my concerns. My current plan is to implement the threading element, but I'll recommend against accepting bug reports on the other aspects of the document, since I think it's an underspecified mess. Kind of silly considering the clear lessons from earlier efforts, but the threading element is good enough. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Feed Thread in Last Call
On 5/19/06, James M Snell [EMAIL PROTECTED] wrote: Other than the issue with the Microsoft implementation, which has already been thoroughly discussed, what other interop problems are you anticipating? A clear, non-editorialized, listing of the potential issues and the rationale for each would be most helpful. You've received several of those from me. I suggest you read your old mail, paying close attention to messages that you replied to in under 15 minutes. I have zero confidence that any technical change or compromise is possible from you, and I find interacting with you to be a giant time sink. My new policy will be to explain my problem *once*, and then I will verify that my concerns (if any) have been addressed at some later date when there is a revised document available. If my concerns aren't addressed, I will make a concerted effort to avoid writing or being responsible for maintaining any relevant functionality. -- Robert Sayre
Re: Feed Thread in Last Call
there are countless such examples. Some implementations don't use/preserve the scheme attribute on the category element; some implementations don't fully support the atom content model (e.g. base64 encoded content); some implementations don't support XML digital signatures; etc. Because there is no definition of conformance, even for the core Atom format, it is perfectly reasonable to expect that existing implementations may have to change a bit in order to support the introduction of new extensions, depending on the level of support they have for the full atom data model as defined by RFC4287. Atom implementations with generic support for links and extensions, will find that this draft moves the goalposts of what a reasonable implementation is expected to handle, and I firmly believe that it should be possible for implementations to provide generic support for extensions in order to assist their adoption. RFC4287 sets the goal posts. Extension attributes and elements ARE allowed on Link. Whether or not an implementation chooses to support such extensions is an implementation choice. [snip] None of the folks I know of that have actually implemented support for the extension has had any problems with them. Does that include any stateful feed APIs, or APP servers that aren't based on native XML back-ends? I am not certain what you mean by stateful feed APIs, but the answer is yes to the question about non-native XML back-ends. [snip] - James -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard
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. - draft-snell-atompub-author-extensions-00 Oh, this excellent document is affected too. Seems like we have a real problem here. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))
On 5/17/06, Paul Hoffman [EMAIL PROTECTED] wrote: At 7:11 AM +0200 5/17/06, Robert Sayre wrote: On 5/17/06, Paul Hoffman [EMAIL PROTECTED] wrote: 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. Where is that written down? RFC 2026. That's a long document that's been updated by other process RFCs. Care to point me at the relevant section? I didn't see one. Didn't Julian just get some WebDAV extensions approved as Experimental? Maybe, but that's irrelevant. I don't know much about the IETF, but I do know the process consists mostly of the unwritten rules, rather than the written ones. So, it seems to me that it is very much relevant. In fact, I can quote you on this, from the initial Atom meeting at Sun Microsystems. If you're big on process, the IETF probably isn't for you, or something to that effect. Why the change of heart? The fact that some WGs don't follow the IETF process doesn't mean we should do the same. If our AD (who is also the AD for WebDAV) That's true in the sense that our AD is in the Apps area. However, Ted Hardie is the AD advisor for WebDAV, and those documents were approved before Lisa was an AD, IIRC. But, I suspect you knew all of that. wanted this document to not be on standards track, she would not have put out the IETF last call for the document to be on standards track. OK, phrase it that way. Why does our AD want this document on the standards track? It was clearly designed without much research, no input from client implementers, and contains lots of extra cruft. We also -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))
On 5/17/06, Paul Hoffman [EMAIL PROTECTED] wrote: Sections 4.1 describes what is appropriate for standards track; section 4.2 describes what is appropriate for Informational and Experimental RFCs. That's true, but the you asserted the following: 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. Where is that written down? Don't see it in RFC2026. In fact, I don't see any of the process we're encountering documented there. I'm disappointed you didn't answer the more interesting and relevant questions in my previous message. -- Robert Sayre
Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))
On 5/17/06, John Panzer [EMAIL PROTECTED] wrote: I don't see any issue with these attributes. Do you see Windows Feed Platform apps using these attributes? Probably not, huh? Do you consider that lack of interoperation a feature? James M Snell wrote: I find it utterly amazing that there is so much contention over two optional attributes that serve a purely informational purpose. Are we supposed to take this seriously? Since you can't coherently defend a single design decision in the draft, it's safe to conclude this document is not ready to be an RFC. If a feed publishers includes them, and a particular feed consumer currently doesn't see a use for them, that feed consumer can ignore them and continue processing the feed with ZERO loss of function. Well, you clearly don't think they're important. But then you felt compelled to change them back and got an instant stamp of approval from our AD. What happened there? -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Informational vs. standards-track for Atom Threading Extensions
On 5/18/06, Lisa Dusseault [EMAIL PROTECTED] wrote: On May 17, 2006, at 10:02 AM, Robert Sayre wrote: Well, you clearly don't think they're important. But then you felt compelled to change them back and got an instant stamp of approval from our AD. What happened there? My question has yet to be answered. I could still recommend Experimental instead of Standards Track if I learned of some possible harm to security/privacy or Internet health, or some deep barrier to interoperability, but I have not yet learned of a high enough risk+severity of such concerns to change my mind there. I think this is an excellent standard. If another individual, such as myself, were to submit an individually authored document, it would have to meet the same standard, right? I hope that makes the situation clearer! Sure does! -- Robert Sayre
Re: Feed Thread in Last Call
On 5/16/06, James M Snell [EMAIL PROTECTED] wrote: Very simple reasons: the attributes are easier to implement, Speaking as an actual, rather than alleged, client implementer, I find this assertion ridiculous and dishonest. are allowed by RFC4287 and are being used in real deployments. So, the argument is that it's already deployed, then? It looks like you agree with me. -- Robert Sayre
Re: Feed Thread in Last Call
On 5/16/06, Paul Hoffman [EMAIL PROTECTED] wrote: 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. James changed the document in response to those messages. That should be enough. Maybe she could ask James about them. It's not my obligation to spelunk for them, and it's certainly not your place to start making demands like that. 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. Well, I'm not going to quibble with you about procedural details. But I have to wonder why they're in the document at all. Looks like the IETF wants to publish a proposed standard explicitly designed to break a very popular implementation, with no technical reason. I think that speaks volumes about the IETF, its management, and the quality of its individual contributors. 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. Well, I don't want to standardize some of what James has deployed. It won't work in Sean's implementation. I'm not sure I can interoperably implement the parts in question. Your two biggest client implementers aren't real happy about this. It might be appropriate if you really stretch, but it's sure not smart. -- Robert Sayre
Re: Feed Thread in Last Call
On 5/17/06, James M Snell [EMAIL PROTECTED] wrote: What's broken? Do you think the AD and this WG are dumb? Why are you setting up such an obvious strawman? Congratulations, your extension didn't break Atom. The point is that your extension is broken. You're including attributes in that document that you know won't be visible to a large number of implementations. You have no technical reason that makes that location compelling, and several WG members have questioned whether this document adequately covers the area in question. In fact, you appear unable to explain the rationale behind any technical decision without resorting to circular reasoning, logical fallacies, and claims that are outright false. -- Robert Sayre
Re: Feed Thread in Last Call
On 5/17/06, A. Pagaltzis [EMAIL PROTECTED] wrote: I have to disagree that there is no technical reason. There is no way to sanely associate additional information with a link element. Sure there is, and it's the way James did it. Is the information valuable? Does the spec cover cardinality issues? Is the link element useful here? Was the spec less effective in its previous incarnation? The answer to all of these questions is no. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Feed Thread in Last Call
On 5/17/06, Lisa Dusseault [EMAIL PROTECTED] wrote: - We're talking about visibility to implementations of the base spec only, not implementations of the extension, naturally. Any new information can be visible to implementations of that extension. There's a misunderstanding here. Many applications rely on a feed parsing service provided by the OS or a language-level library. Some of those platforms (MS is not the only one) don't provide access to extension attributes on the link element. For example, entry ... foo:bar / link foo:bar=baz ... / /entry here the extension attribute stands a chance of getting lost. The reason this occurs is because it's much easier to design an API that doesn't deal with these things in the general case. This situation could change in the future, as Atom consumer APIs develop. My implementation will parse and preserve the attribute, but I'm not sure what I'm supposed to do with it at an application level, especially if I encounter more than one such link element. As a result, I see no reason to introduce gratuitous compatibility problems when the cardinality of the link element doesn't seem to suit the problem very well. - We're talking about adding machine-parsable data that would be invisible to readers of the post content I don't know. The specification says nothing about that. Presumably, the implementers that have already deployed know what they are for. -- Robert Sayre
Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))
On 5/17/06, Paul Hoffman [EMAIL PROTECTED] wrote: 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. Where is that written down? Didn't Julian just get some WebDAV extensions approved as Experimental? You seem to be saying IETF participants don't get to have anything other than a black/white opinion on the readiness of this document. I disagree, and I also think it's kind of inappropriate for you to be managing discussion in this way. After all, it's not a WG document, is it? I would have said this should go Experimental, but it's not clear that the author is willing to change the document in any meaningful way, so there's no experiment to conduct. Informational and Experimental RFCs The role of Informational RFCs is often debated in the IETF. Many people like having them, particularly for specifications that were created outside the IETF but are referenced by IETF documents. They are also useful for specifications that are the precursors for work being done by IETF Working Groups. On the other hand, some people refer to Informational RFCs as standards even though the RFCs are not standards, usually to fool the gullible public about something that the person is selling or supporting. When this happens, the debate about Informational RFCs is renewed. Experimental RFCs are for specifications that may be interesting, but for which it is unclear if there will be much interest in implementing them, or whether they will work once deployed. That is, a specification might solve a problem, but if it is not clear that many people think that the problem is important, or think that they will bother fixing the problem with the specification, the specification might be labeled an Experimental RFC. If, later, the specification becomes popular (or proves that it works well), it can be re-issued as a standards-track RFC. Experimental RFCs are also used to get people to experiment with a technology that looks like it might be standards track material, but for which there are still unanswered questions. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Feed Thread in Last Call
On 5/16/06, James M Snell [EMAIL PROTECTED] wrote: At this point, Feed Thread support has been deployed in Friendster, Typepad, and MovableType. I thought the working group was fairly clear about the dubious value and placement of these attributes, and you yourself posted that no one was implementing them, they were strictly informational, and free to be ignored. So you don't think they're important or needed, and then WG doesn't have consensus on them. Even Tim's comments were in the abstract, and not related to feed thread at all. 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. From a technical perspective, the interactions between multiple links with the extension attributes remain unspecified. As a client implementor, I suppose I'll find out what exactly they're for whenever I see the already-completed implementations deployed. In my opinion, the document should do more to inform the community on the role of these attributes. now is the time to step up and make your case. You've merely stated you believe that moving these attributes back to the original location is the right decision. That is not a technical rationale. I would expect to see a more compelling reason, given the clear, technical rationales of those against your decision. On an unrelated note, this document contains sections copied verbatim from RFC 4287, and it would be polite and honest to acknowledge that. -- Robert Sayre
Re: Feed Thread in Last Call
On 5/16/06, James M Snell [EMAIL PROTECTED] wrote: A few of the individuals on the WG had a problem with the placement of the attributes due to various limitations of a few existing Atom 1.0 implementations. Right, and you're breaking them because...? You haven't coherently explained your reason for moving them back. After all, you agreed with the WG and updated the document, but now you've moved them back for unexplained reasons and pointed at deployments. None of the folks I know of that have actually implemented support for the extension has had any problems with them. I find your answers most unsatisfying and full of circular reasoning that serves mostly to dance around the fact that you and a few others have already deployed. That's been your argument for months now, and the IETF process has a way to deal with that situation: Informational. -- Robert Sayre
Weekly Posting Summary
Messages | Bytes| Who +--++--+ 19.44% |7 | 41.09% | 100373 | [EMAIL PROTECTED] 11.11% |4 | 12.86% |31414 | [EMAIL PROTECTED] 11.11% |4 | 9.60% |23444 | [EMAIL PROTECTED] 13.89% |5 | 6.06% |14807 | [EMAIL PROTECTED] 11.11% |4 | 4.91% |12001 | [EMAIL PROTECTED] 8.33% |3 | 4.44% |10857 | [EMAIL PROTECTED] 2.78% |1 | 7.25% |17717 | [EMAIL PROTECTED] 5.56% |2 | 4.21% |10293 | [EMAIL PROTECTED] 5.56% |2 | 3.97% | 9707 | [EMAIL PROTECTED] 2.78% |1 | 1.59% | 3895 | [EMAIL PROTECTED] 2.78% |1 | 1.59% | 3876 | [EMAIL PROTECTED] 2.78% |1 | 1.24% | 3041 | [EMAIL PROTECTED] 2.78% |1 | 1.17% | 2869 | [EMAIL PROTECTED] +--++--+ 100.00% | 36 |100.00% | 244294 | Total -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Atom Rank Extensions
On 5/5/06, Andreas Sewe [EMAIL PROTECTED] wrote: You mean r:rank, right? Well, the purpose of r:scheme (and its child elements) is to describe the ordered set from which r:rank's values a picked. Think of it as a datatype definition geared specifically at describing those sets of numbers commonly encountered in grading schemes. Why don't you call it that in the draft? This conflicts with the atom:author field. Why not @id, @domain, etc. Well, I am not sure what you mean here, but as for @domain you have to realize that a single scheme can be used to rank entries within more than one Ranking Domain (e.g.., within several feeds). Changing @name to @id might cause confusion, since attributes called id commonly contain NCNames, not IRIs. I suggest to James using an r:id child element of r:scheme, instead, to mimic atom:id, but somehow he doesn't like the idea. But maybe you can come up with a better name for @name (no pun intended). Ranking Domain. I'm still not sure what that means. An Atom feed element MAY contain any number of r:scheme elements. A feed MUST NOT contain more than one r:scheme element with the same name. Well, you have all of these child elements that can change the effect of the element, so why would you want to ban this behavior? I don't understand the above. :-( Can you please clarify your objection. Thanks. I don't see the interoperation problem the MUST NOT is preventing. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
What Atom software are you working on?
I've been working to add Atom support to Firefox 2. Some other Firefox devs are toying with exposing internal data like history and bookmarks as Atom feeds. What software are you writing? -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Feed thread update
On 5/4/06, Tim Bray [EMAIL PROTECTED] wrote: This assertion that atom:link is not extensible is simply, flatly, completely, wrong. I agree that it's not an especially convincing or interesting argument, given that 6.4 starts with Atom allows foreign markup anywhere in an Atom document We certainly don't want consumers to barf on foreign markup anywhere, so it has to be allowed everywhere. Of course, you'd be foolish to put extension attributes on things like atom:updated, and lots of other places, because then you're going to force people to dive into the feedparser/feedtools/gdata/etc implementation layer. Secondly, we might not like it for strange pseudo-nationalistic reasons, but some implementers find it convenient to transcode Atom to RSS2. when you're doing that, it's more difficult to preserve markup in areas left undefined by the specification. If you want to make a point, and carp on how crappy those applications are, you'll look for an excuse to do it. In reality, those extension points haven't proven that interesting or necessary, and the current thread is a particularly forceful example of that reality for those of who aren't participating. So, it really is that most common of syndication archetypes: the tempest in a teacup. -- Robert Sayre
Re: Atom Rank Extensions
On 5/3/06, Paul Hoffman [EMAIL PROTECTED] wrote: Works for me. http://www.alvestrand.no/pipermail/problem-statement/2003-March/000951.html -- Robert Sayre
Re: Atom Rank Extensions
of that specification. Appendix A. Acknowledgements The authors gratefully acknowledge the feedback from the Atom Publishing working group during the development of this specification. You should also acknowledge verbatim copies of text from RFC4287. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Atom Rank Extensions
On 5/2/06, A. Pagaltzis [EMAIL PROTECTED] wrote: Such as? Not appropriate for on-list discussion, sorry. When I read terms like more standard wrt the feed thread extension, it makes me cringe. There are obvious reasons why that one is better than the rag-tag group of RSS extensions... Disagree. There is no proof of that. There is proof that the existing patchwork of RSS extensions is insufficient. That is enough to convince me that an extension which addresses their holes is useful. If addressing holes in existing standards was unnecessary, then RSS is good enough and the Atom was a giant waste of time. I don't I follow your reasoning. We have namespaces so vendors can create whatever they might like, without involving the standards organization. I fail to see the point in rubber-stamping such things. You mean there should be a formal agreed-on statement of what an I-D is supposed to achieve before the process starts? If that is what you mean: yes, that is definitely a fine idea. And WG chairs, etc, etc. -- Robert Sayre
Re: Atom Rank Extensions
On 5/2/06, James M Snell [EMAIL PROTECTED] wrote: Aristotle, I appreciate the intention, but please don't bother. It is painfully clear that Robert has no intention of adding anything of any real value to the discussion. ??? -- Robert Sayre
Re: Atom Rank Extensions
On 5/2/06, A. Pagaltzis [EMAIL PROTECTED] wrote: * James M Snell [EMAIL PROTECTED] [2006-05-02 19:45]: A. Pagaltzis wrote: Such as? Aristotle, I appreciate the intention, but please don't bother. It is painfully clear that Robert has no intention of adding anything of any real value to the discussion. I know. However, I despise politics and old boys clubs and prefer the merit of my decisions to be self-evident, so I'm avoiding any assumption of any axe to grind behind his behaviour, to see what should be addressed and how. If there is any meritorious concern in his objections, I'd like it addressed, regardless (despite?) of who brought them up and how. I've been saying the same thing for weeks. I suppose it's par for the course to handwave about them being strictly advisory, supply circular definitions for the feature in the first place, claim no one will be implementing the feature, then claim that someone is, etc, etc. You know, stuffing an idea because of who proposed it. You can go read the atom-protocol archives if you want more evidence of that. The general pattern seems to be to sanctimoniously scold me for making the suggestion, and then to adopt it with cosmetic changes. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Atom Rank Extensions
On 5/2/06, James M Snell [EMAIL PROTECTED] wrote: Again, however, Feed Rank is not intended to compete with the simple list extensions. They serve different purposes. SLE defines a processing model for individual feed documents whose entries represent a sorted list; Feed Rank defines a way of assigning numeric rankings to entries to facilitate sorting and grouping. I find this explanation most unconvincing. Near as I can tell, this spec serves an identical purpose, but it's much less flexible. In the Atom Syndication Format [RFC4287], the order of entries as presented in a feed is typically considered to be insignificant. This presents a challenge when the set of entries is intended to represent an ordered or ranked list. This document specifies an extension... Seems to me it's pretty darn similar. -- Robert Sayre
Weekly Posting Summary
Messages | Bytes| Who +--++--+ 29.09% | 16 | 36.32% |83142 | [EMAIL PROTECTED] 16.36% |9 | 14.13% |32346 | [EMAIL PROTECTED] 12.73% |7 | 11.57% |26492 | [EMAIL PROTECTED] 7.27% |4 | 6.01% |13765 | [EMAIL PROTECTED] 7.27% |4 | 5.47% |12527 | [EMAIL PROTECTED] 5.45% |3 | 5.84% |13377 | [EMAIL PROTECTED] 3.64% |2 | 6.26% |14339 | [EMAIL PROTECTED] 3.64% |2 | 2.87% | 6578 | [EMAIL PROTECTED] 3.64% |2 | 2.87% | 6563 | [EMAIL PROTECTED] 3.64% |2 | 2.46% | 5632 | [EMAIL PROTECTED] 1.82% |1 | 1.89% | 4331 | [EMAIL PROTECTED] 1.82% |1 | 1.53% | 3512 | [EMAIL PROTECTED] 1.82% |1 | 1.42% | 3246 | [EMAIL PROTECTED] 1.82% |1 | 1.34% | 3070 | [EMAIL PROTECTED] +--++--+ 100.00% | 55 |100.00% | 228920 | Total -- Robert Sayre I would have written a shorter letter, but I did not have the time.
