Loading ...
Sorry, an error occurred while loading the content.
 

Re: [rss-board] Single or Multiple Enclosures

Expand Messages
  • Greg Smith
    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
    Message 1 of 17 , Oct 5, 2006
      "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
    • Greg Smith
      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
      Message 2 of 17 , Oct 5, 2006
        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
      • Greg Smith
        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 .
        Message 3 of 17 , Oct 5, 2006
          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
        • rcade
          ... 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
          Message 4 of 17 , Oct 5, 2006
            --- 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."
          • Eric Lunt
            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
            Message 5 of 17 , Oct 5, 2006
              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.
              >
            • James Holderness
              ... 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
              Message 6 of 17 , Oct 5, 2006
                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
              • rcade
                ... 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
                Message 7 of 17 , Oct 5, 2006
                  --- 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.
                • James Holderness
                  ... 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
                  Message 8 of 17 , Oct 6, 2006
                    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
                  • rcade
                    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
                    Message 9 of 17 , Oct 10, 2006
                      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.
                    • Eric Lunt
                      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
                      Message 10 of 17 , Oct 12, 2006
                        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.
                        >
                      • rcade
                        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
                        Message 11 of 17 , Oct 13, 2006
                          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.
                        • rcade
                          ... We can do a lot in the RSS Profile to tell people that, because the profile can cover current usage in detail:
                          Message 12 of 17 , Oct 13, 2006
                            --- 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.
                          Your message has been successfully submitted and would be delivered to recipients shortly.