W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: #271: use of "may" and "should"

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 03 Jul 2012 19:38:30 +0200
Message-ID: <4FF32E16.1040806@gmx.de>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2012-06-25 00:26, Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:
>> P1, 8.2:
>>
>>     HTTP log information is confidential in nature; its handling is often
>>     constrained by laws and regulations.  Log information needs to be
>>     securely stored and appropriate guidelines followed for its analysis.
>>     Anonymization of personal information within individual entries
>>     helps, but is generally not sufficient to prevent real log traces
>>     from being re-identified based on correlation with other access
>>     characteristics.  As such, access traces that are keyed to a specific
>>     client should not be published even if the key is pseudonymous.
>>
>> "should not" -> "SHOULD NOT"
>
> It seems inconsistent to me make that a SHOULD NOT while keeping the
> "needs to be".

If we elevate "needs to be securely stored" to "SHOULD be securely 
stored" we make many HTTP servers non-compliant, right?

>>     To minimize the risk of theft or accidental publication, log
>>     information should be purged of personally identifiable information,
>>     including user identifiers, IP addresses, and user-provided query
>>     parameters, as soon as that information is no longer necessary to
>>     support operational needs for security, auditing, or fraud control.
>>
>> "should" -> "SHOULD
>
> I think this would have to require minimizing this risk first, other-
> wise there is no requirement if you decide against minimizing it.

Not convinced; what's wrong with saying something like

  "To minimize ... , log information SHOULD be purged of..."?

Best regards, Julian
Received on Tuesday, 3 July 2012 17:38:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2012 17:39:03 GMT