[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "'janusz sienkiewicz'" <janusz@libertyrms.info>
Cc: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Mon, 21 Oct 2002 11:00:44 -0400
Sender: owner-ietf-provreg@cafax.se
Subject: RE: "private" Element Attribute

> -----Original Message-----
> From: janusz sienkiewicz [mailto:janusz@libertyrms.info]
> Sent: Monday, October 21, 2002 10:59 AM
> To: Hollenbeck, Scott
> Cc: 'ietf-provreg@cafax.se'
> Subject: Re: "private" Element Attribute
> 
> 
> Wouldn't it be more convenient to redefine private attribute 
> as enumeration
> versus boolean? For example:
> 
> <contact:email private="true">jdoe@example.com</contact:email>
> 
> could be replaced by:
> 
> <contact:email access=enumValue>jdoe@example.com</contact:email>
> 
> Where enumValue could be: private, public, noWhois, etc.
> 
> Among other petential benefits this approach could eliminate 
> the inconvenience
> of using <extension>.

There's no real benefit to an enumeration because to add new elements to the
enumeration we'd have to rev the protocol -- we can't extend enumerations.
using the extension mechanism means we can add new elements, policies, etc.
without having to produce a new version of the protocol.

Plus, we'd have to agree on all of the possible enumeration elements and
then we'd still be left with no room for extension without revising the
protocol.  We tried talking through identification of policy elements some
time ago when we talked about privacy requirements, and we got nowhere.  The
results of that discussion is in the archives somewhere.

-Scott-

Home | Date list | Subject list