Conference azur::mcc

    RE:.0
    
    This is a sticky point.  According to the SRM there are NO valid
    relational operations for a Fullname datatype.  THIS INCLUDE EQUALITY
    (see page 231).  As compared to Simplename, which does support checking
    for equality.  I believe we have decided that this is really a bug
    (both in the source code, and in the SRM), and plan to fix it for V1.2. 
    (In fact, the SRM says that Wildcarding IS supported, but equality
    ISN'T !?!?)  To make matters more confusing, this appeared to be
    working in V1.0.  Sorry about that.
    
    -Matt.

Thanks Matt for your quick reply,

Should this be submitted as a QAR or do I wait for further 
investigation/decision ? 

Phil

RE: .0 and .2

There is a QAR (#465) on a related problem in MCC_AES_MATCH().

As of today, the new MCC_AES_MATCH() routine (for V1.2) supports the matching 
of Partial instance wildcards of MCC_K_DT_FULL_NAME data type. 
The restriction is that the wildcard ("*" or "?") has to be the LAST character
of the fullname.

For example, .repository.memb* matches with .repository.member_2,
	     .memb* matches with .repository.member_2,
	     .repository.member_* matches with .repository.member_2,
	     .repository.member_? matches with .repository.member_2,
	But, .repository.*_2 does not match with .repository.member_2,
	     .repository.mem*_2 does not match with .repository.member_2.

If you absolutely need to have the support for partial wildcards at any place,
we could support the feature.

William

re .3

Thanks Bill,

Since partial instance wildcard for MCC_K_DT_SIMPLE_NAME supports wildcard at 
any place, it would be inconsistent for MCC_K_DT_FULL_NAME to only support last
character wildcards.

Phil


NOTE: By the way the FCL PM does not seem to support the "?" wildcard, will
it in V1.2 ?

FCL support of fullname and simplename is setup as follows.

	pick up the next token (space or comma delimiter) form the command line
	then send it to the mcc_dns routines for conversion....

I will see if anyone can tell us about support for the ? character. The reason
I point this out is that you should find that if you tried using the ?
with the DNS routines in MCC my guess is you will see the same problem.

I will check to make sure that the parser itself is not barfing on
the "?" imbedded in a string when tokenizing.

It isn't that difficult to do full fullname wildcard matching (as defined in
the  DNS  architecture).   I don't see any point in implementing a hack that
doesn't  save  that  much  effort.   If  we  can do it in our bounded router
systems you lot can do it in MCC!

If you can't get a suitable routine from the DNS group talk to me -- you can
have our BLISS routine.

Graham

    
    Re: .4 and .6
    
    MCC_AES_MATCH() routine has been fixed to match the Partial instance
    wildcard ("*", or "?") for MCC_K_DT_FULL_NAME data type.
    
    Now, the wildcard(s) can be placed in any where in the name.
    
    The changes will be available in V1.2.
    
    Thanks for your comment.
    
    William

Re: .7.   Thanks.   One  question  of  clarification:  you did implement the
wildcarding  as  described in the DNS architecture, didn't you, not just "*"
and "?" ?

For example,  ABC.DEF.GHI  is matched by ABC..., ABC.*F*.*, ABC.*..., ABC...*,
ABC...GHI etc. but not by ABC.DE*HI

Graham

    RE: .8
    
    The wildcards that I implemented do NOT include the Ellipsis ("...").
    The MCC SRM does not mention (I think) the Ellipsis as wildcard characters.
    
    The DNS Document says the Ellipsis is used ONLY to match names in access
    control sets.
    
    The algorithm that I used is as follows:
    	- convert the two fullnames specified in AESs into strings
    	- perform wildcard string matching (wildcards characters are
    	  any number and combination of "*" and "?").
    
    	NOTE: The dots (".") in the strings do not have special meanings.
    	      A dot is treated as a single normal character.
    
    For example,  ABC.DEF.GHI  is matched by ABC*, ABC.*F*.*, ABC*F*,
    ABC.*HI, ABC.*.?HI, *C.*, AB?.D*, etc.
    
                                                  
    William

Thanks William.

I believe  that  MCC  must match DNS-defined datatypes in the way defined in
the  DNS  architecture.   Just as if I defined the FOOBAR type with matching
rules  and  MCC  implemented it I would expect MCC to implement the matching
rules as well.  If the SRM says otherwise, it is wrong and needs fixing.

Otherwise, the following commands will give different results:

SHOW SOME-ENTITY-WITH-FULLNAME-IDENTIFIER *... ALL CHAR

SHOW SOME-ENTITY-WITH-FULLNAME-IDENTIFIER * ALL CHAR WITH NAME=*...

The first  passes  the  wildcard  to  the  entity  (via  the AM) which will,
presumably,  implement  the  DNS rules correctly (it certainly will if it is
our  implementation).   The second passes "Known" to the entity and does the
filter comparison in MCC, incorrectly.

If the  DNS  architecture  limits  ellipsis  to  access control then I could
understand  you  not  implementing  that.   However, I wouldn't recommend it
because  when I close this notesfile I am going over to the DNS architecture
one  to  get  that bug fixed (we have managable entities which use fullnames
which require ellipsis support to be usable)!

You must  implement the simplename bound correctly (so ABC* does not match
ABC.DEF).

I repeat  the  offer  in  an  earlier  note  to send you our (internal form)
fullname  comparison routine.  It isn't directly usable because it makes use
of  others  of  our  routines  to  match simplenames but the logic should be
usable.  It really isn't that hard to do it right!

Graham

I have  checked in the DNS architecture notesfile (note 246 in DNS_ARCH) and
Dave  Oran  says  that  there  is no architectural restriction that ellipsis
matching  is restricted to access control.  The only restriction is that DNS
itself  only  uses  ellipsis  matching  for  access  control:  there  are no
constraints on other users of the datatype.

Please confirm that this has been QAR'd.

Thanks,
Graham