[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Capabilites and Sub-capabilities -- was RE: Proposal: Capabilitie s Attribute
See my subsequent emails.
We already have these examples out there that require to know more then just
capabilities but rather finer details. I don't think we are adding
For me what maybe unneccessary complexity would be using two bits to code:
Not supported, Supported, and required. And that is because I didn't run
into cases but I suppose CUI is one where you could use Supported and
> -----Original Message-----
> From: Nelson, David [mailto:email@example.com]
> Sent: Tuesday, January 18, 2005 2:09 PM
> To: Avi Lior; Barney Wolff; firstname.lastname@example.org
> Subject: RE: Proposal: Capabilities Attribute
> Avi Lior writes...
> > Just to be clear it's not a bit per attribute but rater a
> bit (or two)
> > subcapabilites. The authors of a capability will determine
> which are
> > subcapabilities of their feature. Obviously we can do this for
> > capabilities.
> I, too, question the need for, and desirability of,
> "sub-capabilities". Let's not make this any more complicated
> than necessary. I will define "necessary" for the purposes
> of this memo as a higher burden of proof than the fact that
> authors of various drafts have *claimed* that it is
> "necessary". As the number of possible attribute support
> states increases, the likelihood of convergence, correct
> implementation and global interoperability decreases. Let's KISS.
> -- Dave
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.