Skip to main content

HTTP Header Field X-Frame-Options
RFC 7034

Revision differences

Document history

Date Rev. By Action
2015-10-14
12 (System) Notify list changed from websec-chairs@ietf.org, draft-ietf-websec-x-frame-options@ietf.org to (None)
2013-10-10
12 (System) RFC published
2013-10-10
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2013-09-24
12 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2013-09-21
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2013-08-28
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2013-08-28
12 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2013-08-28
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2013-08-28
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2013-08-28
12 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2013-08-28
12 (System) IANA Action state changed to In Progress
2013-08-28
12 (System) RFC Editor state changed to EDIT
2013-08-28
12 (System) Announcement was received by RFC Editor
2013-08-28
12 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2013-08-28
12 Amy Vezza IESG has approved the document
2013-08-28
12 Amy Vezza Closed "Approve" ballot
2013-08-28
12 Amy Vezza Ballot approval text was generated
2013-08-27
12 Barry Leiba Notification list changed to : websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org
2013-08-27
12 Barry Leiba State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2013-08-27
12 Tobias Gondrom New version available: draft-ietf-websec-x-frame-options-12.txt
2013-08-27
11 Richard Barnes [Ballot Position Update] Position for Richard Barnes has been changed to Yes from Discuss
2013-08-26
11 Tobias Gondrom New version available: draft-ietf-websec-x-frame-options-11.txt
2013-08-22
10 Robert Sparks Request for Last Call review by GENART Completed: Ready. Reviewer: Robert Sparks.
2013-08-19
10 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2013-08-19
10 Richard Barnes
[Ballot discuss]
(D1) The privacy considerations make no sense to me.  To whom is data being leaked?  To the browser?  To random people who send …
[Ballot discuss]
(D1) The privacy considerations make no sense to me.  To whom is data being leaked?  To the browser?  To random people who send a request to a URI?  Do you mean that X-Frame-Options leaks information about who the site authorizes?  That's true, but also true of things like CORS.  If this is the concern, you should recommend a mitigation that's basically the same as what CORS does, namely varying the value of X-Frame-Options based on the Referer or Origin header.

(D2) It seems like this is a value that browsers might cache, to avoid unnecessary requests if the same page is framed in the future.  If this is something browsers do today, please say so. 

(D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI?  In other words, what does it mean to send "X-Frame-Options: ALLOW-FROM https://example.com/this/is/a/path?query#fragment"?
2013-08-19
10 Richard Barnes Ballot discuss text updated for Richard Barnes
2013-08-17
10 Tobias Gondrom IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2013-08-17
10 Tobias Gondrom New version available: draft-ietf-websec-x-frame-options-10.txt
2013-08-16
09 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Joseph Salowey.
2013-08-15
09 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation
2013-08-14
09 Joel Jaeggli [Ballot comment]
support richards discussion, the security/privacy considerations could use some wordsmithing.
2013-08-14
09 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2013-08-14
09 Richard Barnes
[Ballot discuss]
(D1) The privacy considerations make no sense to me.  To whom is data being leaked?  To the browser?  To random people who send …
[Ballot discuss]
(D1) The privacy considerations make no sense to me.  To whom is data being leaked?  To the browser?  To random people who send a request to a URI?  Do you mean that X-Frame-Options leaks information about who the site authorizes?  That's true, but also true of things like CORS.  If this is the concern, you should recommend a mitigation that's basically the same as what CORS does, namely varying the value of X-Frame-Options based on the Referer or Origin header.

(D2) It seems like this is a value that browsers might cache, to avoid unnecessary requests if the same page is framed in the future.  If this is something browsers do today, please say so. 

(D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI?  In other words, what does it mean to send "X-Frame-Options: ALLOW-FROM https://example.com/this/is/a/path?query#fragment"? 

(D3) In the ALLOW-FROM: what does "top level context" mean?  Do you really mean the top level here, as opposed to the next one up?  For example, suppose A loads B in an iframe, and B loads C, and then C sends an X-Frame-Options header with ALLOW-FROM.  Is the ALLOW-FROM origin compared to B or A?  In either case, you should also note the attacks that remain.  For example, if the answer is B, then B needs to use X-Frame-Options as well, or else, A can maliciously frame A within B.  Or if the answer is A, then C is trusting A not to load any malicious intermediate frames B.
2013-08-14
09 Richard Barnes
[Ballot comment]
(C1) In the Introduction, the phrase "secure web page" would seem to imply that this mechanism only applies to pages delivered over HTTPS, …
[Ballot comment]
(C1) In the Introduction, the phrase "secure web page" would seem to imply that this mechanism only applies to pages delivered over HTTPS, which I'm pretty sure isn't true.  Suggest just deleting "secure".

(C2) In Section 2.1, the sentence starting "And the algorithm" seems to imply that ALLOW-FROM allows SAMEORIGIN requests as well, which I think you actually mean something like:
"""
And the algorithm to compare origins from [RFC6454] SHOULD be used to verify that a referring page is of the same origin as the content (in the case of SAMEORIGIN) or that the referring page's origin is identical with the ALLOW-FROM URI (in the case of ALLOW-FROM).
"""
2013-08-14
09 Richard Barnes [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes
2013-08-14
09 Stephen Farrell
[Ballot comment]

(Personal opinion only, no change requested unless it
resonates with folks.) I would prefer that this not say
that NoScript impairs broswer utility. …
[Ballot comment]

(Personal opinion only, no change requested unless it
resonates with folks.) I would prefer that this not say
that NoScript impairs broswer utility. I find it fine.

Other than that, this is a fine draft, thanks.
2013-08-14
09 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2013-08-14
09 Pete Resnick [Ballot comment]
Why is this document not on the standards track?
2013-08-14
09 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-08-14
09 Ted Lemon
[Ballot comment]
The introduction of the concept of origins in 2.1 is a bit clumsy—the term is used under the SAMEORIGIN heading without being defined, …
[Ballot comment]
The introduction of the concept of origins in 2.1 is a bit clumsy—the term is used under the SAMEORIGIN heading without being defined, and is later defined as a constraint specific only to ALLOW-FROM.  Text about browser implementations for SAMEORIGIN and ALLOW-FROM is repeated here and in later sections.  It would be better to simply refer to the later section.  If I were to clean up this section, I would do something like the following:

DENY
        A browser receiving content with this header MUST NOT display
        this content in any frame.

  SAMEORIGIN
        A browser receiving content with this header field MUST NOT
        display this content in any frame from a page of different
        origin than the content itself.
        If a browser or plugin can not reliably determine whether the
        origin of the content and the frame have the same origin, this
        MUST be treated as "DENY".  Section 2.3.2.2 documents
        variations in the handling of this header field by different
        browsers.

  ALLOW-FROM  (followed by a URI [RFC3986] of a trusted origin)
        A browser receiving content with this header MUST NOT display
        this content in a frame from any page with a top-level browsing
        context of different origin than the specified origin.  While
        this can expose the page to risks by the trusted origin, in
        some cases it may be necessary to allow the framing by content
        from other domains.

  The meaning of the term "origin" is given in [RFC6454].
  If the ALLOW-FROM value is used, it MUST be followed by a valid URI.
  Any data beyond the domain address (i.e.  any data after the "/"
  separator) is to be ignored.  And the algorithm to compare origins
  from [RFC6454] SHOULD be used to verify that a referring page is of
  the same origin as the content or that the referring page's origin is
  identical with the ALLOW-FROM URI.  Though in conflict with
  [RFC6454], current implementations do not consider the port as a
  defining component of the origin.

I also noticed that in another exchange about this document, someone said that this document is not intended to give advice to browser vendors.  If that's the case, what is the above SHOULD doing in the text?  Is there uncertainty as to what implementations do?  If so, it would be better to express that uncertainty, if indeed you are documenting browser behavior.

Also, with respect to this text:

  Though in conflict with
  [RFC6454], current implementations do not consider the port as a
  defining component of the origin.

Does this mean that http://www.foo.com and http://www.foo.com:8080 are considered equivalent, or that http://www.foo.com and http://www.foo.com:80 are _not_ considered equivalent?  What about http://www.foo.com and https://www.foo.com?

The following text is incomprehensible to me as a non-domain-expert:

  The criteria for the SAMEORIGIN option is not evaluated unanimously
  either: one implementation may evaluate the SAMEORIGIN option based
  on the origin of the framed page and the framing page, while another
  may evaluate based on the framed page and the top-level browsing-
  context.

What is the distinction between "top-level browsing context" and "origin of the framing page?"  A reference here would be helpful.

Thanks for documenting this.
2013-08-14
09 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2013-08-14
09 Sean Turner
[Ballot discuss]
It's interesting to note that this draft says there's a problem with folks not checking the origins of the entire ancestor tree of …
[Ballot discuss]
It's interesting to note that this draft says there's a problem with folks not checking the origins of the entire ancestor tree of names of the framing resource - but then doesn't say that sounds like a good idea do it.  I can see the argument that might be made that this draft is just documenting what's done now, but shouldn't we take the opportunity to do more and recommend something along the lines of "The entire ancestor tree of names of the framing resource SHOULD be checked to mitigate the risk of attacks in multiple-nested scenarios" or something like that?
2013-08-14
09 Sean Turner
[Ballot comment]
I'd ask about how RFC 6648 applies to this, but I bet this header was out long before the drafts that lead to …
[Ballot comment]
I'd ask about how RFC 6648 applies to this, but I bet this header was out long before the drafts that lead to RFC 6648.

s1 (penultimate paragraph): r/script/Javascript ?

s4.1: Is Figure 1 missing or is that the registration template? ;)

s5:
r/all kinds of these attack vectors/these kind of attack vectors
r/, ...)/)

Appendix A: Is this a guarantee that x-frame-options/frame-options will be supported henceforth until the end of time in those browsers?  Basically, I'm not sure Appendix A is needed.
2013-08-14
09 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner
2013-08-14
09 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-08-13
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2013-08-13
09 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2013-08-13
09 Tobias Gondrom New version available: draft-ietf-websec-x-frame-options-09.txt
2013-08-12
08 Spencer Dawkins
[Ballot comment]
I really like this specification, and I appreciate the working group producing it. Documenting "in the wild" behavior is a good thing.

I …
[Ballot 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.

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.

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?

5.1.  Privacy Considreations should be "Considerations".

In B.2.  Online Shop Confirm Purchase Page

  The "Confirm Purchase""

The doubled trailing quote marks should be one quote mark, perhaps?
2013-08-12
08 Spencer Dawkins Ballot comment text updated for Spencer Dawkins
2013-08-12
08 Spencer Dawkins
[Ballot comment]
I really like this specification, and I appreciate the working group producing it. Documenting "in the wild" behavior is a good thing.

I …
[Ballot 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.

My nits, just so editors don't have to find them again:

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?

5.1.  Privacy Considreations should be "Considerations".

In B.2.  Online Shop Confirm Purchase Page

  The "Confirm Purchase""

The doubled trailing quote marks should be one quote mark, perhaps?
2013-08-12
08 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2013-08-12
08 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2013-08-12
08 Barry Leiba Ballot has been issued
2013-08-12
08 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2013-08-12
08 Barry Leiba Created "Approve" ballot
2013-08-12
08 Barry Leiba Ballot writeup was changed
2013-08-12
08 Barry Leiba State changed to IESG Evaluation from Waiting for AD Go-Ahead
2013-08-12
08 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2013-08-11
08 Tobias Gondrom IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2013-08-11
08 Tobias Gondrom New version available: draft-ietf-websec-x-frame-options-08.txt
2013-08-08
07 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2013-08-08
07 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2013-08-08
07 Robert Sparks Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Robert Sparks.
2013-08-08
07 Jean Mahoney Closed request for Last Call review by GENART with state 'Withdrawn'
2013-08-08
07 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2013-08-08
07 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2013-08-08
07 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2013-08-08
07 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-websec-x-frame-options-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-websec-x-frame-options-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that there is a single action required to be completed upon approval of this document.

In the Permanent Message Header Field Names subregistry of the Message Headers registry located at:

http://www.iana.org/assignments/message-headers

a new message header field name is to be registered as follows:

Header Field Name: X-Frame-Option
Template:
Protocol: http
Status: informational
Reference: [ RFC-to-be ]

NOTE: We will initiate a request and send this to the designated expert
for review.  We will inform you the review result accordingly.

We understand that this is the only action required upon approval of
this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.
2013-08-02
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Joseph Salowey
2013-08-02
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Joseph Salowey
2013-08-02
07 Jean Mahoney Request for Last Call review by GENART is assigned to Ben Campbell
2013-08-02
07 Jean Mahoney Request for Last Call review by GENART is assigned to Ben Campbell
2013-07-29
07 Amy Vezza IANA Review state changed to IANA - Review Needed
2013-07-29
07 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (HTTP Header Field X-Frame-Options) to …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (HTTP Header Field X-Frame-Options) to Informational RFC


The IESG has received a request from the Web Security WG (websec) to
consider the following document:
- 'HTTP Header Field X-Frame-Options'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-08-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  To improve the protection of web applications against Clickjacking,
  this specification describes the X-Frame-Options HTTP response header
  field that declares a policy communicated from the server to the
  client browser on whether the browser may display the transmitted
  content in frames that are part of other web pages.  This
  informational document serves to document the existing use and
  specification of this X-Frame-Options HTTP response header field.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ballot/


No IPR declarations have been submitted directly on this I-D.


2013-07-29
07 Amy Vezza State changed to In Last Call from Last Call Requested
2013-07-29
07 Barry Leiba Notification list changed to : websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org
2013-07-29
07 Barry Leiba Placed on agenda for telechat - 2013-08-15
2013-07-29
07 Barry Leiba Last call was requested
2013-07-29
07 Barry Leiba Last call announcement was generated
2013-07-29
07 Barry Leiba Ballot approval text was generated
2013-07-29
07 Barry Leiba State changed to Last Call Requested from AD Evaluation
2013-07-29
07 Tobias Gondrom New version available: draft-ietf-websec-x-frame-options-07.txt
2013-07-28
06 Tobias Gondrom New version available: draft-ietf-websec-x-frame-options-06.txt
2013-07-15
05 Amy Vezza
Summary
=======

Yoav Nir is the Document Shepherd. Barry Leiba is the Responsible
Area Director.

This informational document serves to document the existing use and …
Summary
=======

Yoav Nir is the Document Shepherd. Barry Leiba is the Responsible
Area Director.

This informational document serves to document the existing use and
specification of this X-Frame-Options HTTP response header field.

To improve the protection of web applications against Clickjacking,
this specification describes the X-Frame-Options HTTP response
header field that declares a policy communicated from the server to
the client browser on whether the browser may display the transmitted
content in frames that are part of other web pages. 


Review and Consensus
====================

In 2009 and 2010 many browser vendors introduced the use of a non-
standard HTTP header field "X-Frame-Options" to protect against
Clickjacking. There have been differences between the various
implementations which may cause security and interoperability
concerns. This draft has been produced as informational by the websec
working group to document the current use and also to function as a
baseline for the future unified standard as part of the currently
produced Content Security Policy 1.1 (by WebAppSec at the W3C) - and
to get rid of the deprecated "X-" (see RFC6648).
The review process took sufficient time and involved a medium amount
of people with deep browser security knowledge. During the review
process no major controversies came up, which is not too surprising
as the draft is intended as informational and documenting.


Intellectual Property
=====================

Each author has confirmed conformance with BCPs 78 and 79.
Tobias confirmed. David has also confirmed.

Other Points
============

None.
2013-07-15
05 Barry Leiba State changed to AD Evaluation from Publication Requested
2013-07-15
05 Barry Leiba Ballot writeup was changed
2013-07-15
05 Barry Leiba Ballot writeup was generated
2013-07-15
05 Barry Leiba Notification list changed to : websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org
2013-07-15
05 Barry Leiba State changed to Publication Requested from AD is watching
2013-07-15
05 Barry Leiba Changed consensus to Yes from Unknown
2013-07-15
05 Yoav Nir IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2013-07-15
05 Yoav Nir Annotation tag Revised I-D Needed - Issue raised by WGLC cleared.
2013-07-15
05 Yoav Nir Changed document writeup
2013-07-15
05 Yoav Nir Changed document writeup
2013-07-15
05 Yoav Nir Document shepherd changed to Yoav Nir
2013-07-15
05 Tobias Gondrom New version available: draft-ietf-websec-x-frame-options-05.txt
2013-06-28
04 Tobias Gondrom New version available: draft-ietf-websec-x-frame-options-04.txt
2013-06-21
03 Tobias Gondrom New version available: draft-ietf-websec-x-frame-options-03.txt
2013-02-25
02 Tobias Gondrom New version available: draft-ietf-websec-x-frame-options-02.txt
2012-11-16
01 Barry Leiba State Change Notice email list changed to websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, alexey.melnikov@isode.com
2012-11-16
01 Barry Leiba Intended Status changed to Informational
2012-11-16
01 Barry Leiba IESG process started in state AD is watching
2012-11-16
01 (System) Earlier history may be found in the Comment Log for draft-gondrom-x-frame-options
2012-11-08
01 Alexey Melnikov IETF state changed to In WG Last Call from WG Document
2012-11-08
01 Alexey Melnikov Annotation tag Revised I-D Needed - Issue raised by WGLC set.
2012-11-08
01 Alexey Melnikov WGLC ends on November 16th as per email from Yoav
2012-11-08
01 Alexey Melnikov Changed shepherd to Alexey Melnikov
2012-10-22
01 Tobias Gondrom New version available: draft-ietf-websec-x-frame-options-01.txt
2012-07-03
00 Tobias Gondrom New version available: draft-ietf-websec-x-frame-options-00.txt