Subject: Time to add advertising to Atom?

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 18 Oct 2004 19:10:45 +0200

«RSS Feeds Hunger for More Ads»:

<url:  
http://www.wired.com/news/technology/0,1282,65347,00.html?tw=wn_tophead_5>

Is this a demand Atom should meet? How can we meet it? Any (new) thoughts?

I know it has been brought up before, but as it is a more apparent need  
now than six months ago, people might have another view on things. Either  
way, time has passed and people have maybe thought more about the matter.

-- 
Asbjørn Ulsberg    -=|=-     http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 18 Oct 2004 11:11:16 -0700

At 7:10 PM +0200 10/18/04, Asbjørn Ulsberg wrote:
>Is this a demand Atom should meet? How can we meet it?

With an extension.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 18 Oct 2004 20:59:19 +0200

>> Is this a demand Atom should meet? How can we meet it?

So we should just start working on that, then, right? Isn't this a good  
place to do it? Any ideas on how such an extension should look like? And  
how should it be implemented to be certain that clients will support it?

I mean, if most clients don't support this extension, the ad agencies will  
clutter and destroy Atom (and RSS before that) with their own additions  
that indubitably _will_ be supported by as good as all clients. They won't  
hear about optional extensions supported by 5% of the client mass and in  
that group, everyone can turn it off whenever they want.

I guess we have to think a bit broader about the problem, possibly with  
some protocol mechanism at work that sends messages over the wire telling  
the originating server that advertisement X has been read by user Y. What  
consequence such an action should have is in the blue, but it could be  
that 10 new messages are downloadable from the server.

I hope the dilemma is understood. An opt-in ad extension won't be accepted  
as a solution. We all have to look at this problem seriously and try to  
find a solution that works for implementors in both ends as well as the  
users.

---

From: James M Snell <[email-masked]>
Date: Mon, 18 Oct 2004 12:56:34 -0600

Just to stick my nose in this a little... it may seem counter-intuitive, 
but advertisements in feeds should be as unobtrusive as possible.  First 
off, publishers who wish to include advertisements need to decide whether 
or not the display of the advertisements is a required part of the 
fair-use-guidelines for their feeds.  If display of advertisements is 
required, aggregators and other applications should do the Right Thing and 
ensure that advertisements are displayed.  If display of ads is not 
required, aggregators/etc should do the Right Thing and allow their users 
to determine whether or not to display the ads.  Second, ads can either be 
included in or referenced by the feed.  If included, some form of content 
item extension should be used as opposed to including the ad in the main 
content of entry.  If referenced, the Atom link mechanism can be used.  To 
me, an ads extension that follows these characteristics makes a lot of 
sense.  There should not be anything, however, built into Atom for 
handling advertisements.

- James M Snell
  [email-masked]
  http://www.ibm.com
  (877) 511-5082 / Office
  930-1979 / Tie Line

Paul Hoffman / IMC <[email-masked]> 
Sent by: [email-masked]
10/18/2004 11:11 AM

To
Asbjørn Ulsberg <[email-masked]>, Atom-Syntax 
<[email-masked]>
cc

Subject
Re: Time to add advertising to Atom?

With an extension.

--Paul Hoffman, Director

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 18 Oct 2004 12:17:06 -0700 (PDT)

> that group, everyone can turn it off whenever they

Why would any client want to explicitly support a
mechanism for shoving ads in users faces regardless of
whether it is in an extension or a 'mandatory' part of
Atom? 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 18 Oct 2004 12:23:41 -0700

At 8:59 PM +0200 10/18/04, Asbjørn Ulsberg wrote:
>On Mon, 18 Oct 2004 11:11:16 -0700, Paul Hoffman / IMC 
><[email-masked]> wrote:
>
>So we should just start working on that, then, right?

Wrong. An individual or a group of individuals should start work 
off-list, publish an Internet Draft, and bring that to the list.

>  Isn't this a good place to do it?

To discuss proposals: yes. To start them with lots of talk: no.

>  Any ideas on how such an extension should look like? And how should 
>it be implemented to be certain that clients will support it?

No and no. That's for people who are expert in the field.

>I mean, if most clients don't support this extension, the ad 
>agencies will clutter and destroy Atom (and RSS before that) with 
>their own additions that indubitably _will_ be supported by as good 
>as all clients. They won't hear about optional extensions supported 
>by 5% of the client mass and in that group, everyone can turn it off 
>whenever they want.

Such dire predictions have not been borne out in the past. "Clutter 
and destroy" seems a bit over the top. And, if an advertiser comes up 
with an extension that works so well that many client developers want 
to use it, what's wrong with that? Do you really think that the only 
extensions to Atom should come from this WG, even after we close down 
(hopefully next year)?

>I guess we have to think a bit broader about the problem, possibly 
>with some protocol mechanism at work that sends messages over the 
>wire telling the originating server that advertisement X has been 
>read by user Y. What consequence such an action should have is in 
>the blue, but it could be that 10 new messages are downloadable from 
>the server.

No, "we" don't. You can if you want. If after all that thinking you 
come up with a worked-out extension, feel free to publish it as an 
individual draft and alert the mailing list of its existence.

>I hope the dilemma is understood. An opt-in ad extension won't be 
>accepted as a solution.

This firm prediction is at odds with the adoption history of numerous 
other IETF protocols with extension mechanisms.

>  We all have to look at this problem seriously and try to find a 
>solution that works for implementors in both ends as well as the 
>users.

I look forward to your worked-out extension as an Internet Draft.

--Paul Hoffman, Director

---

From: James Robertson <[email-masked]>
Date: Mon, 18 Oct 2004 15:47:48 -0400

Here's a really wild thought - each item could be an ad, using either 
markup or plain text as the provider saw fit.  Which means that it's 
already supported.  If providers overdo it, then subscribers will opt 
out.  Why is this hard?

At 03:23 PM 10/18/2004, you wrote:

>Wrong. An individual or a group of individuals should start work off-list, 
>publish an Internet Draft, and bring that to the list.
>
>>  Any ideas on how such an extension should look like? And how should it 
>> be implemented to be certain that clients will support it?
>
>>I mean, if most clients don't support this extension, the ad agencies 
>>will clutter and destroy Atom (and RSS before that) with their own 
>>additions that indubitably _will_ be supported by as good as all clients. 
>>They won't hear about optional extensions supported by 5% of the client 
>>mass and in that group, everyone can turn it off whenever they want.
>
>Such dire predictions have not been borne out in the past. "Clutter and 
>destroy" seems a bit over the top. And, if an advertiser comes up with an 
>extension that works so well that many client developers want to use it, 
>what's wrong with that? Do you really think that the only extensions to 
>Atom should come from this WG, even after we close down (hopefully next year)?
>
>No, "we" don't. You can if you want. If after all that thinking you come 
>up with a worked-out extension, feel free to publish it as an individual 
>draft and alert the mailing list of its existence.
>
>> solution that works for implementors in both ends as well as the users.
>

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView
[email-masked]

---

From: Tim Bray <[email-masked]>
Date: Mon, 18 Oct 2004 13:19:27 -0700

> already supported.  If providers overdo it, then subscribers will opt 

In fact this is being done today.  It seems to work. -Tim

---

From: James Aylett <[email-masked]>
Date: Tue, 19 Oct 2004 09:13:07 +0100

> whether it is in an extension or a 'mandatory' part of

Which is pretty much why most people will just put the ads in as items
(as currently); all an extension would do is to mark them as
advertising, which might conceivably be needed for anti-spam laws in
some territories. Quite what would happen then is anyone's guess - if
a significant number of aggregators just rip out marked advertising
(and some will), the utility of the extension to the advertisers is
pretty limited.

I don't think this is something atompub should get involved in. I'm
not really convinced that anyone should try to get involved in it :-)

(But I don't speak for my employer here.)

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: "Sascha Carlin" <[email-masked]>
Date: Tue, 19 Oct 2004 12:52:41 +0200 (CEST)

Why not implement an attribute for atom:item called ad="ad" like its done
with checked="checked" within XHTML?

Since advertisments must be marked being an advertisment, we could provide
this attribute to help ad-publishers by giving them a standardized way of
marking ads and consumers a way to doubtless identify ads.

cu, Sascha

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 19 Oct 2004 11:47:47 -0400

James Robertson wrote:
> Here's a really wild thought - each item could be an ad, using
> either markup or plain text as the provider saw fit.  Which means
> that it's already supported.  If providers overdo it, then
> subscribers will opt out.  Why is this hard?
	In many cases, what you suggest is probably quite adequate; however,
I think it is important to remember that not all Atom entries will be
handled as text. For instance, you might have a feed of "Airport Delay
Status" or "Weather" whose entries are processed by some clients as data
rather than as text. (i.e. the entries might drive some interactive map
rather than a text display.). In such a feed, an advertisement for something
like a "cheap airplane ticket to Florida" would probably have a different
encoding then the other entries in the feed. The ad would likely be text
rather than some other XML type. It would be useful, I think, for feed
producers to be able to flag the ads in such feeds with some sort of
metadata to indicate to the client that they require special handling.

		bob wyman

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 19 Oct 2004 23:34:40 +0200

> with checked="checked" within XHTML?

I think the problem is a bit bigger than this, but it would nonetheless be  
trivial and unproblematic to add an 'ad:ad="ad"' attribute to the  
atom:entry element. Not sure that solves it all, though.

---

From: Walter Underwood <[email-masked]>
Date: Tue, 19 Oct 2004 15:40:42 -0700

I believe that an advertising marker should be in the Atom core or in an
extension published at the same time as the core.

Some big reasons for this:

1. Publishers need advertising, so we can't pretend it won't exist.

2. Many ad channels (Google, for example) clearly mark ads for the user,
so marked ads are acceptable to publishers. They may even be preferable,
because they avoid some kinds of inadvertant deceptive advertising.

3. Automatic consumers(robots) need to be able to sort out the entries
from the ads. Ads mised in with search results is just not acceptable to
the users of search engines or profile services (pubsub.com).

4. A recommended place for advertising allows clients to push back on
advertising in regular entries, links, whatever (spam). Also, it may be
possible to apply anti-spam laws to advertising which is not properly marked.
[No, I'm not a laywer or a legislator, but spam is everywhere and legal
remedies are one current approach. Enabling those gives us more anti-spam
weapons.]

Some approaches:

Ads as unmarked entries: This puts the responsibility entirely on the
client. Welcome to the spam filtering business, again.

Ads as marked entries: Good for robots, also allows clients to display
a marker with the ads to distinguish them from other entries.

Ads as non-entry items: We're having enough fun with entries. I can't
imagine adding another kind of media content and getting it finished.

Ads as links: Almost as complicated as a new kind of entry. An ad would
need several coordinated links: an href, an optional image, text, etc.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 19 Oct 2004 16:42:39 -0700

>extension published at the same time as the core.

This is not the core of the protocol. It's an add-on that someone 
thought up more than a year after people formulated what the core 
should be.

Please feel free to write an extension, possibly with Asbjørn. When 
you have one that is reasonably well-baked, let the list know.

Best of luck with the semantics of what an "advertisement" is..., 
much less what one isn't.

--Paul Hoffman, Director

---

From: Norman Walsh <[email-masked]>
Date: Wed, 20 Oct 2004 08:28:18 -0400

/ Dare Obasanjo <[email-masked]> was heard to say:
| --- Asbjørn Ulsberg <[email-masked]> wrote:
|
|> 
|> I mean, if most clients don't support this
|> extension, the ad agencies will  
|> clutter and destroy Atom (and RSS before that) with
|> their own additions  
|> that indubitably _will_ be supported by as good as
|> all clients. They won't  
|> hear about optional extensions supported by 5% of
|> the client mass and in  
|> that group, everyone can turn it off whenever they
|> want.
|
| Why would any client want to explicitly support a
| mechanism for shoving ads in users faces regardless of
| whether it is in an extension or a 'mandatory' part of
| Atom? 

Indeed. The sole value I can think of for standarization is that
clients would know what content to suppress with extreme prejudice.

Maybe that's a really, really good reason to sandardize it :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Society is immoral and immortal; it can
http://nwalsh.com/            | afford to commit any kind of folly, and
                              | indulge in any kind of vice; it cannot
                              | be killed, and the fragments that
                              | survive can always laugh at the
                              | dead.--Henry Adams

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 20 Oct 2004 17:01:39 +0100

> Maybe that's a really, really good reason to sandardize it :-)

Since a standardized slot for advertising will ensure no ads are 
present there, we could use it to tunnel content through Atom feeds :)

cheers
Bill

---

From: Sascha Carlin <[email-masked]>
Date: Wed, 20 Oct 2004 19:22:23 +0200

>> Is this a demand Atom should meet? How can we meet it?

What's the reson to not put it in Atom core?

Just curious, Sascha

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 20 Oct 2004 11:17:48 -0700

>What's the reson to not put it in Atom core?

It's not in our charter, and there is *lots* that is not in our 
charter that "might be useful". As long as we have a good extension 
mechanism, the core should be just that: a core.

--Paul Hoffman, Director

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 23 Oct 2004 21:37:15 +0200

> extension published at the same time as the core.

I think it belongs in an extension. But both Atom and RSS needs it, unless  
we want the format(s) to be hijacked by advertisement agencies one year or  
so from now, when they realize that money can be made from the world of  
syndication.

> 1. Publishers need advertising, so we can't pretend it won't exist.

Indeed.

> because they avoid some kinds of inadvertant deceptive advertising.

True. Hence an attribute on the atom:entry element might be something  
content providers are interested in applying.

> the users of search engines or profile services (pubsub.com).

Correct. If content providers think this is a problem; desktop aggregators  
might be able to just filter out all advertisements from real content, we  
can suggest a server-side mechanism that registers downloaded ads which  
again affects how much content you'll get delivered. Such a solution would  
need to be login-based, of course, but it's still a solution.

> client. Welcome to the spam filtering business, again.

Whohoo! No, I don't think this is a good solution. Not even for the ad  
agencies.

> a marker with the ads to distinguish them from other entries.

I think this is the best solution.

---

From: Danny Ayers <[email-masked]>
Date: Sun, 24 Oct 2004 00:55:38 +0200

> I think this is the best solution.

Agreed. I imagine there'll be quite a lot of bouncing around and
attempts at stealth, but the unsubscribe button should damp things
down (good word, damp).

-- 

http://dannyayers.com

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 23 Oct 2004 22:36:35 -0400

Danny Ayers wrote:
> I imagine there'll be quite a lot of bouncing around and
> attempts at stealth, but the unsubscribe button should damp
> things down (good word, damp).
	Please try not to make decisions about the Atom format based on
quaint and out-moded ideas like "unsubscribe" being a useful mechanism to
"punish" rogue publishers or eliminate unwanted data... When syndication was
young, "unsubscribe" was a distinctly powerful tool, however, as the number
of feeds has grown, we have gone far beyond being able to imagine people
relying on having specific subscriptions to all or even a large proportion
of the feeds they read. 
	Consider the case of Robert Scoble who is famous for "reading" a
vast number of feeds every day. Scoble actually reads over 3 million feeds
every day! He subscribes directly to 950 or so and relies on PubSub to
filter the remaining 3 million+ for him. Thus, Scoble is not directly
"subscribed" to the more than a tiny number of the feeds that he "reads" --
at least, not in a way that he can "unsubscribe" to any specific feed. As
more people discover the utility of matching engines like PubSub's or the
search engines provided by Feedster and many others, we're going to find
that fewer and fewer people actually "subscribe" to most of the feeds they
read.
	It is very important to understand this changing dynamic in the
usage of feeds and consider it carefully in the format design. The thing
that is most critical is to carefully consider what, if anything, can be
done in the format to reduce the need for intermediaries that you do not
control to take on more responsibility for filtering content. 
	Ideally, the intermediaries will "filter" and "select" based on
purely objective measures. Objective measures will, however, rely on
metadata being present. Thus, it is best to provide them with as much
metadata as possible and reasonable. If the metadata isn't there or if it is
consistently inaccurate or inconsistent in meaning due to
under-specification, the intermediaries will be forced to make "judgment"
calls to provide the filtering services that users will inevitably demand.
When the intermediaries are forced to start implementing subjective measures
of what is or is not an advertisement, end users will begin to lose control
over the their access to content... That is not a good thing...

		bob wyman

---

From: "Roger B." <[email-masked]>
Date: Sun, 24 Oct 2004 01:18:17 -0500

> When syndication was

Bob: "We" have gone no such place. :) Absolute control over input is
the primary thing that makes syndication something more than
mailing-lists-over-HTTP from the user's perspective, and it's not
going anywhere.

> at least, not in a way that he can "unsubscribe" to any specific feed.

I'm sure you'll add that in a future version of PubSub... filtering
out unwanted sources is pretty important.

> we're going to find

Only among the Scoblesque infovores. Most folks crave brands,
identities, and personalities, things you don't get from cross-web
search results.

> usage of feeds and consider it carefully in the format design.

Agreed. It's not nearly as significant a factor as you're suggesting,
but it's still important.

--
Roger Benningfield

---

From: Danny Ayers <[email-masked]>
Date: Sun, 24 Oct 2004 12:09:43 +0200

> mailing-lists-over-HTTP from the user's perspective, and it's not

Absolutely. 

> out unwanted sources is pretty important.

I don't deny that the dynamic is changing - most of my daily
must-reads are now covered by a couple of 'Planets'. But one of the
key pieces of metadata is the source of the feed. If one of the
Planets decided to add a feed that included advertising, I would
expect to be able to filter it out. If I couldn't, then I'd probably
unsubscribe from that Planet as a whole and find another means of
getting the information. Same goes for any other intermediary tool.

> identities, and personalities, things you don't get from cross-web

Yep, probably be a wide range of (mixed) behaviour.

> but it's still important.

Try substituting 'offensive content' in place of 'advertising' and
apply the same reasoning. Per-feed filtering (aka unsubscribing) is
the end-user's big gun. Any aggregate-republish service that doesn't
take that into consideration will be at a disadvantage in an open
market.

If advertising goes in as unmarked content, then for many end users
this will be lowering the signal/noise ration of the information
source. Sure, this is bound to be one avenue pursued by marketeers,
the blanket treatment of people as customers is found in every other
media. But targetting is another marketing strategy, and providing
additional metadata can potentially improve the
publisher(seller)/consumer(buyer) matchmaking.

Cheers,
Danny.

-- 

http://dannyayers.com