Conference azur::mcc

Records are displayed with filed=value as the format, so you will get
the equals sign from the FCL at least. As for a new data type of the
base format 
	dtype :== <latin1string> "+" <latin1string>
you would have to submit an ECO proposing the new data type which would then
be voted on by the MRG membership. But be warned we are a long way down the
V1.2 planning cycle so new data types in the near future are not a likely
possibility.

jill

My suggestion (which you won't like :-)) is that you make no attempt to keep
the  user  visible  syntax  the same and go for a straightforward structure.
Something like:

	TYPE VMSIdentifierACE = 1 RECORD
		Identifier = 1 : SET OF SimpleName ;
		Options = 2 : SET OF ACEOption ;
		Access = 3 : SET OF ACEAccess ;
	END ;

	TYPE VMSIdentifierACL = 2 
		SEQUENCE OF VMSIdentifierACE ;

	TYPE ACEOption = 3
		( Default = 0,
		Protected = 1, etc);

	TYPE ACEAccess = 3
		( Read = 0,
		Write = 1, etc);

The ACE would look something like:

[Identifier = (Cobb, Dutko), Options = (), Access = (Read, Write, Control)]

You really  don't  want to use Latin1Strings because they require quotes and
because  they are case-sensitive.  We use SimpleNames for identifiers in our
ACLs in PSI Security.

Graham

Unfortunatelly, we can't just abandon all "arcane" syntaxes. This would intro-
duce confusion the order of which people haven't seen since we changed the sys-
tem directory structure in V4.0. Users of the TRM and DCL interfaces would be
confused beyond belief. 

Whereas your use of SimpleName may be valid for PSI access control, identifier 
values in VMS ACEs may contain characters outside the allowed character set for
SimpleName. 

For example, the ACE may contain: [VMS,*]. Unless the SRM is wrong, the "[", and
"]" are invalid for SimpleName. On the other hand, SimpleName allows for "?" and
"-" which are invalid in rights identifier strings.

-- Nestor

SimpleNames allow  *any*  characters -- the restrictions you describe are on
"easy"  simplenames:  ones  that  can  be entered without using quotes.  All
printable  characters  are  allowed in quoted simplenames (and non-printable
characters  are allowed in binary simplenames).  In order to enforce the VMS
rules  you will need to validate the simplenames.  You would have to do that
if you uses Latin1Strings as well but in that case you would also be forcing
your users to *always* use quotes.

My suggestion to change the syntax was based on the idea that it is unlikely
that you can get it to be *identical* (e.g.  the problem with not being able
to  leave out the Options field) so you may as well invent something that is
visibly different rather than confuse people with very small differences.

By the  way,  if  you did that I would suggest changing the DCL syntax to be
the  same  as  the  MCC  syntax  with  the old DCL syntax still accepted for
backwards compatability.

Graham

     VMS DCL users are already used to inconsistency in this area.  The SET
PROTECTION command's syntax for access is single letters (R, W, E and/or D) with
no punctuation in between, which doesn't match the syntax of the access part of
an ACE (even though the semantics are the same).  NEITHER the syntax of SET
PROTECTION nor the syntax of an ACE matches the normal syntax for a set of flags
or options in DCL, which is a set of comma delimited identifiers enclosed in
parentheses (gee, where have I seen that before :-).

     Seriously, I don't think DCL users will be too surprised.  And they'll have
enough NCL syntax to learn without learning random exceptions to NCL syntax.  I
considered posting a response in the same vein as Mr. Cobb's, but he's done it
more eloquently than I could've, so I'll merely second it (whether he wants me
to or not).  I think the conceptual clarity of using the native concepts in NCL
greatly outweighs any advantages of preserving VMS ACE syntax (especially when
one starts dealing with ACEs on multiple OSses somewhere down the line).

								curmudgeonly,

								    Robt. P.

I like Graham's definition too. It preserves the current ACL semantics, and 
reflects it in the syntax.

Mark