On 02/05/2012 20:45, =JeffH wrote:
> [ resent with correct Subject: ]
>
> Hi Alexey, thanks for the review, apologies for latency.
Hi Jeff,
> >     The two directives defined in this specification are described 
> below.
> >     The overall requirements for directives are:
> >
> >     o  The order of appearance of directives is not significant.
> >
> >     o  All directives MUST appear only once in an STS header field.
> >
> >     o  Directive names are case-insensitive.
> >
> >     o  UAs MUST ignore any STS header fields containing directives that
> >        do not conform to their ABNF definition.
> >
> > Should this list also say something about how unrecognized directives
> > should be treated? I.e. are they ignored by default, is the whole
> > STS header field ignored, etc.
>
> Does the last bullet item above not address those questions?
No. The last bullet is talking about recognized, but invalid data. I am 
asking about unrecognized data.

> >     Additional directives extending the semantic functionality of 
> the STS
> >     header field may be defined in other specifications (which "update"
> >     this specification),
> >
> > Is this a requirement on future extensions?
> > (In general "updating" this specification using Updates: in the header
> > of the relevant RFC
> > is a) a heavy weight mechanism (it prevents Experimental extensions) 
> and
> > b) this seems
> > like a wrong mechanism anyway, as Updates usually means that the
> > document being
> > updated can't be implemented without the document which updates it.)
>
> We can place in the above para whatever we/you/ourADs wish. 
> Suggestions welcome.
It is not about the location of this sentence. I think you need to 
strike "(which "update" this specification)".

> >     subdomain of a publicly-available web application which may be
> >     secured by TLS/SSL.  For example, <https://example-ca.com/> is a
> >     publicly-available web application for "Example CA", a 
> certification
> >     authority.  Customers use this web application to register their
> >     public keys and obtain certificates.  Example CA generates
> >     certificates for customers containing
> > <http://crl-and-ocsp.example-ca.com/> as the value for the "CRL
> >     Distribution Points" and "Authority Information Access:OCSP"
> >     certificate fields.
> >
> > 13.  Internationalized Domain Names for Applications (IDNA): Dependency
> >       and Migration
> >
> >     IDNA2008 obsoletes IDNA2003, but there are differences between the
> >     two specifications, and thus there can be differences in processing
> >     (e.g., converting) domain name labels that have been registered 
> under
> >     one from those registered under the other.  There will be a
> >     transition period of some time during which IDNA2003-based domain
> >     name labels will exist in the wild.  User agents SHOULD implement
> >     IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 
> 7 of
> >     [RFC5894]) or [UTS46] in order to facilitate their IDNA transition.
> >
> > I might be kicking a dead horse here, but MAY sounds a bit weak.
> > I especially dislike having the choice between 2 incompatible specs,
> > I think this might cause some interop problems.
>
> As far as I can tell, having had fairly extensive discussions with 
> IDNA folk both privately and on various lists such as idna-update@, 
> the above relects the the unfortunate state of the world at this time. 
> For instance, Pete Resnick signed off on the language in the spec in 
> this message to websec@...
Commented on this in reply to Peter.
> Re: [websec] wrt IDN processing-related security considerations for 
> draft-ietf-websec-strict-transport-sec
> https://www.ietf.org/mail-archive/web/websec/current/msg01015.html
>
> we should probably fork off any further discussion on this topic to 
> that thread.
>
>
> > Also, does "in order to facilitate their IDNA transition" apply
> > to the second reference or to both references?
>
> It applies to both. One may implement [RFC5895] /or/ [UTS46] to 
> facilitate one's IDNA transition (as I understand it).
Can you please move "in order to facilitate their IDNA transition" to 
the beginning of the sentence? I think this will make it clearer.
>
> again, followups on this item and the above should probably be in the 
> "Re: [websec] wrt IDN processing-related security considerations for 
> draft-ietf-websec-strict-transport-sec" thread here on websec@.
>