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: [rss-public] Autodiscovery IPR and Process Concerns

y 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: PaceEntryMediatype

uming information is going to ignore unknown parameters. -- Robert Sayre

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: 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: [rss-public] Autodiscovery IPR and Process Concerns

r 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

Autodiscovery IPR and Process Concerns

onstitutes structure. 3.) Well, whatever. ;) a little confused, Robert Sayre [1] http://www.imc.org/atom-syntax/mail-archive/msg19142.html

WikiWikiWeb (was: Autodiscovery Draft Issues)

#x27;s a wiki... just go for it. (the CSS is a little rough still... I'll work on prettying it up) -- 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 j

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: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)

th 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)

ylvain 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: 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 effo

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.

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.

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

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

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 "

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

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 po

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

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 effo

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 ma

Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]

James M Snell wrote: Fair enough. We'll see if others agree; I'm not in any particular rush nor do I see any particular reason why this should be moved to some other venue. Hmm, looks like WHAT-WG has picked it up already: http://whatwg.org/specs/web-apps/current-work/#alternate0 That's

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? W

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

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 namespac

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

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 ha

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

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

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 g

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 the

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 wha

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: -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 c

Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?]

Bill de hOra wrote: I don't think the document can forward to proposed without clarification. Also, "forward-compatible" is mentioned, but not defined - it's not possible to make a safe assumption on what it means, since it's relative to whatever "foreign markup" is. I assume "unrecognized" a

Re: Atom and bidi

James Holderness wrote: >James M Snell wrote: >> Doh! I actually meant [RLE] here and not [RLO]. Either way, yes, I know >> there is a difference. > > Ok, but I think you need to clarify what exactly it is that this attribute > is supposed to mean then. I'll take that action. -Rob

Re: Atom and bidi

Eric Scheid wrote: > > what happens with ? Nothing. -Rob

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

Re: Atom Syndication Format To Draft Standard?

HTML. 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?

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 Standar

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: Re: clarification: "escaped"

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: <b>&nbsp;hmm<b> -- Robert Sayre "I would have written a shorter letter, but I did not have the time."

Re: clarification: "escaped"

rtant, 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: Protocol Action: 'Atom Threading Extensions' to Proposed Standard

;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

s 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

l 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.

Re: HTTP Authentication Options

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

280.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: 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

Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard

space 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

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

Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

he 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: 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

7;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."

http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

his right. http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests -- Robert Sayre

Re: [RFC 4287] unicity of atom:category element

meaningful, dereferencable URI. There's no spec text to back this up. A convention might emerge, but let's not BS it. -- 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, 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.&qu

Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard

s 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

re 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: Feed Thread approved as a Proposed Standard

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

that the IETF has change control here? -- Robert Sayre

Re: Feed Thread approved as a Proposed Standard

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: Feed Thread approved as a Proposed Standard

t 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: 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 > >explicitl

Re: OT Re: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST]

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: 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]

his 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: 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: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST]

rown quite tired of this Insult-James-And-Everything-He-Does-And-Says campaign of yours. You are accomplishing nothing. Get a life and move on. - James [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] Robert Sayre wrote: > > I think James forgot to cc the

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 revi

Re: Link rel test cases

7;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."

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

Re: Feed Thread in Last Call

ons 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: Link rel test cases

at 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: Link rel test cases

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: 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: Atompub WG meeting at the Montreal IETF

se 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: Feed Thread in Last Call

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

writing or being responsible for maintaining any relevant functionality. -- Robert Sayre

Re: Feed Thread in Last Call

derspecified 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: Informational vs. standards-track for Atom Threading Extensions

On 5/19/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote: I answered your question as fully as I could Quite true, but I asked James. -- Robert Sayre

Re: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard

vision. - 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: Feed Thread in Last Call

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. > >

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 h

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

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 (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

27;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, 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 st

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

ith 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

'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: Feed Thread in Last Call

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

e 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/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 l

Re: Feed Thread in Last Call

yments. 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

s 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

Re: Feed Thread in Last Call

is document contains sections copied verbatim from RFC 4287, and it would be polite and honest to acknowledge that. -- Robert Sayre

Weekly Posting Summary

% | 244294 | Total -- Robert Sayre "I would have written a shorter letter, but I did not have the time."

  1   2   3   4   5   6   7   8   >