APPSDIR review of draft-ietf-httpbis-p7-auth-24

[mnot]

Minor Issues:

In Section 1:

"HTTP provides several OPTIONAL challenge-response authentication schemes that can be used by a server to challenge a client request and by a client to provide authentication information."

I suggest using RFC 2119 after Section 1.2. - see #515

Nits:

In Section 2.1:

"Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information."

The RFC 2119 "may" is unnecessary. - see 2446

Reported by julian.reschke@gmx.de, migrated from https://trac.ietf.org/trac/httpbis/ticket/513

[mnot]

julian.reschke@gmx.de commented:

From 2446:

Replace unneeded "MAY" by "can" (see #513)

[mnot]

julian.reschke@gmx.de changed description from:

Minor Issues:

In Section 1:

"HTTP provides several OPTIONAL challenge-response authentication schemes that can be used by a server to challenge a client request and by a client to provide authentication information."

I suggest using RFC 2119 after Section 1.2.

Nits:

In Section 2.1:

"Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information."

The RFC 2119 "may" is unnecessary.

to:

Minor Issues:

In Section 1:

"HTTP provides several OPTIONAL challenge-response authentication schemes that can be used by a server to challenge a client request and by a client to provide authentication information."

I suggest using RFC 2119 after Section 1.2.

Nits:

In Section 2.1:

"Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information."

The RFC 2119 "may" is unnecessary. - see 2446

[mnot]

julian.reschke@gmx.de changed description from:

Minor Issues:

In Section 1:

"HTTP provides several OPTIONAL challenge-response authentication schemes that can be used by a server to challenge a client request and by a client to provide authentication information."

I suggest using RFC 2119 after Section 1.2.

Nits:

In Section 2.1:

"Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information."

The RFC 2119 "may" is unnecessary. - see 2446

to:

Minor Issues:

In Section 1:

"HTTP provides several OPTIONAL challenge-response authentication schemes that can be used by a server to challenge a client request and by a client to provide authentication information."

I suggest using RFC 2119 after Section 1.2. - see #515

Nits:

In Section 2.1:

"Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information."

The RFC 2119 "may" is unnecessary. - see 2446

[mnot]

• julian.reschke@gmx.de commented:

all items either fixed or tracked separately

• julian.reschke@gmx.de changed resolution to incorporated
• julian.reschke@gmx.de changed status from new to closed
• julian.reschke@gmx.de changed type from design to editorial

[mnot]

julian.reschke@gmx.de changed severity from In WG Last Call to In IETF LC