intertwingly

It looks like Google Blog Search has supported a similar element (called index="no") for a while, but this fact has not been well advertised: [link] [link]

Mihai: do you know of a spec for such a thing?  As near as I can tell, there is no spec, and the function isn’t widely implemented.

Interesting.  Well, I added support for it to FeedTools since it was easy enough to do.  FeedTools will now raise an exception if you try to regenerate the XML for one of these feeds.

You have tests.  I have questions.
1) This spec seems to apply only to server based applications: “a feed may (not) be redistributed to other public sources, including search”.  Define “restribute” - if I mark my feed with <access:restriction relationship="deny" />, will Bloglines no longer allow their users to read my feed in their web reader, or just exclude my feed from being republished via their API?  The use case for indexing seems pretty clear-cut - people don’t want their content indexed and republished in HTML, RSS, Atom, or any other format.  They don’t want their content showing up in search results, basically.  “Redistribute” seems quite broad, and my impulse is to interpret it broadly, covering all server based aggregation applications.  However, this doesn’t cover the common use case where people just don’t want to be included in search results. 
2) “The default relationship is to allow access. However, if a feed is currently set to ‘deny’, the relationship must be explicitly set back to ‘allow’ for it to be registered”.  OK, so clearly, you can’t use default values for attributes - this establishes a state machine, where the default value is “allow”, but once explicitly set to “deny”, the default value for the <code>relationship</code> attribute becomes “deny”.  This is a bit trickier to assert, since a correct result depends on a previous result.  Furthermore, let’s posit an edge case: let’s say a feed is published using “allow”, and at some point in the future, the original URL redirects to a new source URL (assume 302 so the original subscription is not overwritten).  Now, the publisher changes to “deny”, then changes to omit the relationship attribute - as far as the original document, the default value is “deny”.  Subsequently, a server-based aggregator attempts to subscribe the redirected URL (the Location: of the 302, not the original URL that returns 302).  Now, as far as the server is concerned, this is a new document with a new source URL, so the default value is “deny”, but the intent of the publisher is the opposite.  So do I need to track the URL I ultimately retrieved from, as well as the original URL, so I can correctly ascertain that the source document is in fact the same and can calculate default state?
3) Regarding “widely implemented” - I am interested of instances of this being seen “in the wild”.  Is anybody using this yet?

Sam: No spec that I know of, I’m asking around.

“I am not a lawyer,” but it seems entirely plausible that this new element could be considered “a technological measure that effectively controls access” under the DMCA (specifically section 1201).  If so, software (such as Planet) that redistributes feed content without respecting this new element could be illegal under U.S. law, and any developers — and potentially any users — of such software could be subject to felony charges.  That would include you, Sam.

In point of fact, Planet could not possibly support this new access control measure without upstream changes to UFP, because UFP strips the access control information during parsing.  (For example, this example feed could say relationship="allow" or relationship="deny", but either way UFP would return feed.access_restriction='' because it doesn’t know anything about the http://www.bloglines.com/about/specs/fac-1.0 namespace and thus defaults to dropping all attribute values and returning the text content of each element.)  This may mean that UFP is in violation of section 1202 (b) for removal or alteration of copyright management information.  If so, that could subject me to felony charges.  And all I did was wake up this morning.

So Bloglines has published a spec for indicating whether or not feed content should be redistributed. While the extension is simple, there are a number of distinct problems. First off, as Byrne points out, Bloglines is, at least in part, addressing...

I generally agree with James' point about this not really adding much new. Except I think it differs from Creative Commons in that the default there is really full copyright restrictions, with CC explicitly allowing additional use. This extension follows the general loose assumption that a published feed is fair game for publication/indexing and moves to add restrictions.

I like Randy’s take on the extension:

“Every few days, I get an email from somebody who is concerned that I’m reposting in my search results fragments from their blogs, journals, etc. I assume Bloglines gets a lot more than I. This extension gives Bloglines a way of responding to these complaints without having to create and maintain a blacklist of RSS feeds.” [link]

My own first impressions (prior to seeing James & Randy’s comments): [link] The only point not covered elsewhere I think is that this extension is wide open to misinterpretation as enforcing access control rather than requesting it.

BlogLines recent announcement of their Feed Access Control RSS and ATOM has invigorated the discussion of feed specifications for licensing and control. There#x2019s a link dump below for your browsing pleasure. James Holderness, however, seems...

It’s a golden rule in most businesses that salaries must be kept secret. Except for a few heretics it is almost universally accepted that mayhem would ensue in the workplace if people knew what their co-workers, their managers or - gasp - the CEO...