HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields
draft-ietf-httpbis-auth-info-05

IESG/Author/WG Chairs:

IANA has reviewed draft-ietf-httpbis-auth-info-04.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has questions about the actions requested in this draft.

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

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

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

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

two existing registrations will be updated as follows:

OLD:
Authentication-Info http [RFC4229]

Proxy-Authentication-Info http [RFC4229]

NEW:
Header Field Name: Authentication-Info
Protocol: http
Status: standard
Reference: Section 3, [ RFC-to-be ]

Header Field Name: Proxy-Authentication-Info
Protocol: http
Status: standard
Reference: Section 4, [ RFC-to-be ]

Questions/Comment:
1) Is this draft intended to obsolete/replace RFC4229?  Are the author
intended to replace the existing reference RFC4229 for the two entries
with this draft?  Or should this draft be an additional reference for
the two existing entries?  (P.S. we cannot find a pointer indicating
that this draft obsoletes RFC4229.)

2) As this document requests registrations in an Expert Review registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that this is the only action required to be completed 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy-Authentication-Info Response Header Fields) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document:
- ' The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy-
  Authentication-Info Response Header Fields'
  as Proposed Standard

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 2015-04-02. 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

  This specification defines the "Authentication-Info" and "Proxy-
  Authentication-Info" response header fields for use in HTTP
  authentication schemes which need to return information once the
  client's authentication credentials have been accepted.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-auth-info/

When IESG discussion begins, it can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-auth-info/ballot/

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

1. Summary

The document shepherd is Mark Nottingham; the responsible Area Director
is Barry Leiba.

This specification defines the "Authentication-Info" and
"Proxy-Authentication-Info" response header fields, for use in HTTP
authentication schemes that need to return information once the
client's authentication credentials have been accepted.


2. Review and Consensus

This document separates the definition of the "Authentication-Info" and
"Proxy-Authentication-Info" HTTP header fields from RFC2617, so that
they can be used by other HTTP authentication schemes (including some
being actively developed).

As such, the header fields have already enjoyed implementation and
deployment; we have merely re-specified them for more generic use.
Because other Working Groups depend upon this specification to progress
their work items, we have done this work fairly quickly, but with care.

The resulting specification has been reviewed by several Working Group
members, and after a small amount of discussion, its content has been
uncontroversial.


3. Intellectual Property

Julian Reschke has confirmed that any IPR he's personally aware of
related to this document has been disclosed. No other discussion of
related IPR has taken place.


4. Other Points

The document does not contain any downreferences.

This document updates the IANA Message Headers registry, and contains
clear instructions. It does not establish any new registries.

# Shepherd Writeup for auth-info

## 1. Summary

The document shepherd is Mark Nottingham; the responsible Area Director is Barry Leiba.

This specification defines the "Authentication-Info" and "Proxy-Authentication-Info" response header fields for use in HTTP authentication schemes which need to return information once the client's authentication credentials have been accepted.


## 2. Review and Consensus

This document separates the definition of the "Authentication-Info" and "Proxy-Authentication-Info" HTTP header fields from RFC2617, so that they can be used by other HTTP authentication schemes (including some being actively developed).

As such, the header fields have already enjoyed implementation and deployment; we have merely re-specified them for more generic use. Because other Working Groups depend upon this specification to progress their work items, we have done this work fairly quickly, but with care.

The resulting specification has been reviewed by several Working Group members, and after a small amount of discussion, its content has been uncontroversial.


## 3. Intellectual Property

Julian Reschke has confirmed that any IPR he's personally aware of related to this document has been disclosed. No other discussion of related IPR has taken place.


## 4. Other Points

The document does not contain any downreferences.

This document updates the IANA Message Headers registry, and contains clear instructions. It does not establish any new registries.