[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ;binary and *, take 2.
Kurt
I much prefer your new suggestions below. It deals with most, if not
all, of my previous concerns.
David
"Kurt D. Zeilenga" wrote:
>
> I was recently reviewing RFC 2252 and came across this statement:
> Clients which request that all attributes be returned
> from entries MUST be prepared to receive values in
> binary (e.g. userCertificate;binary), and SHOULD NOT
> simply display binary or unrecognized values to users.
>
> (This statement needs to be moved to the [Protocol] section
> detailing the binary transfer option.)
>
> Given this MUST, I'd like to revise my previous suggestion:
>
> There needs to a clarification regarding transfer encoding
> to use when the attribute was not requested by attribute
> description. E.g., by * or an empty attribute list.
>
> I suggest that if "foo" is to returned (when not requested
> by attribute description), that the server is to use the
> "native" transfer encoding if the server supports such for
> that attribute. Otherwise, if the server is able to generate
> ;binary for the attribute, the server is to return the
> attribute using ;binary. Otherwise, the attribute is
> not to be returned.
>
> The last statement is required as clients are not required
> to treat attribute descriptions containing unrecognized
> options as unrecognized. That is, they may simply treat
> the attribute description with one or more unrecognized
> options as a (indirect) subtype of the attribute description
> with the same attribute type and no options.
>
> Additionally, the TS should say that clients MUST NOT
> expect any particular transfer encoding of attributes
> which are not requested by attribute description. Where
> a client desires a particular transfer encoding, including
> the native encoding, the client SHOULD request the
> attribute using an attribute description indicating
> the desired transfer encoding.
>
> Kurt
--
*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351 Fax +44 161 745 8169
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@salford.ac.uk
Home Page: http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500: http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5
*****************************************************************
begin:vcard
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:d.w.chadwick@salford.ac.uk
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard