Re: [websec] Spencer Dawkins' No Objection on draft-ietf-websec-x-frame-options-08: (with COMMENT)

[Tobias Gondrom <[e-mail]>]

Dear Spencer,
thanks a lot for the review and feedback.
I included your feedback comments in version-09.
Thanks for the review and all the best, Tobias



On 13/08/13 02:10, Spencer Dawkins wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-websec-x-frame-options-08: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I really like this specification, and I appreciate the working group
> producing it. Documenting "in the wild" behavior is a good thing.
>
> I have one fairly fundamental comment, which I think can be easily
> addressed, and a few nits.
>
> My comment: This specification starts out like a normal header field
> specification until you get to 
>
> 1.  Introduction
>
>    This specification provides informational documentation about the
>    current use and definition of the X-Frame-Options HTTP header field.
>    Given that the "X-" construction is deprecated [RFC6648], the X
>    -Frame-Options header field will in the future be replaced by the
>    Frame-Options directive in the Content Security Policy Version 1.1
>    [CSP-1-1]. 
>
> That's still KIND of OK (no indication that anything is wrong with
> X-FRAME-OPTIONS functionality, just a heads-up that implementations that
> include X-FRAME-OPTIONS will have work to do in the future), but when we
> get to 
>
> 2.3.2.2.  Variation in current browser behaviour
>
>    There are currently variations in the implementation of the X-FRAME-
>    OPTIONS header. 
>
> we discover unambiguously that current implmentations don't all work the
> same way, so your ability to rely on X-FRAME-OPTIONS is not entirely
> clear.
>
> I wonder if the set of technical details are asperational, saying "this
> is what X-FRAME-OPTIONS could have been, and what the next header field
> in this space should be".
>
> I think it's fine to publish this specification, especially as
> Informational, even if it's not clear to me that *any* of the
> functionality described in this specification is implemented the same way
> in all major browsers.
>
> I would be more comfortable with a clear statement in the Introduction
> that the biggest problem with X-FRAME-OPTIONS is *not* the leading "X-",
> but that today's implementations don't all provide the same options with
> the same behaviors, so relying on this specification as a predictor of
> what will happen to your frames is not a good idea. 
>
> One sentence that puts the reader on notice would be sufficient.
Done.

> My nits, just so editors don't have to find them again:
>
> Is there a reason why sometimes X-FRAME-OPTIONS is in all caps, and other
> times not? I'm not an APP guy, so I'm asking.
Only reason is that my eyes got tired of so many all caps in the flow
text, while in some place, I felt it would be easier to read when in all
caps. Both are possible.


>
> In Section 2.3.2.2.  Variation in current browser behaviour
>
>    These variations in the evaluation of the header by different
>    implementations impair the useage and reliability of this http
>    header.  A revised version of x-frame-options in the form of a frame-
>    options directive in the CSP 1.1[CSP-1-1] will unify the behaviour
>    and it is expected that newer implementations will use it rather than
>    the mechanisms documented here"
>
> The trailing quote mark should be a period, I suppose?
Yes. Corrected.

>
> 5.1.  Privacy Considreations should be "Considerations".
Thanks. Corrected.
>
> In B.2.  Online Shop Confirm Purchase Page
>
>    The "Confirm Purchase"" 
>
> The doubled trailing quote marks should be one quote mark, perhaps?
Yes. Thanks. Corrected.
>