Lukasa/notes.txt

## notes.txt
- Notes on draft-ietf-httpauth-extension-05
	- Abstract
		- “This document specifies a few extensions”
			- The “a few” feels informal to me: consider removing.
		- “fundamental features of HTTP-level authentication is not enough for complex”
			- s/is not enough/are insufficient/
		- “This makes these applications to implement"
			- s/makes/forces/
		- “user-agent clients”
			- Are there non-user-agent clients? If not, remove “clients” and just use “user-agents”.
	- 1. Introduction
		- “to provide enough functionality”
			- Remove the word “enough”.
		- “Web-sites”
			- Generally this is rendered in English as “websites”, one word with no leading capital letter.
		- “HTTP Basic (and Digest, too)”
			- Change to “HTTP Basic and Digest”.
		- “(including a good-feeling user interfaces)”
			- Change to “(including good user interfaces)”.
		- “to support most of realistic”
			- Remove the word “of”.
		- “However, the method is”
			- s/the/this/
		- “because the whole behavior of the implementation”
			- Change to “because all of the implementation”
		- “server-side applications”
			- Change to “server-side application”.
		- “non-mandatory, optional authentication on HTTP”
			- Change to “optional HTTP authentication”. This is because “non-mandatory” and “optional” mean the same thing.
	- 2. Definitions
		- “may involve with several”
			- Replace with “may involve several”.
		- For new terminology:
			- It’s somewhat confusing that the authors use a bulleted list for requests and a numbered list for responses. I recommend using numbered lists in both places.
		- “A non-authenticated response: is”
			- Remove the colon.
			- This should be done for every list item in the new response terminology.
		- “involve with any HTTP authentication”
			- Replace with “involve any HTTP authentication”.
		- “It may not contain any WWW-Authenticate”
			- Is this may not, or does not?
		- “not-authentication-related”
			- s/not/non/
		- “considered as non-authenticated”
			- Remove “as”.
		- “protected by HTTP authentication”
			- Change to “protected by a HTTP authentication”.
		- “request is non-authenticating”
			- Change to “requests is a non-authenticating”
		- “directed to the protection space (realm) other than the server’s expected one”
			- Change to “directed to a protection space  (realm) other than the one the server expected”.
		- “Upon reception"
			- Change to “Upon receiving this response”
		- “If the client may have no prior knowledge on authentication”
			- Change to “If the client has no prior knowledge of authentication”
		- “client already have an enough authentication credentials”
			- Change to “client already has enough authentication credentials”
		- “requires an authentication”
			- Change to “requires authentication”.
		- “requires some more reaction”
			- Change to “requires more action”
		- “without another authentication credential”
			- Change to “without a different set of authentication credentials”
		- “of the currently-using credentials”
			- Change to “of the active credentials”
		- “Client can distinguish it by”
			- Change to “Clients can distinguish negatively-authenticated responses from authentication-initializing responses by”
		- “specifying syntax of header values"
			- Change to: “specifying the syntax of header values”
		- “uses the following syntax elements following syntax definitions”
			- Change to “uses the following syntax definitions”
		- “use the extension-tokens with format”
			- Change to “use extension-tokens with the format”
	- 3. Optional Authentication
		- “it is implemented using HTTP cookies"
			- Change to “this functionality is implemented using HTTP cookies”
		- “custom form-based authentications”
			- Change to “custom form-based authentication”
		- “Servers MAY send successful HTTP responses (response code 200, 206 and others)”
			- Aren’t all 2XX codes successful? If not all 2XX codes are able to use the Optional-WWW-Authenticate header, this section should probably explain why not. Otherwise, change to “Servers MAY send successful HTTP responses (any 2XX response code)”
		- “when it is an authentication-initializing response”
			- Change to “when the response is authentication-initializing”.
		- “MUST NOT be contained in 401 responses”
			- Change to “MUST NOT be sent on 401 responses”
			- May a server send it on 404s or other status codes? It may be better to whitelist the allowed status codes rather than specifically blacklist 401.
		- “a 401 responses corresponding for a same request"
			- Change to “a 401 response corresponding to the same request”.
		- “Failure to comply this rule will make client not able to distinguish”
			- Change to “Failure to comply with this rule will render clients unable to distinguish”
		- “Whenever an authentication scheme support for servers to send some parameter"
			- Change to “Whenever an authentication scheme supports servers sending some parameter”
		- “hint of URL space"
			- Change to “hint of the URL space”
	- 4. Authentication-Control header
		- “will be generated usually by the Web servers"
			- Change to “which will usually be generated by web servers”.
		- “WWW-Authenticate (or Optional-WWW-Authenticate defined in this extension) header”
			- Change to “WWW-Authenticate header (or the Optional-WWW-Authenticate header defined in this extension)”.
		- “determine the scheme and realm to perform an authentication"
			- Change to “determine the scheme and realm they will use to authenticate”
		- “and the entries corresponding to the scheme and real will be meaningful”
			- I don’t understand what this is attempting to say, so it’s hard for me to correct the language. Consider rewording or removing.
		- “the scheme and a realm"
			- Change to “the scheme and realm”
		- “MUST NOT contain the duplicated parameters”
			- Change to “MUST NOT contain duplicated parameters”
		- “it is encouraged t be sent”
			- Change to “implementations SHOULD send the parameter”
		- “If it is defined as a token”
			- Change to “If the parameter is defined as a token”
		- “and is encouraged to be sent in an unquoted form"
			- Change to “and SHOULD be sent in an unquoted form”
		- “Server-side application SHOULD always be reminded that”
			- Change to “Server-side applications SHOULD always be reminded that”.
			- Should there be normative language here? It’s not clear what purpose it serves. Consider rewording to something like: “Server-side applications need to be aware that”
		- “circumvent semantics of this header"
			- Change to: “circumvent the semantics of this header”.
		- “MUST be limited for providing some non-fundamental”
			- Change to: “MUST be limited to providing some non-fundamental”
		- “Server-side application MUST NOT rely”
			- Change to: “Server-side applications MUST NOT rely”
		- “the field MUST be sent in clear using plain RFC 7235 syntax”
			- Change to: “the field MUST be sent in the clear using plain RFC 7235 syntax”
		- “Such parameter MUST have charset value of”
			- Change to: “Such a parameter MUST have a charset value of"
		- “The same parameter must MUST NOT be sent twice or more, those in both plain- and extended-syntax.
			- Change to: “The same parameter MUST NOT use sent more than once, for both parameters in plain- and extended-syntax.”
		- “with value “Renee or France””
			- Change to: “with value “Renee of France””
		- “specifies the server’s preferences over user interface behavior”
			- Change to: “specifies the server’s preferences for user interface behavior”
		- “included in any kind of responses”
			- Change to: “included in any kind of response"
		- “users refusing authentication request"
			- Change to: “users refusing the authentication request”
		- “expected to ask the user a password”
			- Change to: “expected to ask the user for a password”
		- “then provide users opportunities to perform authentication"
			- Change to: “then provide users the opportunity to perform authentication”
		- “default behaviour for the clients is implementation-dependant”
			- Change to: “default behaviour for clients is implementation-dependant”
		- “response for authentication-initializing response”
			- Change to: “response for an authentication-initializing response”
		- “although NOT RECOMMENDED”
			- Change to: “although this is NOT RECOMMENDED”
			- This chunk appears in more than one location in section 4: change it throughout the section.
		- “The clients MUST ignore this parameter, when a response"
			- Change to: “Clients MUST ignore this parameter when a response”
			- This chunk appears in more than one location in section 4: change it throughout the section.
		- “The clients SHOULD ignore this parameter”
			- Change to: “Clients SHOULD ignore this parameter”
			- This chunk appears in more than one location in section 4: change it throughout the section.
		- “it specifies that new authentication attempt is not to be performed on this location for better user experience”
			- Change to: “it specifies that new authentication attempts are not to be performed on this location in order to improve the user experience”
		- “a (Web content’s level) explicit interaction of users is desired before authentications”
			- Change to: “an explicit user interaction with the web content is desired before authentication”
		- “instead of giving user an opportunity to start”
			- Change to: “instead of giving the user an opportunity to start”
		- “this parameter MUST ignored”
			- Change to: “this parameter MUST be ignored”
		- “be used as any security measures"
			- Change to: “be used as a security measure”
		- “the user explicitly request a logout"
			- Change to: “the user explicitly requests a logout”
		- “the user requests to terminate an authentication period"
			- Change to: “the user requests termination of an authentication period"
			- This chunk appears in more than one location in section 4.5: change it throughout the section.
		- “authentication credentials and states”
			- Change to: “authentication credentials and state"
		- “has been passed from the time received"
			- Change to: “has passed since the time this header was received”
		- “the long-term memories for the passwords”
			- Change to: “the long-term memories for passwords and password-related details”
		- “scheme to be used has syntax limitation on allowed user names"
			- Change to: “scheme to be used has a syntax limitation on allowed user names”
		- “Client SHOULD ignore any values which do not conform"
			- Change to: “Clients SHOULD ignore any values which do not conform"
		- “but doing it will give bad user"
			- Change to: “but doing so will give bad user”
		- “requires specific style of text preparation"
			- Change to: “requires a specific style of text preparation"
	- 5. Usage examples (informative)
		- “If this assumption is not hold, texts below provides”
			- Change to: “If this assumption is not valid, the text below provides”
		- “Without explicit notices”
			- Change to: “When not explicitly specified”
		- “regardless of authentication statuses"
			- Change to: “regardless of the authentication status"
		- “most of web pages are available for guest (unauthenticated) users"
			- Change to: “most web pages are available for guest (unauthenticated) users”
		- “contents of these pages are customized"
			- Change to: “the content of these pages is customised”
		- “does not need a specific actions upon log-in”
			- Change to: “does not require specific actions upon log-in"
		- “available to authenticated users, Set up”
			- Change to: “available to authenticated users, set up”
			- This chunk appears in more than one place in Section 5: change it throughout the section.
		- “No specific pages for authentication is needed"
			- Change to: “No specific pages for authentication are needed”
		- “If the site will have one"
			- Change to: “If the site has one”
		- “If the site needs a specific actions upon log-out"
			- Change to: “If the site requires specific actions upon log-out”
		- “All shown in the Case 1 are to be applied"
			- Change to: “All settings in Case 1 are applied”
		- “In the de-authentication pages”
			- Change to: “In the de-authentication page”
		- “If there is any direct links to it"
			- Change to: “If there are any direct links to the de-authentication page”
		- “(some announces, user notices”
			- Change to: “(some announcements, user notices”
		- “to all pages available to guest"
			- Change to: “to all pages available to guests”
		- “for the specific log-in page, Set up"
			- Change to: “for the specific log-in page, set up”
		- “If the site will have one"
			- Change to: “If the site has one”
			- This chunk appears in more than one place in Section 5: change it throughout the section.
		- “If almost all pages in the target site requires authentication”
			- Change to: “If almost all pages in the target site require authentication"
		- “or there are no needs to support both"
			- Change to: “or if there is no need to support both"
		- “the setting will become somewhat simple”
			- Change to: “the settings become simpler”
		- “an example to realize such a site"
			- Change to: “an example for such a site”
		- “all pages available to authenticated"
			- Change to: “all pages available to authenticated users”
		- “In the current Web sites using Form-based authentications”
			- “In current web sites using form-based authentication"
		- “In some cases, there will be some ambiguous situations whether some functions are authorization management or session management”
			- Change to: “In some cases there will be ambiguity about whether some functions are for authorization management or for session management”
		- “for deciding which features to be used"
			- Change to: “for deciding which features to use”
		- “the main requirement for such feature"
			- Change to: “the main requirement for such a feature"
		- “protect users from their consoles and browsers hijacked”
			- Change to: “protect users from having their consoles and browsers hijacked”
		- “On the other hand, the requirements is to protect the server’s privilege”
			- Change to: “On the other hand, if the requirement is to protect the server’s privilege”
		- “support both HTTP-layer and Form-based authentications”
			- Change to: “support both HTTP-layer and Form-based authentication"
		- “should identify which authentication are used for the session"
			- Change to: “should identify which authentication has been used for the session”
		- “put the following things to the Web pages"
			- Change to: “add the following things to the web pages”
		- “if users are not authenticated, it may have a diversion for HTTP-level authentication"
			- “if users are not authenticated, the page may have a diversion for HTTP-level authentication”
		- “Users are identified for authorizations”
			- Change to: “Users are identified to authorization”
		- “both ones should match"
			- Change to: “both should match”
		- “Cookie tied to an HTTP authentication"
			- Change to: “Cookie tied to HTTP authentication”
	- 6. Methods to extend this protocol
		- “The extension-tokens MUST be with format"
			- Change to: “Any extension-tokens MUST use the format”
	- 8. Security Considerations
		- “Server application implementer SHOULD"
			- “The server application implementer SHOULD”
		- “protect server-side resources, such features MUST”
			- Change to: “protect server-side resources, this protection MUST”
		- “Server-side applications MUST be implemented always considering that"
			- Change to: “Server-side applications MUST always consider that”
			- A note: how will this normative language ever be enforced? May be worth changing this to something non-normative.
		- “Especially, it SHOULD NOT be used"
			- Change to: “Most importantly, the “username” parameter SHOULD NOT be used”
		- “in any case where the valid user names are configured by its users”
			- Change to: “in any case where the valid user names are configured by users”
	- Appendix A
		- “This section provides cross-reference table about applicability of each features provided in this specification for each kinds of responses described in Section 2.1”
			- Change to: “This section provides a cross-reference table showing the applicability of the features provided in this specification to each kind of response described in Section 2.1”
	- Appendix B
		- “meaning of WWW-Authenticate headers"
			- Change to: “the meaning of WWW-Authenticate headers"
	- Notes on draft-ietf-httpauth-extension-05
	- Abstract
	- “This document specifies a few extensions”
	- The “a few” feels informal to me: consider removing.
	- “fundamental features of HTTP-level authentication is not enough for complex”
	- s/is not enough/are insufficient/
	- “This makes these applications to implement"
	- s/makes/forces/
	- “user-agent clients”
	- Are there non-user-agent clients? If not, remove “clients” and just use “user-agents”.
	- 1. Introduction
	- “to provide enough functionality”
	- Remove the word “enough”.
	- “Web-sites”
	- Generally this is rendered in English as “websites”, one word with no leading capital letter.
	- “HTTP Basic (and Digest, too)”
	- Change to “HTTP Basic and Digest”.
	- “(including a good-feeling user interfaces)”
	- Change to “(including good user interfaces)”.
	- “to support most of realistic”
	- Remove the word “of”.
	- “However, the method is”
	- s/the/this/
	- “because the whole behavior of the implementation”
	- Change to “because all of the implementation”
	- “server-side applications”
	- Change to “server-side application”.
	- “non-mandatory, optional authentication on HTTP”
	- Change to “optional HTTP authentication”. This is because “non-mandatory” and “optional” mean the same thing.
	- 2. Definitions
	- “may involve with several”
	- Replace with “may involve several”.
	- For new terminology:
	- It’s somewhat confusing that the authors use a bulleted list for requests and a numbered list for responses. I recommend using numbered lists in both places.
	- “A non-authenticated response: is”
	- Remove the colon.
	- This should be done for every list item in the new response terminology.
	- “involve with any HTTP authentication”
	- Replace with “involve any HTTP authentication”.
	- “It may not contain any WWW-Authenticate”
	- Is this may not, or does not?
	- “not-authentication-related”
	- s/not/non/
	- “considered as non-authenticated”
	- Remove “as”.
	- “protected by HTTP authentication”
	- Change to “protected by a HTTP authentication”.
	- “request is non-authenticating”
	- Change to “requests is a non-authenticating”
	- “directed to the protection space (realm) other than the server’s expected one”
	- Change to “directed to a protection space (realm) other than the one the server expected”.
	- “Upon reception"
	- Change to “Upon receiving this response”
	- “If the client may have no prior knowledge on authentication”
	- Change to “If the client has no prior knowledge of authentication”
	- “client already have an enough authentication credentials”
	- Change to “client already has enough authentication credentials”
	- “requires an authentication”
	- Change to “requires authentication”.
	- “requires some more reaction”
	- Change to “requires more action”
	- “without another authentication credential”
	- Change to “without a different set of authentication credentials”
	- “of the currently-using credentials”
	- Change to “of the active credentials”
	- “Client can distinguish it by”
	- Change to “Clients can distinguish negatively-authenticated responses from authentication-initializing responses by”
	- “specifying syntax of header values"
	- Change to: “specifying the syntax of header values”
	- “uses the following syntax elements following syntax definitions”
	- Change to “uses the following syntax definitions”
	- “use the extension-tokens with format”
	- Change to “use extension-tokens with the format”
	- 3. Optional Authentication
	- “it is implemented using HTTP cookies"
	- Change to “this functionality is implemented using HTTP cookies”
	- “custom form-based authentications”
	- Change to “custom form-based authentication”
	- “Servers MAY send successful HTTP responses (response code 200, 206 and others)”
	- Aren’t all 2XX codes successful? If not all 2XX codes are able to use the Optional-WWW-Authenticate header, this section should probably explain why not. Otherwise, change to “Servers MAY send successful HTTP responses (any 2XX response code)”
	- “when it is an authentication-initializing response”
	- Change to “when the response is authentication-initializing”.
	- “MUST NOT be contained in 401 responses”
	- Change to “MUST NOT be sent on 401 responses”
	- May a server send it on 404s or other status codes? It may be better to whitelist the allowed status codes rather than specifically blacklist 401.
	- “a 401 responses corresponding for a same request"
	- Change to “a 401 response corresponding to the same request”.
	- “Failure to comply this rule will make client not able to distinguish”
	- Change to “Failure to comply with this rule will render clients unable to distinguish”
	- “Whenever an authentication scheme support for servers to send some parameter"
	- Change to “Whenever an authentication scheme supports servers sending some parameter”
	- “hint of URL space"
	- Change to “hint of the URL space”
	- 4. Authentication-Control header
	- “will be generated usually by the Web servers"
	- Change to “which will usually be generated by web servers”.
	- “WWW-Authenticate (or Optional-WWW-Authenticate defined in this extension) header”
	- Change to “WWW-Authenticate header (or the Optional-WWW-Authenticate header defined in this extension)”.
	- “determine the scheme and realm to perform an authentication"
	- Change to “determine the scheme and realm they will use to authenticate”
	- “and the entries corresponding to the scheme and real will be meaningful”
	- I don’t understand what this is attempting to say, so it’s hard for me to correct the language. Consider rewording or removing.
	- “the scheme and a realm"
	- Change to “the scheme and realm”
	- “MUST NOT contain the duplicated parameters”
	- Change to “MUST NOT contain duplicated parameters”
	- “it is encouraged t be sent”
	- Change to “implementations SHOULD send the parameter”
	- “If it is defined as a token”
	- Change to “If the parameter is defined as a token”
	- “and is encouraged to be sent in an unquoted form"
	- Change to “and SHOULD be sent in an unquoted form”
	- “Server-side application SHOULD always be reminded that”
	- Change to “Server-side applications SHOULD always be reminded that”.
	- Should there be normative language here? It’s not clear what purpose it serves. Consider rewording to something like: “Server-side applications need to be aware that”
	- “circumvent semantics of this header"
	- Change to: “circumvent the semantics of this header”.
	- “MUST be limited for providing some non-fundamental”
	- Change to: “MUST be limited to providing some non-fundamental”
	- “Server-side application MUST NOT rely”
	- Change to: “Server-side applications MUST NOT rely”
	- “the field MUST be sent in clear using plain RFC 7235 syntax”
	- Change to: “the field MUST be sent in the clear using plain RFC 7235 syntax”
	- “Such parameter MUST have charset value of”
	- Change to: “Such a parameter MUST have a charset value of"
	- “The same parameter must MUST NOT be sent twice or more, those in both plain- and extended-syntax.
	- Change to: “The same parameter MUST NOT use sent more than once, for both parameters in plain- and extended-syntax.”
	- “with value “Renee or France””
	- Change to: “with value “Renee of France””
	- “specifies the server’s preferences over user interface behavior”
	- Change to: “specifies the server’s preferences for user interface behavior”
	- “included in any kind of responses”
	- Change to: “included in any kind of response"
	- “users refusing authentication request"
	- Change to: “users refusing the authentication request”
	- “expected to ask the user a password”
	- Change to: “expected to ask the user for a password”
	- “then provide users opportunities to perform authentication"
	- Change to: “then provide users the opportunity to perform authentication”
	- “default behaviour for the clients is implementation-dependant”
	- Change to: “default behaviour for clients is implementation-dependant”
	- “response for authentication-initializing response”
	- Change to: “response for an authentication-initializing response”
	- “although NOT RECOMMENDED”
	- Change to: “although this is NOT RECOMMENDED”
	- This chunk appears in more than one location in section 4: change it throughout the section.
	- “The clients MUST ignore this parameter, when a response"
	- Change to: “Clients MUST ignore this parameter when a response”
	- This chunk appears in more than one location in section 4: change it throughout the section.
	- “The clients SHOULD ignore this parameter”
	- Change to: “Clients SHOULD ignore this parameter”
	- This chunk appears in more than one location in section 4: change it throughout the section.
	- “it specifies that new authentication attempt is not to be performed on this location for better user experience”
	- Change to: “it specifies that new authentication attempts are not to be performed on this location in order to improve the user experience”
	- “a (Web content’s level) explicit interaction of users is desired before authentications”
	- Change to: “an explicit user interaction with the web content is desired before authentication”
	- “instead of giving user an opportunity to start”
	- Change to: “instead of giving the user an opportunity to start”
	- “this parameter MUST ignored”
	- Change to: “this parameter MUST be ignored”
	- “be used as any security measures"
	- Change to: “be used as a security measure”
	- “the user explicitly request a logout"
	- Change to: “the user explicitly requests a logout”
	- “the user requests to terminate an authentication period"
	- Change to: “the user requests termination of an authentication period"
	- This chunk appears in more than one location in section 4.5: change it throughout the section.
	- “authentication credentials and states”
	- Change to: “authentication credentials and state"
	- “has been passed from the time received"
	- Change to: “has passed since the time this header was received”
	- “the long-term memories for the passwords”
	- Change to: “the long-term memories for passwords and password-related details”
	- “scheme to be used has syntax limitation on allowed user names"
	- Change to: “scheme to be used has a syntax limitation on allowed user names”
	- “Client SHOULD ignore any values which do not conform"
	- Change to: “Clients SHOULD ignore any values which do not conform"
	- “but doing it will give bad user"
	- Change to: “but doing so will give bad user”
	- “requires specific style of text preparation"
	- Change to: “requires a specific style of text preparation"
	- 5. Usage examples (informative)
	- “If this assumption is not hold, texts below provides”
	- Change to: “If this assumption is not valid, the text below provides”
	- “Without explicit notices”
	- Change to: “When not explicitly specified”
	- “regardless of authentication statuses"
	- Change to: “regardless of the authentication status"
	- “most of web pages are available for guest (unauthenticated) users"
	- Change to: “most web pages are available for guest (unauthenticated) users”
	- “contents of these pages are customized"
	- Change to: “the content of these pages is customised”
	- “does not need a specific actions upon log-in”
	- Change to: “does not require specific actions upon log-in"
	- “available to authenticated users, Set up”
	- Change to: “available to authenticated users, set up”
	- This chunk appears in more than one place in Section 5: change it throughout the section.
	- “No specific pages for authentication is needed"
	- Change to: “No specific pages for authentication are needed”
	- “If the site will have one"
	- Change to: “If the site has one”
	- “If the site needs a specific actions upon log-out"
	- Change to: “If the site requires specific actions upon log-out”
	- “All shown in the Case 1 are to be applied"
	- Change to: “All settings in Case 1 are applied”
	- “In the de-authentication pages”
	- Change to: “In the de-authentication page”
	- “If there is any direct links to it"
	- Change to: “If there are any direct links to the de-authentication page”
	- “(some announces, user notices”
	- Change to: “(some announcements, user notices”
	- “to all pages available to guest"
	- Change to: “to all pages available to guests”
	- “for the specific log-in page, Set up"
	- Change to: “for the specific log-in page, set up”
	- “If the site will have one"
	- Change to: “If the site has one”
	- This chunk appears in more than one place in Section 5: change it throughout the section.
	- “If almost all pages in the target site requires authentication”
	- Change to: “If almost all pages in the target site require authentication"
	- “or there are no needs to support both"
	- Change to: “or if there is no need to support both"
	- “the setting will become somewhat simple”
	- Change to: “the settings become simpler”
	- “an example to realize such a site"
	- Change to: “an example for such a site”
	- “all pages available to authenticated"
	- Change to: “all pages available to authenticated users”
	- “In the current Web sites using Form-based authentications”
	- “In current web sites using form-based authentication"
	- “In some cases, there will be some ambiguous situations whether some functions are authorization management or session management”
	- Change to: “In some cases there will be ambiguity about whether some functions are for authorization management or for session management”
	- “for deciding which features to be used"
	- Change to: “for deciding which features to use”
	- “the main requirement for such feature"
	- Change to: “the main requirement for such a feature"
	- “protect users from their consoles and browsers hijacked”
	- Change to: “protect users from having their consoles and browsers hijacked”
	- “On the other hand, the requirements is to protect the server’s privilege”
	- Change to: “On the other hand, if the requirement is to protect the server’s privilege”
	- “support both HTTP-layer and Form-based authentications”
	- Change to: “support both HTTP-layer and Form-based authentication"
	- “should identify which authentication are used for the session"
	- Change to: “should identify which authentication has been used for the session”
	- “put the following things to the Web pages"
	- Change to: “add the following things to the web pages”
	- “if users are not authenticated, it may have a diversion for HTTP-level authentication"
	- “if users are not authenticated, the page may have a diversion for HTTP-level authentication”
	- “Users are identified for authorizations”
	- Change to: “Users are identified to authorization”
	- “both ones should match"
	- Change to: “both should match”
	- “Cookie tied to an HTTP authentication"
	- Change to: “Cookie tied to HTTP authentication”
	- 6. Methods to extend this protocol
	- “The extension-tokens MUST be with format"
	- Change to: “Any extension-tokens MUST use the format”
	- 8. Security Considerations
	- “Server application implementer SHOULD"
	- “The server application implementer SHOULD”
	- “protect server-side resources, such features MUST”
	- Change to: “protect server-side resources, this protection MUST”
	- “Server-side applications MUST be implemented always considering that"
	- Change to: “Server-side applications MUST always consider that”
	- A note: how will this normative language ever be enforced? May be worth changing this to something non-normative.
	- “Especially, it SHOULD NOT be used"
	- Change to: “Most importantly, the “username” parameter SHOULD NOT be used”
	- “in any case where the valid user names are configured by its users”
	- Change to: “in any case where the valid user names are configured by users”
	- Appendix A
	- “This section provides cross-reference table about applicability of each features provided in this specification for each kinds of responses described in Section 2.1”
	- Change to: “This section provides a cross-reference table showing the applicability of the features provided in this specification to each kind of response described in Section 2.1”
	- Appendix B
	- “meaning of WWW-Authenticate headers"
	- Change to: “the meaning of WWW-Authenticate headers"