Hi,
I've filed issue ticket #45 encompassing the items in your message I'm replying
to, and will address them in -08 (underway).
> 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.
So how about this re-write of that last bullet item..
o UAs MUST ignore any STS header fields containing directives, or
other header field value data, that does not conform to the
syntax defined in this specification.
..?
>> > 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 did not say anything about the location of the sentence.
> I think you need to
> strike "(which "update" this specification)".
works for me. done in my -08 working copy.
<snip/>
>> 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.
sure, done in my -08 working copy.
=JeffH
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
