On 6/6/06, George Schlossnagle <george(_at_)omniti(_dot_)com> wrote:
David Nicol wrote:
> receivers coddle B2C senders in order to keep them better behaved. Less
I don't buy this at all. I don't know of any receivers that I would
classify as 'coddling' large b2c senders. In general receivers don't
need to be offering carrots to large b2c senders, the stick seems to
work fine; there's been mainly stick (or future threat of stick) around
setting up DK/DKIM signing and adoption of that has been working well.
Sorry, I guess I got the verb tense wrong there. That present-tense
assertion was meant to be taken subjunctively. "The proposal would make
sense in a possible future in which receivers wish to manage B2C senders
with carrots as well as sticks" is closer to what I meant. By giving B2C
senders their own special protocol, they could be effectively rate-limited,
and billed. B2C e-mail is big business, and AFAIK the stick approach is
just making all involved frustrated and unhappy. With a carrot approach,
a receiving domain would have less of their incoming bandwidth taken up
by B2C traffic and make the B2C people carry their weight when they want
to use more.
Maybe the BULK extension would start with some sender accounting identification,
before issuing templates.
The differences in regards to content creation responsibility, interop,
liability for cretaed content etc. between doing templatization and
doing compression are hopefully obvious.
As are the similarities. Are you seriously arguing that "templatization is a
form of compression" is a false statement? Have you ever written a driver
for an industrial label printer?
Really, about liability -- does anyone have any links to case law concerning
templatization and common-carrier issues? A lot of web pages anymore are
created with dynamic client-side tools, and there is no confusion
that, for instance,
the images presented by google maps are fully the responsibility of google and
not my responsibility because the image was knit together by their
program running
on a computer plugged into my wall, or that a the responsibility for a
cross-site-scripting
attack lies with the perpetrator of the attack rather than with the victim.
Thanks very much for the feedback on my off-the-cuff ideas; the amount of typing
I've done on this thread today (large) is far out of proportion to the
weight of my
convictions on the issues (small).
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg