Subject: Re: [websec] handling STS header field extendability
From: =JeffH <[email-masked]>
To: IETF WebSec WG <[email-masked]>
Date: Fri, 17 Aug 2012 15:55:15 -0700
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>

Yoav Nir noted:
 >
 > As a reminder, the proposed resolution is as follows:
 >
 >  * Do not establish a registry now
 >       Let the first new header field specification establish it
 >
 >  * A client that gets an unknown field ignores it
 >       This means no mandatory-to-understand extensions

Thanks, Yoav.

I'd also noted that we need to decide on a IANA policy to declare. My original 
message is here..

   https://www.ietf.org/mail-archive/web/websec/current/msg01315.html

..and I suggested that, since HSTS is a security policy, I lean towards wanting 
to have relatively rigorous review applied to any registry and its contents 
created for HSTS directives and thus am thinking a policy of "IETF Review" is 
what we ought to state (for "FOO" in the below excerpt from -12 at the end of 
section 6.1)..

    Additional directives extending the semantic functionality of the STS
    header field can be defined in other specifications, with a registry
    (having an IANA policy definition of FOO [RFC5226]) defined for them
    at such time.

    NOTE:  Such future directives will be ignored by UAs implementing
           only this specification, as well as by generally non-
           conforming UAs.  See Section 14.1 "Non-Conformant User Agent
           Implications" for further discussion.

thanks,

=JeffH