Subject: [Ietf-not43] extended attributes for privacy crap

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Aug 25 23:57:34 2003

I'm trying to get a handle on what exactly we're looking for with the
extended privacy data.

The most liberal reading of section 3.2.8 in req-06 essentially says that
versions of the attributes should exist that have negative flags for
privacy and access. These special attributes should be returned (instead
of null responses) if the user is not authorized to view the actual data.

Meanwhile, the new requirements in section 3.1.14 essentially says that if
the user is authorized to view the underlying data, then versions of the
attribute may be returned that have positive flags which indicate that the
data is sensitive and shouldn't be shared.

So that means we essentially have three classes of attribute values:

  attribute: data1  (here's the public data)
  attribute: <null> (maybe there's data here, maybe not)
  attribute: data2  (here's the private data)

We also have the null set of problems:

  attribute: <null>0 (was left empty and everybody knows it)
  attribute: <null>1 (you're not allowed to find out it's really empty)
  attribute: <null>2 (you're allowed to find out, but don't tell anybody)

Is that right?

I'm thinking I'm going to deal with this by defining attribute
descriptions (similar to the language tags), and possibly make clients
use a control during the query.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/