I support the proposal.

Joly MacFie



On Tue, Nov 24, 2009 at 2:29 PM, Rogers <cadenhead@...> wrote:

> A proposal has been made for the RSS Advisory Board to take over
> publication of the Media-RSS specification and maintenance of the RSS-Media
> mailing list. Details here:
>
> http://tech.groups.yahoo.com/group/rss-board/message/295
>
> We welcome comments from the public on the proposal.
>
>
> --
---------------------------------------------------------------
Joly MacFie  917 442 8665 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
http://pinstand.com - http://punkcast.com
---------------------------------------------------------------


[Non-text portions of this message have been removed]

A proposal has been made for the RSS Advisory Board to take over publication of
the Media-RSS specification and maintenance of the RSS-Media mailing list.
Details here:

http://tech.groups.yahoo.com/group/rss-board/message/295

We welcome comments from the public on the proposal.

Thanks Rogers!

--- In rss-public@yahoogroups.com, "Rogers" <cadenhead@...> wrote:
>
> The RSS Advisory Board is now running a local copy of the Feed Validator:
>
> http://rssboard.org/rss-validator
>
> I'm still making some adjustments to the presentation, but it looks like it
works properly. If you could test it with your own RSS feeds and let me know if
you encounter problems, that would be helpful.
>
> The validator didn't have a "valid RSS" badge that includes the Feed Icon, so
I created one:
>
> http://rssboard.org/rss-validator/images/valid-rss.png
>
> I will try to keep the code up to date with the Feed Validator and contribute
any changes I make back to the project. So far it's running the exact same code.
>
> The valid RSS badge is available for reuse under the Creative Commons
Attribution/Share Alike license [1]
>
> 1: http://creativecommons.org/licenses/by-sa/2.0/
>

Rogers wrote:
> The RSS Advisory Board is now running a local copy of the Feed Validator:
>
> http://rssboard.org/rss-validator

Cool. Tried a few tests and it's working nicely for me.

Regards
James

Rogers wrote:
>
> The RSS Advisory Board is now running a local copy of the Feed Validator:
>
> http://rssboard.org/rss-validator <http://rssboard.org/rss-validator>
>
> I'm still making some adjustments to the presentation, but it looks like
> it works properly. If you could test it with your own RSS feeds and let
> me know if you encounter problems, that would be helpful.
>
> The validator didn't have a "valid RSS" badge that includes the Feed
> Icon, so I created one:
>
> http://rssboard.org/rss-validator/images/valid-rss.png
> <http://rssboard.org/rss-validator/images/valid-rss.png>

Deployed on feedvalidator.org. :-)

> I will try to keep the code up to date with the Feed Validator and
> contribute any changes I make back to the project. So far it's running
> the exact same code.

You already have commit access.  Let me know if I can help in any way.

> The valid RSS badge is available for reuse under the Creative Commons
> Attribution/Share Alike license [1]
>
> 1: http://creativecommons.org/licenses/by-sa/2.0/
> <http://creativecommons.org/licenses/by-sa/2.0/>

- Sam Ruby

The RSS Advisory Board is now running a local copy of the Feed Validator:

http://rssboard.org/rss-validator

I'm still making some adjustments to the presentation, but it looks like it
works properly. If you could test it with your own RSS feeds and let me know if
you encounter problems, that would be helpful.

The validator didn't have a "valid RSS" badge that includes the Feed Icon, so I
created one:

http://rssboard.org/rss-validator/images/valid-rss.png

I will try to keep the code up to date with the Feed Validator and contribute
any changes I make back to the project. So far it's running the exact same code.

The valid RSS badge is available for reuse under the Creative Commons
Attribution/Share Alike license [1]

1: http://creativecommons.org/licenses/by-sa/2.0/

--- In rss-public@yahoogroups.com, Aristotle Pagaltzis <pagaltzis@...> wrote:
> I see no upside to this attempt at consistency. RFC 3339
> datetimes are nearly trivial to parse (which of course was the
> whole point of that RFC), and in any case are already supported
> by anyone who parses either Atom or the Dublin Core RSS extension
> elements.

You're right. If this proposal gets any further, I will switch the date-time
format to RFC 3339.

* Rogers <cadenhead@...> [2009-10-15 14:20]:
> My thinking was that because the namespace was centered on RSS,
> it would be better to use its date-time format. If it was
> expanded to support Atom, I would have used RFC 3339 since that
> format is easier to parse.

It’s not just ease of parsing, it’s also 2- vs 4-digit years
(are you using RFC 822 or RFC 2822 format?), and the presence of
redundant information (the day name) that allows for properly
formatted but invalid dates (Fri, 15 Oct 2009 15:57:08 +0200).

I see no upside to this attempt at consistency. RFC 3339
datetimes are nearly trivial to parse (which of course was the
whole point of that RFC), and in any case are already supported
by anyone who parses either Atom or the Dublin Core RSS extension
elements.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

--- In rss-public@yahoogroups.com, "Bill Kearney" <wkearney99@...> wrote:
> In theory this info is already coming with the feed as part of the > HTTP
headers. Use the data that's already present.

By "this info" you mean the date-time of last update, correct? I can see why it
would be better to make a HEAD request to the feed details feed to determine
whether it was updated, but it would mean an extra request most of the time to
be told there was nothing new.

> What evidence exists to prove there would be any uptake of it?

That's a good question. There's a chicken-egg problem here. If I adopted the
namespace today, it would make my feed less capable to every RSS client that
doesn't support the namespace.

Perhaps the namespace could be used only for requests from clients that support
RFC3229+feed, since they're already trying to optimize bandwidth and would be
more receptive to the proposal. Anyone know some of the bigger clients that
support this?

Randy Charles Morin made this comment on my blog: "A similar solution to
feedDetails is X-Include. It's already well documented and understood. A
downfall of these approaches is that they actually increases connections, which
is often more important than bandwidth when you are scaling RSS."

What do people think about putting these optional elements in a separate file
and using X-Include [1] to incorporate them? Would clients make HEAD requests to
determine whether they needed an updated copy, or just request the included file
every time they requested the feed?

1: http://www.w3.org/TR/xinclude/

--- In rss-public@yahoogroups.com, Aristotle Pagaltzis <pagaltzis@...> wrote:
> Since this is in a new namespace, is there a reason to prefer
> RFC 3339 over RFC 822 format here?

My thinking was that because the namespace was centered on RSS, it would be
better to use its date-time format. If it was expanded to support Atom, I would
have used RFC 3339 since that format is easier to parse.

* Rogers <cadenhead@...> [2009-10-13 16:40]:
> <rssboard:feedDetails lastUpdated="Tue, 13 Oct 2009 09:01:25
-0400">http://ekzemplo.com/feedDetails.rss</rssboard:feedDetails>

Since this is in a new namespace, is there a reason to prefer
RFC 3339 over RFC 822 format here?

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

Rogers wrote:
> A publisher who wished to make use of this would be advised to
> move all channel elements except for title, link, description
> and atom:link to the detail URL.

I would think you'd still need to send the full feed by default for
backwards compatibility with clients that don't understand your new minimal
format. And then those clients that were willing to except the minimal feed
would include some kind of HTTP header to identify that capability to the
server.

At that stage though, you have no need for a link to an external source. If
a client decides that it wants the full feed details, it just doesn't
include the magic HTTP header. And if the server wants to force the full
details down to client in the event of an update, it can just ignore the
header (possibly based on etags or If-Modified-Since for clients that have
already been updated).

However, your problem now is how this will all be handled by proxy servers.
You're going to need to include a Vary header of some sort. How well that
works may depend on the kind of header you use to signal support for this
capability.

And at the end of the day, I'm not sure it's really worth all the effort.
You're proposing keeping a bunch of elements that I'd be happy to see
dropped, but not keeping ones that I'd consider essential. I imagine
everyone's opinion on this would differ though, so the end result may never
satisfy anyone.

With compression enabled, is it really going to save you that much
bandwidth?

Regards
James

In theory this info is already coming with the feed as part of the HTTP
headers.

Use the data that's already present.

But since that data is often ignored (and sometimes wrong because of poor
scripting) what's to justify making the effort to introduce yet another way
to get it?  What evidence exists to prove there would be any uptake of it?

Don't get me wrong, I pitched for much the same notions ages ago.  The
market apparently doesn't care enough to manage their consumption of
bandwidth.  Adding the code to be more effective is apparently not worth it,
sad to say.

-Bill Kearney

----- Original Message -----

> I posted this idea on my blog [1], and Antone Roundy had a better idea
> than ttl -- putting the date and time the feed details were last updated
> in the element, like this:
>
> <rssboard:feedDetails lastUpdated="Tue, 13 Oct 2009
> 09:01:25 -0400">http://ekzemplo.com/feedDetails.rss</rssboard:feedDetails>
>
> That way, the client knows when the detail feed needs to be checked for an
> update, and never checks it otherwise.
>
> 1: http://workbench.cadenhead.org/news/3562
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

I posted this idea on my blog [1], and Antone Roundy had a better idea than ttl
-- putting the date and time the feed details were last updated in the element,
like this:

<rssboard:feedDetails lastUpdated="Tue, 13 Oct 2009 09:01:25
-0400">http://ekzemplo.com/feedDetails.rss</rssboard:feedDetails>

That way, the client knows when the detail feed needs to be checked for an
update, and never checks it otherwise.

1: http://workbench.cadenhead.org/news/3562

With the current interest in rssCloud and PubSubHubbub (PuSH), I've been
thinking about all the bandwidth that's consumed by the RSS elements that
describe the feed. When a client requests an RSS feed 14 times in one day, it
gets the basic details of the feed -- title, link, image, ttl and so on -- 14
times even though most of them stay the same for months if not years.

James Holderness directed me to RFC3229+feed, a method to request partial RSS
feeds that omit elements that a client has already seen. Here's information on
that:

http://www.wyman.us/main/2004/09/using_rfc3229_w.html

But as far as I can determine, this approach still sends all of the channel
elements that describe the feed itself. I wanted to float an idea here to see if
mailing list members think it would be useful:

<rssboard:feedDetails>http://ekzemplo.com/feedinfo.rss</rssboard:feedDetails>

This channel-level RSS element identifies a URL that contains the full details
about the feed. The details would be expressed as an RSS feed without any item
elements.

An optional ttl attribute could contain the number of days the publisher would
like clients to cache the information before checking it again:

<rssboard:feedDetails
ttl="30">http://ekzemplo.com/feedinfo.rss</rssboard:feedDetails>

A publisher who wished to make use of this would be advised to move all channel
elements except for title, link, description and atom:link to the detail URL.
Title, link and description are required in RSS, and atom:link identifies the
feed's URL so it can't be moved.

Hello, everybody.  Here are some comments on the draft rss-namespace document
posted at http://www.rssboard.org/rss-namespace

1.) The Introduction says: "This namespace requires the
"http://www.rssboard.org/rss-specification" declaration in the top-level element
of the XML dialect that's making use of RSS..."

I think that's not worded quite right.  The XML namespace declarations are
inherited such that any parent node or even the nested rss elements themselves
can declare the namespace.  I think it should be sufficient to state the decided
namespace and direct the reader to "http://www.w3.org/TR/REC-xml-names/" for
instructions on how to use it, but here are three examples:

<root xmlns="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6">
   <midlevel xmlns:rss="http://www.rssboard.org/rss-namespace">
     <rss:rss .../>
   </midlevel>
</root>

<root xmlns="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6">
   <rss xmlns="xmlns="http://www.rssboard.org/rss-namespace" .../>
</root>

<root xmlns="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6">
   <rss:cloud xmlns:rss="http://www.rssboard.org/rss-namespace" .../>
</root>

2.) I still think the namespace URL should include at least the version "2.0",
as per my last post: http://tech.groups.yahoo.com/group/rss-public/message/1963

3.) If necessary, the motivation for providing a namespace could be explained
with something like the following:

"Because RSS 2.0 has no XML namespace, direct reuse of its XML elements inside
other XML documents can often be difficult and sometimes impossible. Rather than
requiring repeated invention of an ad hoc namespace each time full or partial
embedding of RSS-like data is required, the Rss Advisory Board is here
recommending a common XML namespace [and providing XML schema documents to go
with it?].  It is important to understand that Namespaced RSS 2.0 is not RSS 2.0
compliant, and therefore should only be used in special circumstances, and never
in the regular publication or consumption of RSS 2.0 feeds."

4.) You asked for other examples.  I think the "cloud" tag is the best, and you
have that one.  One extreme example might be temporarily nesting an entire RSS
document inside another XML doc.  For instance, one might like to define a WSDL
function that takes RSS-structured data as parameter.  Since trying to embed
non-namespaced XML in something like WSDL can sometimes be problematic (depends
on your tools), the RSS data might normally have to be passed as a string with
all XML being escaped.  Unfortunately you then have unstructured data at the
WSDL level, and further, when reconstructed internally as non-namespaced RSS,
the RSS types may cause collisions when considered in a global ontologies.  One
possible solution--not always optimal of course--is to first transform the RSS
2.0 XML into "Namespaced RSS 2.0" XML for internal use.  If this approach is
taken, transformations to and from the Namespaced RSS 2.0 to the standard
non-namespaced RSS 2.0 would still always be required for interoperability with
the normal RSS world.

5.) I think it would be helpful to provide an XSD for Namespaced RSS 2.0, to
help developers write conforming code.  Is there a preferred XSD for RSS 2.0
today that could adapted?  I found existing XSD for RSS 2.0 here:
http://weblogs.asp.net/wkriebel/archive/2004/03/07/85642.aspx

Hope this is helpful.

Cheers,

Mason Lee
http://masonlee.org

Nate,
Believe it or not, that's just one big weird-ass looking singular link, not
multiple links. There's nothing in RSS about having multiple links in the link
element.
Thanks,

Randy

--- In rss-public@yahoogroups.com, "nrutman" <nathan.rutman@...> wrote:
>
> I'm working on parsing some RSS 2.0 content, and I've found that several
popular RSS 2.0 documents have multiple links embedded in one <link> tag
separated by asterisks.
>
> For instance, this is from the Yahoo Finance feed:
>
>
<link>http://us.rd.yahoo.com/finance/news/rss/story/*http://us.rd.yahoo.com/fina\
nce/news/topnews/*http://biz.yahoo.com/ap/091009/as_india_earns_infosys.html</li\
nk>
>
> Is this part of the RSS 2.0 spec?  It doesn't look like it to me.  Is this
common?  How should I handle this?
>
> Thanks,
> -Nate
>

I'm working on parsing some RSS 2.0 content, and I've found that several popular
RSS 2.0 documents have multiple links embedded in one <link> tag separated by
asterisks.

For instance, this is from the Yahoo Finance feed:

<link>http://us.rd.yahoo.com/finance/news/rss/story/*http://us.rd.yahoo.com/fina\
nce/news/topnews/*http://biz.yahoo.com/ap/091009/as_india_earns_infosys.html</li\
nk>

Is this part of the RSS 2.0 spec?  It doesn't look like it to me.  Is this
common?  How should I handle this?

Thanks,
-Nate

Hey, that's really great!

(Turns out there were many good responses to my earlier post that I missed
because my subscription notifications to this list are not what I thought. 
Embarrassing!)

I have some comments regarding the namespace choice:
"http://www.rssboard.org/rss-namespace"

1. The RSS version should probably be included in the namespace URL.

2. The year 2009 perhaps should be included in the namespace URL to mitigate the
fact that ownership of domain names changes hands and URLs may get repurposed. 
I think what you want is a namespace that will be globally unique forever--even
if there is no document hosted there in the future.  Using the year helps out
future owners of the domain.

Some real-world examples:

http://www.w3.org/2001/XMLSchema
http://www.w3.org/2005/Atom
http://xml.apache.org/xmlbeans/2004/02/xbean/config

(Though there are plenty of counter examples!)

For these reasons, I believe a better namespace URL is something like:

http://www.rssboard.org/2009/rss2.0

But at least:

http://www.rssboard.org/rss2.0-namespace

Thanks for all this!

I read the draft at http://www.rssboard.org/rss-namespace and it looks good.


Cheers,

Mason
http://masonlee.org


--- In rss-public@yahoogroups.com, Rogers Cadenhead <cadenhead@...> wrote:
>
> Randy Charles Morin and I have been working on draft documentation for an
> RSS namespace.
> Here's a link to it:
>
> http://www.rssboard.org/rss-namespace
>
> As the docs state, it has not been approved by the board yet and is offered
> for discussion purposes only. We'd love to get feedback on it.
>
> If anyone has one or two more examples of how RSS could be used in another
> XML dialect, that would be helpful.
>
>
> [Non-text portions of this message have been removed]
>

Randy Charles Morin and I have been working on draft documentation for an
RSS namespace.
Here's a link to it:

http://www.rssboard.org/rss-namespace

As the docs state, it has not been approved by the board yet and is offered
for discussion purposes only. We'd love to get feedback on it.

If anyone has one or two more examples of how RSS could be used in another
XML dialect, that would be helpful.


[Non-text portions of this message have been removed]

Hi folks--

Didn't get any response before, so just wanted to try one more time:

Is anyone at RssBoard interested in providing an XML namespace for RSS 2.0, for
when RSS elements need to be nested inside other XML?  I've seen it mentioned on
this group before.

Having a namespace would allow for the structure and meaning of RSS to be used
inside XML documents other than RSS.  See: 
http://masonlee.org/2009/09/11/rsscloud-atom-extension/ as an example of one
such use.

Of course, RssBoard.org suggesting a namespace for easier embedding of RSS 2.0
elements would not affect RSS 2.0 in anyway.  RSS 2.0 documents would continue
to *require* no namespace.

This seems to me well within the scope of an organization like RSS board.

Cheers,

Mason Lee
http://masonlee.org

Direct quote from Dave, "I will join as a member, if you want me to, to help
give it legitimacy."

http://tech.groups.yahoo.com/group/rss-public/message/1374

Thanks,

Randy


--- In rss-public@yahoogroups.com, "dwiner" <dave.winer@...> wrote:
>
> 1. I'm pretty sure that Harvard University [1] owns the RSS 2.0 spec.
>
> 2. The Roadmap specifies terms under which you can modify the spec. It makes
no mention of an "Advisory Board."
>
> 3. I never considered joining this group.
>
> 4. It has no authority.
>
> [1] http://cyber.law.harvard.edu/rss/rss.html
>

On Tue, Sep 22, 2009 at 7:54 AM, dwiner <dave.winer@...> wrote:
> 2. The Roadmap specifies terms under which you can modify the spec.

The RSSCloud Interface has been a part of the specification since
1999. You're proposing to make changes to it, rather than doing new
work in a namespace.

Given that, why should anyone else interpret the roadmap to mean that
revisions to the spec are not allowed?

1. I'm pretty sure that Harvard University [1] owns the RSS 2.0 spec.

2. The Roadmap specifies terms under which you can modify the spec. It makes no
mention of an "Advisory Board."

3. I never considered joining this group.

4. It has no authority.

[1] http://cyber.law.harvard.edu/rss/rss.html

randymorin wrote:
> UPnP is not supported by many routers and is specifically disabled
> in Windows by default because of malware issues. This solution
> would only work, if a geek like me and you were at the helm.

The Windows firewall can be controlled programmatically as well, so in
theory that part is still feasible without geek intervention too. As for
UPnP support, I don't have any official stats, but I've seen some sources
claiming most home routers support it. Certainly I would expect more than
1%.

Also bare in mind that applications like BitTorrent and Instant Message (for
things like file transfers) rely on this sort of technology as well. That
means there's a reasonable chance that the average user's computer has
already been setup correctly by their friendly neighbourhood geek.

I don't expect this to work on every computer in every possible situation,
but I don't think it's anywhere near as problematic as you seem to think.
With a well written client I expect it to just work out of the box for most
people. Maybe I'm overly optimistic.

Regards
James

UPnP is not supported by many routers and is specifically disabled in Windows by
default because of malware issues. This solution would only work, if a geek like
me and you were at the helm. The user doesn't have to configure the router, but
he does have to configure Windows. It would not work in the majority of cases.
Further, most every public WiFi enabled router does not enable or support UPnP.

On both the corporate and NAT fronts. These are technically viable solutions
that you've presented. Neither works in the real world where an uber-geek is not
present. Neither are viable solutions as they will only work in the 1% case.

Thanks,

Randy

--- In rss-public@yahoogroups.com, "James Holderness" <j4_james@...> wrote:

> I'm using UPnP (Universal Plug and Play) - more specifically, the Internet
> Gateway Device protocol. On Windows, it's just a couple of lines of code.
> You can learn the external IP address (including notification of when that
> address changes) and add and remove port mappings on the router as you need
> them.
>

randymorin wrote:
> Can you elaborate on how you enabled NAT traversal?

I'm using UPnP (Universal Plug and Play) - more specifically, the Internet
Gateway Device protocol. On Windows, it's just a couple of lines of code.
You can learn the external IP address (including notification of when that
address changes) and add and remove port mappings on the router as you need
them.

> Firewalls are not only a technical problem, they are also an
> adoption problem. Most all large corporations have chosen not
> to open inbound ports thru firewalls.

The way I see it, the corporation has two choices. Either they don't want
their employees mucking about on twitter (and twitter-like protocols) all
day, in which case it's perfectly reasonable for them to block such
connections. Or, they consider real-time RSS feeds important to their
business in which case they'll find a way to make them work.

Now, assuming they want to make them work, I can see two options. Option one
would be to allow client applications to open ports in their firewalls as
necessary (using UPnP). I suspect their are security reasons which preclude
large corps from doing this, but I don't think it's unimaginable for smaller
companies.

Option two would be to invest in some kind of enterprise RSS gateway product
that handles the caching and forwarding of cloud notifications automatically
(not to mention caching of regular RSS content). Such a product may not yet
exist, but if this real-time feed thing really starts to take off, it could
be a great business opportunity.

Also, bare in mind that PSHB/PuSH has all the same problems as RSS cloud in
this regard, so they'll be looking for similar solutions.

Regards
James

* Geoffrey Sneddon <foolistbar@...> [2009-09-21 18:15]:
> The spec has several gaping holes, and nobody outside of the
> advisory board seems to care to try and fix them whatsoever…

Mr. Winer doesn’t *want* anyone to try and fix them. Atom was not
created because everyone wanted the glory of being spec authors
of yet another incompatible format, it was created reluctantly
because people wanted an interoperable feed format and RSS was
never going to be it on Mr. Winer’s emphatic insistence.

> why should I not also say authors must not create RSS
> documents, as they can create Atom documents which are far more
> interoperable?

Why indeed should you not?

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

On 20 Sep 2009, at 18:46, dwiner wrote:

> 3. Emphatically, this group is not a standards organization. It does
> not own RSS, or the spec, it has no more or less authority than any
> other group of people who wish to promote RSS.

Then who _does_ own the spec? You? Can you try and fix the gaping
holes in the spec then? The spec has several gaping holes, and nobody
outside of the advisory board seems to care to try and fix them
whatsoever…

To be a bit more explicit: one thing I've never managed to get
anywhere near the level of web compatibility I'd like in around four
years of leading development of SimplePie. The number one cause of
these problems are ambiguities in the spec: how can you ever expect
interoperability (which surely is the goal of a spec?) if it leaves
certain things (such as what the content of the title element is)
totally undefined?

If nobody is going to work on clarifying such gaping holes that make
it impossible to be interoperable, why should I not write a document
and call it "RSS 2.1", defining nothing more than what is defined in
the current RSS 2.0 specification? With such major interoperability
issues in RSS (like different UAs doing totally different things with
titles), why should I not also say authors must not create RSS
documents, as they can create Atom documents which are far more
interoperable?


--
Geoffrey Sneddon
<http://gsnedders.com/>
<http://simplepie.org/>

Dave,

The RSS Advisory Board is the only place to go for RSS help. James runs tests to
determine the usability of various RSS elements and knows more about the
usability of the RSS elements than anyone. Rogers answers almost every user
question. We wrote an RSS profile (Best Practices) and an RSS discovery
specification. The other members pop their heads in here from time-to-time to
help out as well. Support and promote RSS? That's what we do.

The board runs two public mailing lists; rss-board and rss-public. rss-board is
for board members only to post. rss-public is for everyone to post. If you (a
non-board member) want to post, then you post in rss-public. That's the way it
works.

You were on the board and quit. I thought we (Spring 2007) had a deal where you
would rejoin the board. Then you simply dropped out of the conversation and
ignored us.

You can't pop your head in here every two years and re-iterate the same
complaints over-and-over and expect for us to take you seriously. We've answered
your concerns several times already. If we reach a compromise again, will you
simply walk away from it again? Fool me once.

Thanks,

Randy


--- In rss-public@yahoogroups.com, "dwiner" <dave.winer@...> wrote:
>
> Briefly -- you're trying to be a standards body, a gatekeeper, and that's
wrong. Get to work and help out. Support and promote RSS. You're no more
authoritative than anyone else. And open up the rss-board list so anyone can
post to it. Then you might find you're all in the loop. Dave
>