| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
Hello, Now I have a question about the BY qualifiers. In all examples in MCC examples directory these qualifiers are declared as supported, so they will be accepted by the validation routines. Other than that nothing is done to them, i.e. they are simply ignored. If our module doesn't care about this qualifiers, i.e. we allow anyone to use the service provided by our module, what should we do: allow these qualifiers but ignore them, or reject them? Thank you for your answers. Gene
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3849.1 | Probably should reject the BY qualifiers | TOOK::STRUTT | Management - the one word oxymoron | Fri Oct 09 1992 13:08 | 16 |
Assuming you are developing an AM, I'd suggest you should reject them
unless you have any way of ascribing meaning to the qualifiers -
but I'd be interested in opposing views. If you are developing an FM
that is generic (ie. applies to multiple classes) then you should pass
them through unmodified. If you are developing an FM for a specific
class of object, then the answer is the same as for AMs.
The purpose of the BY qualifiers is to provide a means to assist in
access control, eg. with the specification of passwords, etc.
If you are developing an AM, then you presumably know whether or not
the thing you are managing (or the protocol you are implementing)
supports access controls or not - and if so, how. If you are capable
of supporting such access controls, by all means permit the appropriate
BY qualifiers. If not, then you should reject them, so the user is
aware that they have no meaning in the context of your entities.
| |||||