Re: [apps-discuss] Call For Adoption: draft-nottingham-safe-hint

[John C Klensin <[e-mail]>]

--On Sunday, July 27, 2014 18:41 -0700 Paul Hoffman
<[e-mail]> wrote:

> Given your worry that someone might successfully extend this
> specification in the future, but we might stop them from doing
> their own (dangerous) multi-faceted header, would your concern
> be mitigated by something in the spec that says "this header
> may never have any value than the one specified in this
> document"?

Paul,

My sense is that our track record when saying "this may never
have any value..." has been rotten.  The people, or
implementers, who think they need additional capabilities just
ignore such constraints and do their own thing, typically in a
way that creates confusion rather than interoperability.    If
we were going to do anything along those lines, it would be
better to lay out some minimal syntax with no semantics and then
reserve it for future extension and explain why the reservation
is needed and specify what to do if a current-technology server
implementation encounters a use of the extended syntax.  

So, if one wants to try to keep the spec to a single bit (at
least until some other consensus emerges), it would probably be
best to specify a parameter field (see
draft-snell-http-prefer-18), to specify that it is reserved for
future expansion and semantics, and even to require that, should
a non-null parameter field appear, it most contain a version
number and, for now, a value of 0 and nothing else and that a
server encountering a non-zero version number or parameter field
not containing such a version number must treat the field as
missing.  If one wanted to be really aggressive about that, one
might require that a server encountered a non-empty,
none-version-zero parameter would return an error message rather
than any web content.   

That is a bit extreme but, if we really want to "stop them from
doing their own...", that would probably do it where "never have
any value..." would not.

Stephen,

I don't see the Chinese issue as particularly relevant to this
proposed extension.  Their current policy, at least as widely
reported outside China, is "nothing is allowed on the network
that is not 'safe' as we define it".  The presence of a header
that says "I prefer 'safe'" would have no impact at all,
positive or negative, on such a policy since there is already a
policy requiring that sites emit only "safe" material (whether
the header is present or not).  It would be different if there
were no precedent for sites returning different, or a more
restrictive set of, material for different types of users but
the sites Mark identifies have already shown both the ability
and willingness to do that.   

FWIW, while the definition of "safe" varies, the perceived
Chinese requirement/behavior is not, AFAICT, significantly
different from that advocated by various "conservative" or
Internet-afraid legislators around the world.  I'm afraid of
those legislators, but I don't see how this header would affect
them one way or the other.  In that regard, it is somewhat like
the evil bit of RFC 3514 and far more like the claims that
ICANN's delegation of the XXX TLD would make the Internet safe
for children and others who didn't want to be exposed to
pornography.  I don't expect this header to be very useful, but
suspect that standardizing it, with appropriate disclaimers,
might turn out to be better than leaving each system to figure
out its own format and implied semantics.

    john