Conference iosg::all-in-1_v30

    1.  - Set by X400 Standards 
    2.  - Value Added on X.400
    3.  - Set by X400, not so easy in practice... 
    4. - I guess you want obsoleteing - again defined by X.400 standards.
    
    If these are correct interpretations, then I can assure you that they
    are all on our own wishlist. Which is not to say that they will be
    done, but that you're not alone in wanting them :-)
    
    Winton

    Winton,
    
    Well I just thought it was worth a try.  By the way ALL-IN-1 mail or
    DECmailwork (however it's spelt) has some of these features also
    UNIPLEX.
         
    Sunil

    Hi Winton,   
    
    >4. - I guess you want obsoleteing - again defined by X.400 standards
    
    I don't understand what you mean by "obsoleteing".  The scenario I am
    refering to is when a user sends a message and realises that it should
    not have been sent s/he can withdraw it.  The user can make
    modifications and resend it or delete it.  I have come across cases
    when a user wanted to unsend a message if you like and I have replaced
    the .WPL in OA$SHARcn with a dummy file and Gold got the VMS file in a
    temp document.
    
    Sunil

Hi,

There are a whole string of reasons why "unsending" mail is a no-no, both
practical and political.  I think it's been discussed in one of the notes
conferences before (cue GAP who can no doubt quote the exact note number from
memory :-).  This isn't something that's going to be implemented.

"Obsoleting" is where you send a second message, with a tag that says "this
message obsoletes message SPQR1".  Nice user agents then convert the reference
SPQR1 into a "real" message in your file cabinet, and tell you it's been
obsoleted.  Note the user agent shouldn't just delete the obsoleted message
without the user knowing, otherwise I could send you lots of "obsoleting"
messages and delete your whole file cabinet!

Scott

    re -.2 
    
    The problem is that mail would be 'inconsistently' treated - if the
    mail has gone off-node already- you can't catch it. If it hasn't the
    user may already have read it anyway - if it hasn't been processed,
    then there remains a possibility of doing so - if this is what you
    need, then use DEFER in order to put off DELIVERY until the last
    possible deadline for the information to be known.
    
    Otherwise you need obsoleting...
           
    If the reason is a sudden worry that you were incredibly rude to your
    manager and have threatened to resign, and had a change of mind, then I
    suggest that one looks before they leap so to speak - at best all we
    could provide is a 1 in 3  chance of 'stopping' the mail (off node,
    local read, - you can only stop local unread/remote unsent)
                                                               
                                                               
     Winton

And if you have a site full of really nervous customers. apt to regret sending 
messages, you can either suggest or force them to use DEFer instead of Send.

g

    G'day,
    
    I have been given good reasons for not having the unsend option they are
    acceptable.  I am glad we agree on the first 3 points.  It's good to
    know that the ALL-IN-1 product team keeps to international standards.
    
    Can someone just give a brief out line of the X400 protocol please. 
    Also X500 has been talked about what's the difference between the two ? 
    If this is going to take too much time please give me a pointer to some
    reading material.
         
    Sunil
    

    Hi Sunil,
       
     X.400 (and X.4nn) define the ISO standards for MESSAGE HANDLING
    Service.                                        
                                                    
    There's a bundle of protocols P2 (user to user) and P1 (UserAgent to
    UserAgent). Basically defines the format, down to the encoding of
    messages - the envelopes, headers and bodypart types). There are 3
    standards so far 84, 88 and 92 - each extra fields, protocols etc.
                                                    
    X.500 is the definition of the DIRECTORY Service - a bit like DDS, but 
    far more comprehensive, scalable and hierarchical - possibly a future
    repositry of ALL network information.

    
    There are different levels of compliance with the X.400 standards - the
    most basic one for X.400 is to be able  store all the attributes of an
    X.400 message without loss - something that ALL-IN-1 is unable to do
    currently - It can store the major fields - TO, CC etc , but not the
    more esoteric ones such as BCC for example. 
                                                
     DECmail Works is a X.400 compliant useragent - though it sends via 
    Message Router (unless you use the new MTA router).

   (Useragent is the application which give user control over messages,
    MTA = Message Transfer Agent- a network of which makes up the MHS
    Message Handling System - takes a message from one UA and delivers it
    to another)
    
     There are a fair number of internal documents on X.500, on X.400 I'm
    not so sure, but there a fair number of PUBLISHED guides to X.400.
           
    Ask your local library maybe. Try FORTY2::MAILBUS - do a directory
    there is a list of documentation available somewhere.,
                                                          
     Winton                                               

    Oh, and a last comment, 
    
    X.400 is based on O/R addressig - this stands for Originator/Recipient
    Addressing. This means that you just name the person by address, not by
    ROUTE - the simile is that of giving directions (left, right, along the
    road) VERSUS a postal address (Bloggs, 1 Sun Street, Sydney).
    
    X.400 MTAs will work out the routing of it, in conjunction with X.500.
                                                   
                                                   
    Winton

Sunil,

>> a brief out line of the X400 protocol

If you're interested, the X.400 (88) family of protocols are defined in a 600+
page book, ISBN 92-61-03721-6.  It's rather expesnive though, and not the most
readable book...

Scott

The X.500 conference on Forty2 contains pointers to all levels of 
documentation on our offering. You should be aware that X.500 is mandatory if 
you're using the new MAILbus 400 MTA.

(With any luck a '*' will appear above this note to direct you to said 
conference!)

grahame