Re: Last Call: <draft-nottingham-safe-hint-05.txt> (The "safe" HTTP Preference) to Proposed Standard

[[e-mail]]

> On Thu, Oct 23, 2014 at 7:51 PM, Mark Nottingham <[e-mail]> wrote:
> > Donald Eastlake said:
> >
> >> I believe it has many of the problems discussed in RFC 3675.
> >
> > Could you please be more specific? The analogy is not obvious, and that's a big RFC.

> Consider the analogy between one bit of "safeness" and one top level
> domain name for "adult" material.

OK... So one is a visible label saying "unsafe material here", the other is a
way to make a request saying "safe material preferred". At first glance these
don't seem structurally similar at all.

Issues with .xxx or whatever described in RFC 3675 include the cost of
publishers of unsafe material switching labels, internationalization issues
with the .xxx or whatever label itself, the stigma and/or legal repercussions
of being labeled as being in the unsafe category, the explosion of surrounding
TLD names and their associated semantics, and the ability of anyone
to create an unsafe label pointing at someone else.

None of these issues seem applicable to the safe-hint mechanism, mostly because
it's a hint, not a label.

The privacy issue described in RFC 3675 would also appear to be avoided, at
least up to the point where a sufficiently high number of requests use the safe
hint that requests without it stand out. This probably should be mentioned,
along with the opposite concern of knowing who wants safe material, but it's
hardly a showstopper.

Really, the only issue in RFC 3675 that seems remotely relevant is that of
disagreement over the definition of what meets the criteria - the case of the
safe hint, what consistitutes "safe enough". And I suppose it's a concern that
if you offer a safe mode you're implictly acknowledging that some of your
material is "unsafe", but many web sites already have multiple areas and/or
versions, so this is hardly anything new.

The bottom line is as far as I'm concerned you're going to have be a lot more
specific about why RFC 3675 is relevant in this context, because I don't see
it.

				Ned