| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 681.1 | | MAKREL::COOLEY | Megan and Michelle's Daddy | Mon Jan 27 1997 11:48 | 17 |
| Hi,
Re: 1. email aux class attributes
I take it this for allowing the email attributes to work with motif
dxim? The labels for email class would have to go in email.sc, though,
since dua.sc is controlled by X.500 engineering.
Have you already made some changes? I'll be happy to include them in the
next version.
Re: 2. x_put, x_get
I'll have to get back to you on these questions. Can you be more
specific on the x_put problem in the meantime.
Warren
|
| 681.2 | back to you | CHEFS::SMITHMR | Making it Easier | Mon Jan 27 1997 13:14 | 35 |
|
>>>
I take it this for allowing the email attributes to work with motif
dxim? The labels for email class would have to go in email.sc, though,
since dua.sc is controlled by X.500 engineering.
Have you already made some changes? I'll be happy to include them in the
next version.
>>>
Yep this is for DXIM Motif. Why do they need to go in email.sc, I
thought they needed to go in dua.sc as this is what DXIM is looking at?
However no I wonder if DXIM looks at the compiled schema in which case
it doesn't really matter (although email.sc is logically correct) as all
.sc files are included for compilation. I haven't done this yet and look
to you as the definitive source for this ;-). Any chance you could knock
one together and I'll test/improve (if necessary).
>>>
Re: 2. x_put, x_get
I'll have to get back to you on these questions. Can you be more
specific on the x_put problem in the meantime.
>>>
The recipient address of X_PUT over about 80 characters causes problems.
It is possible that this is only true if it contains a dda, or maybe
specific to the dda's value. I can investigate but thought I should
check I had the latest version first. Be nice if these utilities
supported a -v swich which displayed their version (or some other
mechanism).
Mike.
|
| 681.3 | over | GOBUCS::COOLEY | Megan and Michelle's Daddy | Mon Feb 03 1997 18:29 | 23 |
| Mike,
Regarding email.sc:
To allow these attributes to be properly used with Motif Dxim, I'll
need to change emailInfo from an auxillary class to a structural class.
In the next XDSU release, I plan on putting together another variant of
email.sc which uses a structural class - then the user can decide,
which to use.
I will post the structural class variant when I get a chance. I'm not
sure, however, what effect changing an objectclass from an aux. to a
structural would have on your existing schema/dsa. I suspect you would
have to delete/reload everything that has any emailinfo attributes.
Regarding x_put:
You have the latest version, so if you can nail down your problem to
whether dda's are involved, that would be a big help. The idea to
start putting a version number on these is good....
Reagrds,
Warren
|
| 681.4 | Sounds Good | CHEFS::SMITHMR | Making it Easier | Thu Feb 13 1997 04:55 | 15 |
|
Hi,
This sounds very interesting. I don't understand why a structural class
is necessary except that you imply that DXIM would be able to work with
one.
Deleting and reloading everything is not a problem. All incoming
directories, MTS routing information and the DSA are all built from
master scripts. This protects customers from DIT corruption, changes in
product schemas etc.
thanks,
Mike.
|
| 681.5 | | GOBUCS::COOLEY | Megan and Michelle's Daddy | Thu Feb 13 1997 09:43 | 18 |
|
> This sounds very interesting. I don't understand why a structural class
> is necessary except that you imply that DXIM would be able to work with
> one.
From the latest X.500 (T3.1) Release Notes:
7 DXIM Motif Interface Restrictions
7.10 No Support for Auxiliary Object Classes
The DXIM Motif interface does not support auxiliary object
classes.
I believe one of the forms doesn't allow you to specify a aux. class.
This only prohibits you from modifying attributes, as far as I can tell.
Warren
|