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

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Oct 2014 10:51:06 +1100

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.

Thanks,

--
Mark Nottingham   https://www.mnot.net/

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 23 Oct 2014 20:04:21 -0400

> 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.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Oct 2014 11:27:13 +1100

> On 24 Oct 2014, at 11:04 am, Donald Eastlake <[email-masked]> wrote:
> 

RFC3675 walks through the impacts of of using a particular type of flag in a few different situations. It doesn't follow that all flags are bad in all situations; the problems listed in that draft don't necessarily apply to the safe preference, because it's designed and deployed in a way that's very different than a DNS label.

To put it another way - a common judgement in engineering is that many things are "0, 1 or many." Are you suggesting we rule out all "1" cases?

If not, please spell out the analogy, because I'm not following.

Also, I note that in 4.3 you hold up PICS labels as an exemplar;

> This sort  of technology is really the only reasonable way to make
> categorizations or labelings of material available in a diverse and
> dynamic world.

I disagree, given that PICS labels have absolutely failed to get any serious traction in the real world over the past 18+ years.

P3P did something similar (I was involved there), and similarly didn't get anywhere (except annoying some Web site operators).

Cheers,

---

From: [email-masked]
Date: Thu, 23 Oct 2014 17:40:14 -0700 (PDT)

> 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

---

From: Andrew Newton <[email-masked]>
Date: Fri, 24 Oct 2014 09:08:25 -0400

> it's a hint, not a label.

Another difference between .xxx and a safe hint is that there would or
could be an authority judging the content that does or does not go
under .xxx. With a safe hint, that distinction is drawn by the content
holder. I think a safe hint is a far more workable solution as there
would never be a universal agreement about what constitutes .xxx
material (as is stated by 3675).

> along with the opposite concern of knowing who wants safe material, but it's

+1

> versions, so this is hardly anything new.

Perhaps this draft could have an informative reference to 3675 if
readers want to know more about the issues of what is and is not
"safe" content. But I don't see the issues discussed in 3675 as being
showstoppers for this. And given this draft is documenting an existing
practice, I support its adoption.

-andy