I second and will initiate the discussion.

My understanding is that Apple is standing on firm legal ground when
they try to protect their iPod trademark. Podcast was clearly derived
from the term iPod and therefor the community at large made a big
trademark error. This fight might be unwinnable.

There is a win-lose, where Apple pays for being this stupid. Let's
make up a word to use instead of podcasting and rebrand. It'll create
initial confusion, I admit, but Apple will lose the word-of-mouth
marketing machine that bloggers created for it.
MHO,

Randy Charles Morin
http://www.kbcafe.com/rss



--- In rss-board@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> Since the terms were first coined in 2004, the words "podcast" and
> "podcasting" have been used generically to refer to audio or video
> files delivered as RSS enclosures.
>
> This usage became so popular that "podcasting" was declared the 2005
> word of the year by the editors of the New Oxford American
Dictionary. [1]
>
> That dictionary defines the term as "a digital recording of a radio
> broadcast or similar program, made available on the Internet for
> downloading to a personal audio player."
>
> In recent weeks, Apple Computer has begun to object to some uses of
> the term "podcast" as possible violations of its iPod trademark [2].
>
> I'd like to propose that the RSS Advisory Board affirm our strong
> belief that the terms podcast and podcasting refer generically to
> enclosure-delivered audio and video broadcasts and should not be
> claimed as exclusive trademarks by any entity.
>
> Additionally, the board will gather and publish evidence of generic
> use of these terms for the use of trademark examiners and anyone
else
> researching their use.
>
> If this proposal has a second, a one-week discussion of the proposal
> will be followed by a one-week vote.
>
> 1: http://makeashorterlink.com/?R2BA62BDD
> 2: http://makeashorterlink.com/?M1DA21BDD
>

In the early days, iPodder.org was retargeted as
indiepodder.org, the  iPodder the program was
retargeted as "Juice reciever" and "podcasting" was
interpreted as "Personal On Demand".

Wikipedia says this: The term gained wide popularity
as a portmanteau of iPod and broadcasting, but was
seen before that as an acronym for "portable on
demand".

Much to my dismay, I have seen it written that Apple
coined "podcast". ARRGGHH! This is absolutely not
true.

It appears there are several strategies including
1) make noise about it, referencing early definitions.

2) Make noise about a new term.

3) Attempt to understand the law and talk to the
receivers of the letters to understand the exact
nature of Apples complaint, rather than rely on
third-party reports.

I would vote for 3, then likely 1 (depending on how
"winnable" a fight would seem).

I would think press releases on the order of "Apple is
destroying "Podcasting" might help get the word out
among geeks, but among the rest of the population, I'm
not sure.

http://www.uspto.gov/web/offices/tac/doc/basic/trade_defin.htm

For reference "A trademark is a word, phrase, symbol
or design, or a combination of words, phrases, symbols
or designs, that identifies and distinguishes the
source of the goods of one party from those of
others."

IANAL, and it is my understanding that trademarks are
intended to prevent confusion in the marketplace about
the source of a product. Unfortunately, given Apple's
(smart) early embracing of podcasting in iTunes for
the iPod, prior to most people even hearing the term,
they have certainly not dissuaded the confusion. This
is even more exacerbated by some sites with a picture
of an iPod talking about podcasting.

Greg Smith


--- Randy Morin <randy@...> wrote:

> I second and will initiate the discussion.
>
> My understanding is that Apple is standing on firm
> legal ground when
> they try to protect their iPod trademark. Podcast
> was clearly derived
> from the term iPod and therefor the community at
> large made a big
> trademark error. This fight might be unwinnable.
>
> There is a win-lose, where Apple pays for being this
> stupid. Let's
> make up a word to use instead of podcasting and
> rebrand. It'll create
> initial confusion, I admit, but Apple will lose the
> word-of-mouth
> marketing machine that bloggers created for it.
> MHO,
>
> Randy Charles Morin
> http://www.kbcafe.com/rss
>
>
>
> --- In rss-board@yahoogroups.com, "rcade"
> <cadenhead@...> wrote:
> >
> > Since the terms were first coined in 2004, the
> words "podcast" and
> > "podcasting" have been used generically to refer
> to audio or video
> > files delivered as RSS enclosures.
> >
> > This usage became so popular that "podcasting" was
> declared the 2005
> > word of the year by the editors of the New Oxford
> American
> Dictionary. [1]
> >
> > That dictionary defines the term as "a digital
> recording of a radio
> > broadcast or similar program, made available on
> the Internet for
> > downloading to a personal audio player."
> >
> > In recent weeks, Apple Computer has begun to
> object to some uses of
> > the term "podcast" as possible violations of its
> iPod trademark [2].
> >
> > I'd like to propose that the RSS Advisory Board
> affirm our strong
> > belief that the terms podcast and podcasting refer
> generically to
> > enclosure-delivered audio and video broadcasts and
> should not be
> > claimed as exclusive trademarks by any entity.
> >
> > Additionally, the board will gather and publish
> evidence of generic
> > use of these terms for the use of trademark
> examiners and anyone
> else
> > researching their use.
> >
> > If this proposal has a second, a one-week
> discussion of the proposal
> > will be followed by a one-week vote.
> >
> > 1: http://makeashorterlink.com/?R2BA62BDD
> > 2: http://makeashorterlink.com/?M1DA21BDD
> >
>
>
>
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Wikipedia is a great source of misinformation. Podcasting was coined
shortly after the less glamourous iPod Platform, which was being
worked on my Winer and Curry. It did not come from "Personal On
Demand." That's likely someone trying to change history.
That's my recollection,

Randy Charles Morin
http://www.kbcafe.com/rss

--- In rss-board@yahoogroups.com, Greg Smith <ecomputerd@...> wrote:
>
> In the early days, iPodder.org was retargeted as
> indiepodder.org, the  iPodder the program was
> retargeted as "Juice reciever" and "podcasting" was
> interpreted as "Personal On Demand".
>
> Wikipedia says this: The term gained wide popularity
> as a portmanteau of iPod and broadcasting, but was
> seen before that as an acronym for "portable on
> demand".
>
> Much to my dismay, I have seen it written that Apple
> coined "podcast". ARRGGHH! This is absolutely not
> true.
>
> It appears there are several strategies including
> 1) make noise about it, referencing early definitions.
>
> 2) Make noise about a new term.
>
> 3) Attempt to understand the law and talk to the
> receivers of the letters to understand the exact
> nature of Apples complaint, rather than rely on
> third-party reports.
>
> I would vote for 3, then likely 1 (depending on how
> "winnable" a fight would seem).
>
> I would think press releases on the order of "Apple is
> destroying "Podcasting" might help get the word out
> among geeks, but among the rest of the population, I'm
> not sure.
>
> http://www.uspto.gov/web/offices/tac/doc/basic/trade_defin.htm
>
> For reference "A trademark is a word, phrase, symbol
> or design, or a combination of words, phrases, symbols
> or designs, that identifies and distinguishes the
> source of the goods of one party from those of
> others."
>
> IANAL, and it is my understanding that trademarks are
> intended to prevent confusion in the marketplace about
> the source of a product. Unfortunately, given Apple's
> (smart) early embracing of podcasting in iTunes for
> the iPod, prior to most people even hearing the term,
> they have certainly not dissuaded the confusion. This
> is even more exacerbated by some sites with a picture
> of an iPod talking about podcasting.
>
> Greg Smith
>
>

Randy,

Agreed. My recollection is similar to yours (though I
don't specifically remember "iPod Platform").
"Personal On Demand" and the renaming of iPodder.org
and iPodder program occured after some time had
passed. My impression at the time was that this was to
avoid any future run in with Apple. Curry, at a
minimum, was attempting to popularize "Portable On
Demand" long after Podcasting was coined and became
known in the geek crowd.

But really, this may all be unimportant depending on
exactly what Apple is claiming in its actions.

Greg Smith

--- Randy Morin <randy@...> wrote:

> Wikipedia is a great source of misinformation.
> Podcasting was coined
> shortly after the less glamourous iPod Platform,
> which was being
> worked on my Winer and Curry. It did not come from
> "Personal On
> Demand." That's likely someone trying to change
> history.
> That's my recollection,
>
> Randy Charles Morin
> http://www.kbcafe.com/rss
>
> --- In rss-board@yahoogroups.com, Greg Smith
> <ecomputerd@...> wrote:
> >
> > In the early days, iPodder.org was retargeted as
> > indiepodder.org, the  iPodder the program was
> > retargeted as "Juice reciever" and "podcasting"
> was
> > interpreted as "Personal On Demand".
> >
> > Wikipedia says this: The term gained wide
> popularity
> > as a portmanteau of iPod and broadcasting, but was
> > seen before that as an acronym for "portable on
> > demand".
> >
> > Much to my dismay, I have seen it written that
> Apple
> > coined "podcast". ARRGGHH! This is absolutely not
> > true.
> >
> > It appears there are several strategies including
> > 1) make noise about it, referencing early
> definitions.
> >
> > 2) Make noise about a new term.
> >
> > 3) Attempt to understand the law and talk to the
> > receivers of the letters to understand the exact
> > nature of Apples complaint, rather than rely on
> > third-party reports.
> >
> > I would vote for 3, then likely 1 (depending on
> how
> > "winnable" a fight would seem).
> >
> > I would think press releases on the order of
> "Apple is
> > destroying "Podcasting" might help get the word
> out
> > among geeks, but among the rest of the population,
> I'm
> > not sure.
> >
> >
>
http://www.uspto.gov/web/offices/tac/doc/basic/trade_defin.htm
> >
> > For reference "A trademark is a word, phrase,
> symbol
> > or design, or a combination of words, phrases,
> symbols
> > or designs, that identifies and distinguishes the
> > source of the goods of one party from those of
> > others."
> >
> > IANAL, and it is my understanding that trademarks
> are
> > intended to prevent confusion in the marketplace
> about
> > the source of a product. Unfortunately, given
> Apple's
> > (smart) early embracing of podcasting in iTunes
> for
> > the iPod, prior to most people even hearing the
> term,
> > they have certainly not dissuaded the confusion.
> This
> > is even more exacerbated by some sites with a
> picture
> > of an iPod talking about podcasting.
> >
> > Greg Smith
> >
> >
>
>
>
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Just a quick note: if you're going to the Podcast Expo
in California this Friday/Saturday, look me up I'll be
in the FeederReader booth.

Here's my "on topic" part:

It seems to me after reading the Engadget article,
that Apple is not claiming anything about "podcast" or
"podcasting" but they are claiming that "myPodder"
sounds too much like "iPod". And that "Apple objects
to 'Podcast Ready' trademark applications which cover
'portable listening devices' and 'software to manage
digital content for portable media players,'" though
they specifically do not object to the generic use of
the term "podcast" (I think). If I read the article
correctly, Apple seems to object to the use of
"Podcast Ready" applications which cover "portable
listening devices" and "software to manage digital
content for portable media players". I took this to
mean they object to the actual phrase "Podcast Ready"
(this is my presumption, but I don't know if it is
correct).

So I'm not sure if there's anything here for us to
actually do.

As far as coming out and saying "podcast" and
"podcasting" are generic terms. Great! It seems Apple
agrees with that already. But does that affect any
claims on trademarks that sound like "iPod" or refer
to "portable media devices".

One thing that's not clear from the article is whether
Apple is claiming anything that has "pod" in the name
and refers to "portable listening devices" or"software
to manage digital content for portable media players".
If Apple had their way (given my presumption!) this
would preclude any trademarking of "podcast" or
"podcasting" within a name for software or devices
designed for portable media playing. This seems
similar to "Coca Cola" objecting to "RC Cola" or
"Pepsi Cola" because they all contain "Cola" and, if
my presumption is correct, seems like an absurd claim
by Apple.

Do these observations help move us along to any sort
of resolution?

Greg Smith

--- rcade <cadenhead@...> wrote:

In recent weeks, Apple Computer has begun to object to
some uses of
the term "podcast" as possible violations of its iPod
trademark [2].

I'd like to propose that the RSS Advisory Board affirm
our strong
belief that the terms podcast and podcasting refer
generically to
enclosure-delivered audio and video broadcasts and
should not be
claimed as exclusive trademarks by any entity.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

--- In rss-board@yahoogroups.com, Greg Smith <ecomputerd@...> wrote:
> Just a quick note: if you're going to the Podcast Expo
> in California this Friday/Saturday, look me up I'll be
> in the FeederReader booth.

Thanks. I hope that other board members will let us know when they're
going to upcoming conferences or launching new products and services,
because I'd like to note that on our blog.

> So I'm not sure if there's anything here for us to
> actually do.

We're not equipped to make legal distinctions, but my thinking is that
by documenting the generic use of "podcast" and "podcasting" since the
terms were coined, the board can serve as a resource for any future
trademark examinations related to those terms. (This would be similar
to documenting prior art in a patent situation.)

We also can help reinforce the use of these two terms by the public to
describe enclosure-based media publishing.

Though an Apple official said the company does not object to
"podcast," the opposition to the "Podcast Ready" trademark appears to
suggest otherwise.

I'm not unsympathetic to Apple's attempt to protect its iPod trademark
-- products like MyPodder and the since-renamed Ipodder podcast client
do seem confusingly similar in my opinion -- but podcast has become
too popular as a generic term in the last two years for it to be
claimed today as an infringement.

A Yahoo/Ipsos Insight poll in October 2005 [1] found that 28% of
Internet users are aware of podcasting. Rechristening it "netcasting"
or something else -- as Randy has suggested on his blog -- drops that
awareness back down to 0.

1: http://publisher.yahoo.com/rss/RSS_whitePaper1004.pdf

James Holderness and Paul Querna have joined the RSS Advisory Board:

http://www.rssboard.org/news/65

Welcome to the group!

--- In rss-board@yahoogroups.com, "rcade" <cadenhead@...> wrote:
> I'd like to propose that the RSS Advisory Board affirm our strong
> belief that the terms podcast and podcasting refer generically to
> enclosure-delivered audio and video broadcasts and should not be
> claimed as exclusive trademarks by any entity.
>
> Additionally, the board will gather and publish evidence of generic
> use of these terms for the use of trademark examiners and anyone else
> researching their use.

As the proponent, I'm withdrawing this proposal before the vote
begins. I'd like to see whether alternate terms such as netcasting and
feedcasting gain any traction.

In the 2.5 years I've been a member of the RSS Advisory Board, three
questions have been asked most often by programmers having difficulty
interpreting the RSS 2.0 specification:

1. Can an item contain more than one enclosure?

2. What elements are allowed to contain HTML?

3. How do I deal with relative URLs?

I think it's time that the board answered them.

In February, work began on a new, written-from-scratch draft of the
specification, with each revision announced and vetted on the
RSS-Public mailing list. The main contributors to the draft are four
members of the board and one of the lead developers of the Feed
Validator: James Holderness, Randy Charles Morin, Sam Ruby, Greg Smith
and myself.

The new draft documents the same elements and attributes described in
RSS 2.0 (version 2.0.8), the current spec, making no changes to the
requirements upon which RSS creators Dan Libby and Dave Winer sparked
the incredibly successful RSS boom. No elements have been added or
removed.

It does clarify the RSS specification in the three areas mentioned
above, based on our interpretation of the current spec and its
predecessors:

1. An item cannot contain more than one enclosure. The only RSS
element that can be present more than once in an item is category.

2. The only RSS element that can contain HTML is an item's description.

3. Relative URLs are not allowed. When they're encountered in an
item's description -- which is not recommended -- the feed's link
element should be used as the base URL.

Though we could answer these three questions by editing the current
spec, this draft should be easier to interpret because it follows the
rules of RFC 2119, a standard for spec writers that dictates exactly
what words like "must", "may" and "should" mean when they appear in a
technical document.

It also has been through a thorough and open review process that
included 11 revisions to the draft and 13 revisions to a companion
document still under development, the RSS Profile.

I propose that the RSS Advisory Board adopt the following document as
version 2.0.9 of the RSS 2.0 specification:

http://www.rssboard.org/rss-draft-1

If this proposal is seconded, the seven-day discussion period will be
used to fix mistakes, address concerns and make other minor edits to
this draft. When the vote begins, I'll report to the board on the
changes that were made and publish the final draft at the above URL
for consideration.

I agree substantially with moving in this direction,
though as I recall the conclusions *I made in my head
(and argued heavily for at the time)* were

1) Multiple enclosures are allowed because a) the
original specification was ambiguous, b) some
implementations used it, and c) I did not want to
break backward compatibility. At the time, I settled
on zero or one enclosure is RECOMMENDED, more are
possible, and client handling is not guaranteed,
though clients should not crash. Didn't we have an
entire fruitful discussion of SHOULD/MAY/RECOMMEND
over this particular issue?

2) I have seen HTML within title elements, and I think
there is good reason to allow them (in part for
backward compatibility, and in part for visual
flexibility), though many clients may not properly
display them.

3) I don't recall the discussion on relative links
relative to the "link" element, but there may be
reason to allow links relative to the actual URL of
the RSS Feed. This could be very useful when dealing
with "file://" URLs. I can see situations where it
would be beneficial to use as the BASE URL either a)
LINK element or b) retreived RSS Feed URL would be
useful. For example, situations where the feed is
copied to another URL. It might be useful to use the
LINK element. If all related files are copied to a
different location with the same hierarchy, then (b)
would be useful because the files could be copied
unmodified.

Greg Smith

--- rcade <cadenhead@...> wrote:

> In the 2.5 years I've been a member of the RSS
> Advisory Board, three
> questions have been asked most often by programmers
> having difficulty
> interpreting the RSS 2.0 specification:
>
> 1. Can an item contain more than one enclosure?
>
> 2. What elements are allowed to contain HTML?
>
> 3. How do I deal with relative URLs?
>
> I think it's time that the board answered them.
>
> In February, work began on a new,
> written-from-scratch draft of the
> specification, with each revision announced and
> vetted on the
> RSS-Public mailing list. The main contributors to
> the draft are four
> members of the board and one of the lead developers
> of the Feed
> Validator: James Holderness, Randy Charles Morin,
> Sam Ruby, Greg Smith
> and myself.
>
> The new draft documents the same elements and
> attributes described in
> RSS 2.0 (version 2.0.8), the current spec, making no
> changes to the
> requirements upon which RSS creators Dan Libby and
> Dave Winer sparked
> the incredibly successful RSS boom. No elements have
> been added or
> removed.
>
> It does clarify the RSS specification in the three
> areas mentioned
> above, based on our interpretation of the current
> spec and its
> predecessors:
>
> 1. An item cannot contain more than one enclosure.
> The only RSS
> element that can be present more than once in an
> item is category.
>
> 2. The only RSS element that can contain HTML is an
> item's description.
>
> 3. Relative URLs are not allowed. When they're
> encountered in an
> item's description -- which is not recommended --
> the feed's link
> element should be used as the base URL.
>
> Though we could answer these three questions by
> editing the current
> spec, this draft should be easier to interpret
> because it follows the
> rules of RFC 2119, a standard for spec writers that
> dictates exactly
> what words like "must", "may" and "should" mean when
> they appear in a
> technical document.
>
> It also has been through a thorough and open review
> process that
> included 11 revisions to the draft and 13 revisions
> to a companion
> document still under development, the RSS Profile.
>
> I propose that the RSS Advisory Board adopt the
> following document as
> version 2.0.9 of the RSS 2.0 specification:
>
> http://www.rssboard.org/rss-draft-1
>
> If this proposal is seconded, the seven-day
> discussion period will be
> used to fix mistakes, address concerns and make
> other minor edits to
> this draft. When the vote begins, I'll report to the
> board on the
> changes that were made and publish the final draft
> at the above URL
> for consideration.
>
>
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

--- In rss-board@yahoogroups.com, Greg Smith <ecomputerd@...> wrote:
> 1) Multiple enclosures are allowed because a) the
> original specification was ambiguous, b) some
> implementations used it, and c) I did not want to
> break backward compatibility. At the time, I settled
> on zero or one enclosure is RECOMMENDED, more are
> possible, and client handling is not guaranteed,
> though clients should not crash. Didn't we have an
> entire fruitful discussion of SHOULD/MAY/RECOMMEND
> over this particular issue?

I'll support any direction the board wants to go on these three
questions, but I don't think we should change requirements in the spec
in response to usage. We ought to decide what we think the spec means
and encourage others to support that interpretation.

Here's why I think that an item can have no more than one enclosure:

1. The current spec [1] explicitly states that five elements can be
present more than once within their parent: item, channel-category,
item-category, skipHours-hour and skipDays-day. It does not state that
enclosure can be present more than once.

2. The spec links to a use-case narrative for enclosure [2] that
associates one enclosure with one item:

"With the addition of the <enclosure> sub-element of <item> any RSS
element can describe a video or audio file (actually any type of file)."

1: http://www.rssboard.org/rss-specification
2: http://www.thetwowayweb.com/payloadsforrss

--- In rss-board@yahoogroups.com, Greg Smith <ecomputerd@...> wrote:
> 2) I have seen HTML within title elements, and I think
> there is good reason to allow them (in part for
> backward compatibility, and in part for visual
> flexibility), though many clients may not properly
> display them.

Here's my take on why item-description is the only element that allows
HTML:

1. RSS 0.91 [1] explicitly prohibited HTML markup in RSS aside from 96
HTML entities in the RSS 0.91 DTD [2].

"We also are not allowing any HTML markup beyond the commonly used
entities such as " A full list of these are defined in the RSS
0.91 DTD."

2. RSS 0.92 [3] explicitly changed the requirements for
item-description to allow HTML.

"Further, 0.92 allows entity-encoded HTML in the <description> of an
item, to reflect actual practice by bloggers, who are often proficient
HTML coders."

3. No requirements regarding HTML markup have been changed or
introduced in any subsequent versions, so all other elements in RSS
2.0 still follows the prohibition against HTML markup established in
RSS 0.91.

1: http://www.rssboard.org/rss-0-9-1-netscape
2: http://www.rssboard.org/rss-0-9-1-netscape#dtd
3: http://www.rssboard.org/rss-0-9-2

--- In rss-board@yahoogroups.com, Greg Smith <ecomputerd@...> wrote:
> 3) I don't recall the discussion on relative links
> relative to the "link" element ...

That part of the spec is pretty clear. All link and url elements must
begin with an official URI scheme such as http:// or https://:

http://www.rssboard.org/rss-specification#comments

The URI scheme link is broken. Here's the official list:

http://www.iana.org/assignments/uri-schemes.html

I don't know which URI schemes permit relative URLs.

> I can see situations where it would be beneficial to use as the BASE
> URL either a) LINK element or b) retreived RSS Feed URL would be
> useful.

I can, too, but relative URLs require a base URL, and there's nothing
in the spec that explicitly designates a base URL.

In our discussion of the issue on RSS-Public, the best solution we
came up with was to tell publishers they SHOULD NOT use relative URLs
and tell aggregators that when they find one in an item description,
they SHOULD use channel-link as the best guess on the base URL.

"We ought to decide what we think the spec means and
encourage others to support that interpretation." I
agree completely.

Here's my point-by-point interpretation of the RSS
specification regarding multiple enclosures:
http://tech.groups.yahoo.com/group/rss-public/message/312

I agree that the deployment should not dictate the
specification, except to the extent that deployment is
a proxy for the common interpretation of the
specification where the specification is ambiguous. My
main point is that the original specification is
ambiguous at best and reasonable people have already
implemented and deployed both single and
mulitple-enclosure implementations.

Regarding the current deployment of RSS generator
software and SHOULD vs. MUST
http://tech.groups.yahoo.com/group/rss-public/message/337
http://tech.groups.yahoo.com/group/rss-public/message/319

Greg Smith


--- rcade <cadenhead@...> wrote:

> --- In rss-board@yahoogroups.com, Greg Smith
> <ecomputerd@...> wrote:
> > 1) Multiple enclosures are allowed because a) the
> > original specification was ambiguous, b) some
> > implementations used it, and c) I did not want to
> > break backward compatibility. At the time, I
> settled
> > on zero or one enclosure is RECOMMENDED, more are
> > possible, and client handling is not guaranteed,
> > though clients should not crash. Didn't we have an
> > entire fruitful discussion of SHOULD/MAY/RECOMMEND
> > over this particular issue?
>
> I'll support any direction the board wants to go on
> these three
> questions, but I don't think we should change
> requirements in the spec
> in response to usage. We ought to decide what we
> think the spec means
> and encourage others to support that interpretation.
>
> Here's why I think that an item can have no more
> than one enclosure:
>
> 1. The current spec [1] explicitly states that five
> elements can be
> present more than once within their parent: item,
> channel-category,
> item-category, skipHours-hour and skipDays-day. It
> does not state that
> enclosure can be present more than once.
>
> 2. The spec links to a use-case narrative for
> enclosure [2] that
> associates one enclosure with one item:
>
> "With the addition of the <enclosure> sub-element of
> <item> any RSS
> element can describe a video or audio file (actually
> any type of file)."
>
> 1: http://www.rssboard.org/rss-specification
> 2: http://www.thetwowayweb.com/payloadsforrss
>
>
>
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

While I haven't personally reviewed all your
statements here regarding the specification, I have no
reason to disbelieve them.

I think you're saying the specification granted HTML
in the form of ENTITY statements.

Even though the ENTITY statements and their use are
similar to HTML entities, they are not HTML. Saying
that RSS allows the characters defined by the XML
ENTITY statements within RSS is redundant. As far as I
can tell, characters defined by XML ENTITY statements
are technically allowed (by the XML specification)
anywhere within the XML (if I recall correctly, except
perhaps within ELEMENTs). These are presumably
interpreted by an XML processor prior to
interpretation in an RSS processor.

Please correct me if I'm wrong regarding HTML vs. XML!

In practical terms, the XML ENTITY characters are
better inserted by using an appropriate encoding
(Unicode support, for example, is required of XML
processors). The HTML in TITLEs that I have seen are
tags such as italics <i>, emphasis <em>, strong
<strong>, and bold <b>.

ENTITY statements in XML are essentially which are
really defined within the XML specification. In my
opinion we should be clear (maybe it is already?)
regarding the RSS specification relative to the XML
specification.

My argument is much more pragmatic, though I'm not
sure I present a strong enough case for "HTML allowed
in TITLE elements" to be writtin into the
specification. The bottom line is HTML will continue
to exist in titles regardless of what the
specification says.

With these points in mind, whatever the specification
ends up saying, there should be clear guidance in the
RSS Profile to client implementations of RSS to allow
HTML tags in (at a minimum) TITLE RSS elements.

Though "allowing the option" of HTML presents its own
set of difficulties, particularly in how many times to
"process" the TITLE text through an HTML processor. A
simple way to express the difficulty: As a creator of
the TITLE element, how do I ensure that the title
displays literally as "Is 1 < 2?" or "This <I>
believe."

I think James Holderness may have done a survey
regarding client implementations. Anyone have a link?

Greg Smith

--- rcade <cadenhead@...> wrote:

> --- In rss-board@yahoogroups.com, Greg Smith
> <ecomputerd@...> wrote:
> > 2) I have seen HTML within title elements, and I
> think
> > there is good reason to allow them (in part for
> > backward compatibility, and in part for visual
> > flexibility), though many clients may not properly
> > display them.
>
> Here's my take on why item-description is the only
> element that allows
> HTML:
>
> 1. RSS 0.91 [1] explicitly prohibited HTML markup in
> RSS aside from 96
> HTML entities in the RSS 0.91 DTD [2].
>
> "We also are not allowing any HTML markup beyond the
> commonly used
> entities such as " A full list of these are
> defined in the RSS
> 0.91 DTD."
>
> 2. RSS 0.92 [3] explicitly changed the requirements
> for
> item-description to allow HTML.
>
> "Further, 0.92 allows entity-encoded HTML in the
> <description> of an
> item, to reflect actual practice by bloggers, who
> are often proficient
> HTML coders."
>
> 3. No requirements regarding HTML markup have been
> changed or
> introduced in any subsequent versions, so all other
> elements in RSS
> 2.0 still follows the prohibition against HTML
> markup established in
> RSS 0.91.
>
> 1: http://www.rssboard.org/rss-0-9-1-netscape
> 2: http://www.rssboard.org/rss-0-9-1-netscape#dtd
> 3: http://www.rssboard.org/rss-0-9-2
>
>
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

I do want to point out an interesting dichotomy. With
respect to relative URLs, the "spec is pretty clear"
yet we are suggesting to define it as a "SHOULD". But
where the spec is arguably unclear on the topic of
multiple enclosures, we are suggesting to define it as
a "MUST" and disregarding (or maybe disagreeing on)
the ambiguity.

I am much more passionate on the multiple enclosures
issue because I truly think it is ambiguous (in part
because "multiple" is the way I interpreted and
implemented it).

If we really want to not "change" the specification
and the specification "is pretty clear" it seems to me
we should define it as a MUST and issue the guidance
on the BASE URL in the RSS Profile.

[stream of thought]
Regarding the BASE URL, as an implementor the most
obvious to me is to interpret it first as relative to
the actual Feed URL and if that fails, then as
relative to the LINK element. This would allow
wholesale copying/moving of a group of files. I could
see both ways because as the writer of an RSS feed,
obviously you want a "stable" and definable BASE URL.
But if this were really the case, you should simply
write non-relative URLs within the feed. The only case
where relative URLs are actually beneficial is during
a non-modifying copy/move. If you are actually going
to go in and modify an RSS LINK element, you might as
well modify all URLs within the file, too.

Based on this line of thinking, I would say that the
BASE URL should be the actual current URL of the RSS
file. This then gets compliated in the case of a
redirect to the RSS Feed. On the one hand, if the
redirected-from URL is used, the redirector should be
preprated to redirect (or satisfy) all requests based
on the relative URL. The other option is to use the
redirected-to URL where it is presumed that the
"related files" (those that are referred to using
relative URLs) are still accessible.

Which for an client implementor implies the following
hierarchy for relative URLs:
1) Actual Feed URL (aka "Redirected-from URL", if
redirected)
2) Redirect-to URL
3) LINK element

The only caution is that the request may get
inadvertantly satisfied if the client tries cases 1
and/or 2 and where the server implementor assumed case
3.

In all of this, I would also allow for "file://"
schemes where the set of files is available locally.
Or is this scheme specifically prohibited in RSS?

Like a good lawyer, I'll "argue" across all fronts:
"Don't allow it", "when it occurs, interpret it this
way" ;-)

Greg Smith

--- rcade <cadenhead@...> wrote:

> --- In rss-board@yahoogroups.com, Greg Smith
> <ecomputerd@...> wrote:
> > 3) I don't recall the discussion on relative links
> > relative to the "link" element ...
>
> That part of the spec is pretty clear. All link and
> url elements must
> begin with an official URI scheme such as http:// or
> https://:
>
> http://www.rssboard.org/rss-specification#comments
>
> The URI scheme link is broken. Here's the official
> list:
>
> http://www.iana.org/assignments/uri-schemes.html
>
> I don't know which URI schemes permit relative URLs.
>
> > I can see situations where it would be beneficial
> to use as the BASE
> > URL either a) LINK element or b) retreived RSS
> Feed URL would be
> > useful.
>
> I can, too, but relative URLs require a base URL,
> and there's nothing
> in the spec that explicitly designates a base URL.
>
> In our discussion of the issue on RSS-Public, the
> best solution we
> came up with was to tell publishers they SHOULD NOT
> use relative URLs
> and tell aggregators that when they find one in an
> item description,
> they SHOULD use channel-link as the best guess on
> the base URL.
>
>
>
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

--- In rss-board@yahoogroups.com, Greg Smith <ecomputerd@...> wrote:
> I do want to point out an interesting dichotomy. With
> respect to relative URLs, the "spec is pretty clear"
> yet we are suggesting to define it as a "SHOULD". But
> where the spec is arguably unclear on the topic of
> multiple enclosures, we are suggesting to define it as
> a "MUST" and disregarding (or maybe disagreeing on)
> the ambiguity.

The draft spec is still clear that link and url elements MUST begin
with a base URI:

http://www.rssboard.org/rss-draft-1#data-types-url

"In all link and url elements, the first non-whitespace characters in
a URL must begin with a scheme defined by the IANA Registry of URI
Schemes ..."

The SHOULD/MAY stuff only covers relative URLs in an item description:

http://www.rssboard.org/rss-draft-1#element-channel-item-description

"The description SHOULD NOT contain relative URLs. When a relative URL
is present, an aggregator MAY attempt to resolve it to a full URL
using the channel's link as the base."

Well, I can tell you all that what Rogers proposes for the
interpretation of these three questions exactly match the assumptions
that FeedBurner makes about RSS 2.0 feeds. We only support a single
enclosure per item, we assume that description is the only core
element that can contain HTML, and we make no attempt to handle or
resolve relative URLs (even though the base feed URL is modified when
it flows through the app).

So, if I go under the assumption that the least amount of work is the
best answer (a personal philosophy that gets me in trouble at home all
the time), I agree with and support Rogers proposals here.

Eric

--- In rss-board@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> In the 2.5 years I've been a member of the RSS Advisory Board, three
> questions have been asked most often by programmers having difficulty
> interpreting the RSS 2.0 specification:
>
> 1. Can an item contain more than one enclosure?
>
> 2. What elements are allowed to contain HTML?
>
> 3. How do I deal with relative URLs?
>
> I think it's time that the board answered them.
>
> In February, work began on a new, written-from-scratch draft of the
> specification, with each revision announced and vetted on the
> RSS-Public mailing list. The main contributors to the draft are four
> members of the board and one of the lead developers of the Feed
> Validator: James Holderness, Randy Charles Morin, Sam Ruby, Greg Smith
> and myself.
>
> The new draft documents the same elements and attributes described in
> RSS 2.0 (version 2.0.8), the current spec, making no changes to the
> requirements upon which RSS creators Dan Libby and Dave Winer sparked
> the incredibly successful RSS boom. No elements have been added or
> removed.
>
> It does clarify the RSS specification in the three areas mentioned
> above, based on our interpretation of the current spec and its
> predecessors:
>
> 1. An item cannot contain more than one enclosure. The only RSS
> element that can be present more than once in an item is category.
>
> 2. The only RSS element that can contain HTML is an item's description.
>
> 3. Relative URLs are not allowed. When they're encountered in an
> item's description -- which is not recommended -- the feed's link
> element should be used as the base URL.
>
> Though we could answer these three questions by editing the current
> spec, this draft should be easier to interpret because it follows the
> rules of RFC 2119, a standard for spec writers that dictates exactly
> what words like "must", "may" and "should" mean when they appear in a
> technical document.
>
> It also has been through a thorough and open review process that
> included 11 revisions to the draft and 13 revisions to a companion
> document still under development, the RSS Profile.
>
> I propose that the RSS Advisory Board adopt the following document as
> version 2.0.9 of the RSS 2.0 specification:
>
> http://www.rssboard.org/rss-draft-1
>
> If this proposal is seconded, the seven-day discussion period will be
> used to fix mistakes, address concerns and make other minor edits to
> this draft. When the vote begins, I'll report to the board on the
> changes that were made and publish the final draft at the above URL
> for consideration.
>

rcade wrote:
> 1. An item cannot contain more than one enclosure. The only RSS
> element that can be present more than once in an item is category.
>
> 2. The only RSS element that can contain HTML is an item's description.
>
> 3. Relative URLs are not allowed. When they're encountered in an
> item's description -- which is not recommended -- the feed's link
> element should be used as the base URL.

If I were forced to guess the intention of the original spec regarding these
issues I'd probably reach the same conclusions. However, I don't think that
clarifying those intentions in an ammended spec is necessarily a good thing.
I'll explain why.

The first problem is that the RSS roadmap does not permit changes. While
these clarifications may seem like the most likely interpretations, they are
still interpretations. Writing one particular interpretation into the spec,
no matter how right we think it is, is going to be considered a change by
someone. Remember Dave's words:

"[The spec] *has* to remain ambiguous, because the roadmap says so. It takes
the decision out of everyone's hands, no one can change the spec, because
the SPEC SAYS IT CAN'T BE CHANGED." [1]

If we try and do this, you can be sure there's going to be a fight. Do we
really want to go through that again?

Secondly, even if the roadmap allowed this, I don't think the proposed
clarifications are particularly useful (accurate, maybe, but not useful).
Without the extra information that the profile provides about current usages
and best practice, these changes can actually be counter-productive.

Consider this scenario: You're an aggregator author adding support for
enclosures to your client. Looking at the original spec you're unsure if
more than one is allowed, so to be on the safe side you support multiple
anyway. This works out great, since even though producers shouldn't be
including multiple enclosures, there are some that do.

Now let's say the spec had been updated to clarify that only a single
enclosure was allowed. No room for doubt now, so you feel comfortable hard
coding a limit of one enclosure for RSS feeds. But now your product fails to
support all those feeds that include multiple enclosures. It doesn't seem
like that clarification has helped you much does it?

The clarification regarding HTML outside item/descriptions suffers from the
same problem. The clarifiction of relative URLs is the only one that
provides useful guidance, and ironically that's the biggest change from the
original spec (the concept of using the feed link as a base URL, while
useful, is a completely new idea).

In short: I like the direction that the profile is going and I think it can
be tremendously useful to both feed producers and aggregator authors.
However I'm not convinced that revising the spec as proposed is a good idea.

Regards
James

[1] http://tech.groups.yahoo.com/group/rss-public/message/360

--- In rss-board@yahoogroups.com, "James Holderness" <j4_james@...> wrote:
> The first problem is that the RSS roadmap does not permit changes.

It's within the board's discretion to decide that the roadmap does not
permit us to touch anything in the spec that affects the
interpretation of RSS. We could leave the language in version 2.0.8
alone, announce that we won't change element or attribute definitions
in any way, and leave these three questions unanswered.

My position is that the roadmap [1] permits the kind of clarifications
we're discussing here:

1: http://www.rssboard.org/rss-specification#roadmap

"We anticipate possible 2.0.2 or 2.0.3 versions, etc. only for the
purpose of clarifying the specification, not for adding new features
to the format."

The argument that the roadmap forces the spec to "remain ambiguous"
wasn't the policy of the board in 2004, when aggregator developers
asked for guidance on how to properly encode HTML in item
descriptions. We voted to add encoding examples:

http://www.rssboard.org/rss-encoding-examples

As I said back then, I think respecting the roadmap means sticking to
the existing element and attribute set and all requirements that are
clearly specified, not freezing the spec language so that we have no
way to deal with errors, oversights and poorly understood requirements
that require clarification.

Greg Smith wrote:
> The HTML in TITLEs that I have seen are
> tags such as italics <i>, emphasis <em>, strong
> <strong>, and bold <b>.

The most common place that I've seen HTML titles is in search results. Try
doing a search on Bloglines or the Google blog search for a term that's
likely to show up in the title and have a look at their RSS feeds. Both of
them markup any matching keywords in bold. I'm sure there are other search
engines that do that too.

> The bottom line is HTML will continue
> to exist in titles regardless of what the
> specification says.

Agreed.

> I think James Holderness may have done a survey
> regarding client implementations. Anyone have a link?

http://www.詹姆斯.com/blog/2006/06/encoding-rss-titles

No guarantees that those results are still valid though.

Regards
James

The draft spec has been revised to take a more conservative approach
on enclosures and HTML markup.

http://www.rssboard.org/rss-draft-1

In both cases, the draft offers our clarification in the form of a
suggestion, not a requirement.

Enclosures

http://www.rssboard.org/rss-draft-1#element-channel-item-enclosure

"For best support in the widest number of aggregators, publishers
SHOULD NOT include more than one enclosure in an item.

"Because some popular RSS implementations support multiple enclosures,
aggregators SHOULD expect to encounter feeds where more than one
enclosure is present in an item. Aggregators MAY use their discretion
to handle all of the enclosures or just the first enclosure present
within an item."

Character Data

http://www.rssboard.org/rss-draft-1#data-types-characterdata

"For all elements defined in this specification that enclose character
data, publishers should format the data as plain text with the
exception of an item's description element, which must be suitable for
presentation as HTML. ...

"Although some publishers employ HTML markup in other elements such as
an item's title, using plain text in those elements achieves the
widest support in aggregators."

This approach follows Postel's Law: "be conservative in what you do,
be liberal in what you accept from others."

I think it's a solid approach to two difficult situations for RSS
implementers. The board suggests the best course for maximum
interoperability without causing any present RSS feeds to become invalid.

Here's the exact rundown of changes:

1. Dropped this sentence from item:

The preceding elements MUST NOT be present more than once in an item,
with the exception of category.

http://www.rssboard.org/rss-draft-1#element-channel-item

2. Added these sentences to item-enclosure:

For best support in the widest number of aggregators, publishers
SHOULD NOT include more than one enclosure in an item.

Because some popular RSS implementations support multiple enclosures,
aggregators SHOULD expect to encounter feeds where more than one
enclosure is present in an item. Aggregators MAY use their discretion
to handle all of the enclosures or just the first enclosure present
within an item.

http://www.rssboard.org/rss-draft-1#element-channel-item-enclosure

3. Revised the first sentence of the character data section to this:

For all elements defined in this specification that enclose character
data, publishers SHOULD format the data as plain text with the
exception of an item's description element, which MUST be suitable for
presentation as HTML.

http://www.rssboard.org/rss-draft-1#data-types-characterdata

4. Added this sentence to the same section:

Although some publishers employ HTML markup in other elements such as
an item's title, using plain text in those elements achieves the
widest support in aggregators.

5. Added links in element descriptions to the Character Data, Dates
and Times, and URLs sections.

I like, in theory, taking the Postel's Law approach for the multiple
enclosures issue, but it still gives me pause to see "aggregators SHOULD
expect to encounter feeds where more than one enclosure is present in an
item". I mean, I agree that clients shouldn't break when they encounter
feeds with multiple enclosure elements, but I think the expectations
should be very, very low that an aggregator will do anything useful with
anything beyond the first enclosure. Is there any way to convey that?

So, with that one slight reservation, I agree with and like the
clarifications you've made here.

--- In rss-board@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> The draft spec has been revised to take a more conservative approach
> on enclosures and HTML markup.
>
> http://www.rssboard.org/rss-draft-1
>
> In both cases, the draft offers our clarification in the form of a
> suggestion, not a requirement.
>
> Enclosures
>
> http://www.rssboard.org/rss-draft-1#element-channel-item-enclosure
>
> "For best support in the widest number of aggregators, publishers
> SHOULD NOT include more than one enclosure in an item.
>
> "Because some popular RSS implementations support multiple enclosures,
> aggregators SHOULD expect to encounter feeds where more than one
> enclosure is present in an item. Aggregators MAY use their discretion
> to handle all of the enclosures or just the first enclosure present
> within an item."
>
> Character Data
>
> http://www.rssboard.org/rss-draft-1#data-types-characterdata
>
> "For all elements defined in this specification that enclose character
> data, publishers should format the data as plain text with the
> exception of an item's description element, which must be suitable for
> presentation as HTML. ...
>
> "Although some publishers employ HTML markup in other elements such as
> an item's title, using plain text in those elements achieves the
> widest support in aggregators."
>
> This approach follows Postel's Law: "be conservative in what you do,
> be liberal in what you accept from others."
>
> I think it's a solid approach to two difficult situations for RSS
> implementers. The board suggests the best course for maximum
> interoperability without causing any present RSS feeds to become
invalid.
>
> Here's the exact rundown of changes:
>
> 1. Dropped this sentence from item:
>
> The preceding elements MUST NOT be present more than once in an item,
> with the exception of category.
>
> http://www.rssboard.org/rss-draft-1#element-channel-item
>
> 2. Added these sentences to item-enclosure:
>
> For best support in the widest number of aggregators, publishers
> SHOULD NOT include more than one enclosure in an item.
>
> Because some popular RSS implementations support multiple enclosures,
> aggregators SHOULD expect to encounter feeds where more than one
> enclosure is present in an item. Aggregators MAY use their discretion
> to handle all of the enclosures or just the first enclosure present
> within an item.
>
> http://www.rssboard.org/rss-draft-1#element-channel-item-enclosure
>
> 3. Revised the first sentence of the character data section to this:
>
> For all elements defined in this specification that enclose character
> data, publishers SHOULD format the data as plain text with the
> exception of an item's description element, which MUST be suitable for
> presentation as HTML.
>
> http://www.rssboard.org/rss-draft-1#data-types-characterdata
>
> 4. Added this sentence to the same section:
>
> Although some publishers employ HTML markup in other elements such as
> an item's title, using plain text in those elements achieves the
> widest support in aggregators.
>
> 5. Added links in element descriptions to the Character Data, Dates
> and Times, and URLs sections.
>

A new draft of the proposed spec has been published:

http://www.rssboard.org/rss-draft-1

This draft fixes an error in the description of the category element
and addresses a concern that was raised about using the word SHOULD on
advice that's inconsequential -- such as the spec's recommendation to
make a channel's title element match a web site's title.

After the last proposal, a new board member's question reminded me
that I haven't explained our voting process lately.

A proposal can be made by any member. If that proposal is seconded, a
one-week discussion begins here and on the RSS-Public mailing list.

If the end of that week is reached without the proponent withdrawing
the proposal, a one-week vote begins.

I propose that this spec be adopted as version 2.0.9 of the RSS 2.0
specification.

Here's the exact rundown of changes:

1. Fixed the channel category element to state that the
slash-delimited value goes in the element itself, not the domain
attribute:

http://www.rssboard.org/rss-draft-1-13#element-channel-category

2. Simplified the item ttl definition to more closely follow the
approach taken in the current spec:

http://www.rssboard.org/rss-draft-1-13#element-channel-ttl

3. Changed SHOULD to could in several elements:

http://www.rssboard.org/rss-draft-1-13#element-channel-title
http://www.rssboard.org/rss-draft-1-13#element-channel-category
http://www.rssboard.org/rss-draft-1-13#element-channel-image-link
http://www.rssboard.org/rss-draft-1-13#element-channel-image-title
http://www.rssboard.org/rss-draft-1-13#element-channel-item-author
http://www.rssboard.org/rss-draft-1-13#element-channel-item-source

RFC 2119 contains the following rule about using verbs like SHOULD:

"Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method on
implementors where the method is not required for interoperability."

In all five of the linked sections, SHOULD was being used on advice
that has no effect on interop and no potential to reduce harm -- stuff
like making the channel title match the title of a web site.

--- In rss-board@yahoogroups.com, "Eric Lunt" <eric@...> wrote:
> I mean, I agree that clients shouldn't break when they encounter
> feeds with multiple enclosure elements, but I think the expectations
> should be very, very low that an aggregator will do anything useful
> with anything beyond the first enclosure. Is there any way to convey
> that?

We can do a lot in the RSS Profile to tell people that, because the
profile can cover current usage in detail:

http://www.rssboard.org/rss-profile#element-channel-item-enclosure

There are some pretty big aggregators -- and the world's biggest
browser -- that don't support multiple enclosures.

I propose that the RSS Advisory Board adopt a specification for RSS
auto-discovery to give users and developers formal definition and
guidance for using this popular technique.

I've prepared a couple sentences on the technique which can be used
(permission to blogiarize) in formulating the spec.

http://www.kbcafe.com/rss/?guid=20061026112637

--- In rss-board@yahoogroups.com, "Randy Morin" <randy@...> wrote:
> I propose that the RSS Advisory Board adopt a specification for RSS
> auto-discovery to give users and developers formal definition and
> guidance for using this popular technique.

> I've prepared a couple sentences on the technique which can be used
> (permission to blogiarize) in formulating the spec.

> http://www.kbcafe.com/rss/?guid=20061026112637

I second the proposal. There's already work underway on RSS-Public,
for members who'd like to join Randy and I in drafting the spec.

With the second, discussion will occur for one week on the proposal.

As I've previous written here, we've been working on official
specification for RSS autodiscovery.

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

To date, there has not been such a spec, which makes it difficult for
programmers to find accurate information.  I propose that the RSS
Advisory board approve this spec to fill that gap. Looking for a second.
Thanks,

Randy Charles Morin
http://www.kbcafe.com/rss

--- In rss-board@yahoogroups.com, "Randy Morin" <randy@...> wrote:
> To date, there has not been such a spec, which makes it difficult for
> programmers to find accurate information.  I propose that the RSS
> Advisory board approve this spec to fill that gap. Looking for a second.

I second the proposal, so board members have the next seven days to
vote on the adoption of this spec.

Thanks for putting this together, Randy.