Conference virke::mrmemo

    Some of our customers like DDS validation but don't like complex
    addressing in MEMO. As soon as DDS validation is enabled for MR in both
    directions addresses could be translated to DGN.DEN instead of 
    DGN.user..mailbox..node. There should be a configuration parameter to
    have the choice. Using only the DGN.DEN addresses could also easyer 
    solve the problem mentioned in #16 because each TS user has a unique DEN. 
    
    Regards,
    
    Rainer

    I'D say :
    
    - DDIF support for outgoing stuff.
    - Solve the X400 addressing stuff.
    - SNA translation table that will fallback our DMCS to normal 
      EBCDIC (i.e. NO spaces instead of accentuated characters, NO 
      replacement EBCDIC whatever instead of accentuated characters,
      JUST make it so that � -> e, � -> ss or s, � -> u etc.
    
    				Marc VH.
    
    

    
    MRMEMO V2.0 problems fixed?
    
    TOP
    
    1) ... additional left margin
       If you send/add a document form A1 to MEMO you get 12 Blanks
       as additional left margin;
       If your page format is 63 signs per row the left margin is zero;
       
       The document looks like:
    
       !            ABCDEFG..............    !
       !            12345678910111213 ... 36 !
       !37383940414243......                 !                           
    
    
    2) ... more than 40KB
       If you send a document with more than 40KB (A1 to MEMO) then
       a errormessage is sent to the operator !!! not to the sender !!!;
       Is it possible to split documents with more than 40KB automatically?
        
    
    
    regards from eva
    

    
    I would like to add another good reason for implementing the
    suggestions in .1
    
    I just spoke to a Verimation rep and he told me that a sender address
    of DGN.user..mailbox..node cannot be relayed through MEMO to, for example
    SNADS, whereas a DGN.DEN address which is fetched from DDS, incoming and
    outgoing would serve that purpose very well. On the other hand we want
    our customers to purchase MRS...
    
    Anyway, keep the suggestions coming, we have had very useful input so
    far, both on and off line. Also, feel free to comment or qualify other
    people's requirements.
    
    Stefan

I'd like to strengthen .1

Our customer only uses ALL-IN-1 and MEMO. They don't see any need for turning
on the complex addressing feature within MEMO just in order to be able to reply
to any mail sent from ALL-IN-1. Currently (feature still off) they have to
create a completely new mail message! Annoying...

Well, I see the light...

Thanx for listening, and best regards
-mr

	Take it away boys..... :


	1	DGN.freeform_name as address option in MEMO From-field

		In line with Rainers request for the FROM address in MEMO
		being shown as DGN.DEN, the possibility of showing it as
		DGN.freeform_name should also be selectable.

		This is important to enhance the operationla interface
		for people who use free-form addressing.

	2	Selection of non-unique freeform name

		In case several users have the same freeform name,
		the selection of which one is intended should be done
		using additional tags. Example :

		TO : VAX.Stefan__Persson (non-unique receiver, should be )
		TO : VAX.Stefan__persson..un=swas

		Use of both X.400 and other attributes should be supported.

	3	Interoperational tests with other MR gateways

		Interoperability should be verified with as many MAILbus
		gateway products as possible : MR/Telex, MR/Fax, Ultrix
		Mail Connection etc. New MAILbus user agents should also 
		be tested (PC/All-In-1, DECwindows All-In-1 etc). The user
		manual should include chapters on the use of the MEMO
		gateway in all the above cases.

		This way we avoid the problems encountered in the X.400
		case.


	4	Improved management

		a	Indication of which addresses are discarded during 
			verification

			If DDS sender/receiver verification is enabled and
			a DDS match is not found, the reverse look-up used
			should be written into the logfile.

		b	Timestamp for last message (in SHOW display)

		c	Status of last message 

			In the SHOW display, indicate action on last message :
			FORWARDED or NON-DELIVERY, if a distribution list,
			a synopsis (n users FORW, m NON-DEL)

	4	Support for DDIF body-part

		The DDIF bodypart produced by the new DECwindows-based UAs
		should be accepted. Data-types included in the DDIF format
		that cannot be translated into a textual format understood
		by MEMO should be flaggged, example :

		__________________________________________________________
		Message contains data that could not be translated :
		FAX-image
		__________________________________________________________

		Another (simpler) possibility is to run the DDIF bodypart
		thru the RMS converter, which will translate the message to
		text only. This is not as good, as there is no info on data
		lost due to conversion.

	5	A better line-truncation algorithm

		When text is tranferred in the direction MR->MEMO, lines
		should be truncated on word boundaries. This could be 
		complemented by an additional truncation parameter that would
		indicate how many letters from the end of the line a forced
		(regardsless of word boundaries) truncation will be used.


	6	Finnish end-user messages

		OK, I'll do the translation if required!

	
	7	Correction of some error messages in MEMO :

		a	Messages to VAXmail remain in state (when expanded)
			X - delivery not confirmed. Could this be removed?

		b 	Errors are reported in three different ways :
			1/ Message status : ****ERROR****
			2/ Messages from MEMO
			3/ Messages from Message Router

			Could the last two be eliminated?? They seem to cause
			confusion in the MEMO users??? 


	8	Different sizes of messages supported inbound and outbound

		In some cases a message can be sent MEMO->MR, but sending the
		other way causes message to be flagged as too big?


	If you still feel underworked, just call back and we'll think up some 
	more!

	H�kan

	A few more wishes :

	I just remembered one thing that I talked to you guys about with
	regards to X.400 and the use of DDS :

	For users with DDS set up, normally a second MEMO gateway would need
	to be set up for accessing (non-DDS defined) X.400 users. Using
	a setup like this, we would need a double MHSORADDRESS for each user :

	1/ MHSMAILBOX = MEMO (with DDS set, freeform names in use)
	2/ MHSMAILBOX = MEMO2 (without DDS, to be able to do reverse look up
			       in MRX to sender validation)

	Now, any message coming back from the X.400 world would be returned
	by way of MEMO (with DDS set), because MEMO requires that this entry 
	be first and MRX uses the first entry for returning X.400 messages.

	Now, this would mean that any returning X.400 message cannot be answered 
	directly, as the message would not pass thru the MEMO server with DDS
	enabled. 

	This could be circumwented in at least one way : If we could set up
	two DDS entries, one of which would contain the X.400 attributes
	and the other the SNL/SNU attributes, X.400 messaging would use the
	DDS entry with the X.400 attributes (and MEMO2 as server) and MR-MEMO
	messages would use the other. Now, with freeform addressing this is
	not possible today, as both entries have the same freeform name and
	a message using the free form name would not be delivered due to 
	nonunique address. If MEMO checked for the presence of the SNL/SNU 
	attributes before discarding a message as being addressed to a non-
	unique receiver, this setup would work for free-form addressing also.

	Ofcourse, a solution that would not require two DDS-entries would be
	much preferred, but that one you'd have to figure out for yourself?

	Second additional suggestion :

	Also, a customer proposed the possibility of using "extended" free form
	addressing to easily resolve the problems of several (actually distinct)
	persons having the same freeform name. This would mean including one
	additional field as an extended name attribute :

	Stefan__Persson__swas

	where the additional attribute could be selectable, in this case for
	instance ORGU (other possibilities are LOCATION, ORGN etc). A parameter
	in the server definitions would indicate which attribute would be
	used (for all senders/receivers). The usage would be as follows :
	
	If an address is received with three fields, take the last to be the
	additional field (YES, I realize that whis would not be very nice in
	Holland, but there they could elect not to use this), the address being
	equivalent to : givenname__surname..UNIT=SWAS. If only two fields are
	present, treat as regular freeform name.

	For sender addresses sent into MEMO, always add the last attribute (as
	in 17.6, wish 1) to give a sender address consisting of the three
	elements.

	Let's see if I can dream up some more...

	H�kan

	As we have not yet passed that magic date....

	Requirement n+1 : 

	If, for some reason, the connection to MEMO fails, a terrible amount
	of logging data is produced, especially if the system happens to be
	running over a week-end etc.

	To avoid this situation, it would be nice (and here now comes the
	requirement) if the reconnect interval would grow longer for each
	connection failure up to a maximum time of about 1 hour. Like this
	30 sec, 1 minute, 2 minutes, 4 minutes, 8 minutes.... You get the
	idea? This way the amount of logging info would stay within reasonable
	bounds. Now (especially as customers tend to run the system on small
	systems like uVAX II's) we (MR/MEMO) sometimes fill up the whole 
	system disk...!

	And as I'm at it, the cutoff limit for shutting a server down in case
	of repeated errors could be settable - or if not settable then it could
	be lowered to say 10 or 5 or something.....

	H�kan

	PS : Only way to stop me is to take Finland off the Easynet..... 

    
    >>	PS : Only way to stop me is to take Finland off the Easynet..... 

    We have no intention of trying to stop anybody. Please keep the
    requirements coming. Keep in mind that we don't have the elevated minds
    of Corporate Marketing to trust in these matters, since this is not a
    worldwide Product.
    
    Stefan

    Some more ideas...
    
    1) The MEMO gateway management and configuration should adhere more
       to the MAILBUS standards. Parameters, like batch queue, starting
       time, reconnect interval, number of sending attempts etc. should
       be configurable in the MB$CONFIG.          
       
    2) If a message cannot be delivered to MEMO there should be a retry
       counter that makes it possible to discard the message. At our
       customer that happens 3 to 4 times a day and most of the time
        the gateway just finnishes to work, stack dumps and huge log
       files are the results.
    
    3) Failure messages should be sent to the users in all cases. It
       is no use at all if only there is an entry in the log file. The
       messaging service must be reliable no matter where the message
       comes from or goes to. If I cannot tell my customer with a fairly
       good feeling that no message just disappears, that he is always
       informed about delivery failures etc., then he will loose confidence in
       the product and not use it any more.                   
    
    Regards 
    Ute

    
    Re .10
    
    > 2) If a message cannot be delivered to MEMO there should be a retry
    >   counter that makes it possible to discard the message. At our
    >   customer that happens 3 to 4 times a day and most of the time
    >    the gateway just finnishes to work, stack dumps and huge log
    >   files are the results.
    >
    > 3) Failure messages should be sent to the users in all cases. It
    >   is no use at all if only there is an entry in the log file. The
    >   messaging service must be reliable no matter where the message
    >   comes from or goes to. If I cannot tell my customer with a fairly
    >   good feeling that no message just disappears, that he is always
    >   informed about delivery failures etc., then he will loose confidence in
    >   the product and not use it any more.                   
    
    
    My advice to you is to watch out for V2.0A. It'll probably take care of
    most of your problems. Nevertheless the retry counter scheme is a fair
    requirement.
    
    Stefan

�       Parameters, like batch queue, starting
�       time, reconnect interval, number of sending attempts etc. should
�       be configurable in the MB$CONFIG.          
    
    You must be joking !
    I wouldn't do that to my worst enemy.
    
    The configuration of MRMEMO is much easier and much more flexible than
    the MB$CONFIG silly procedures. Please, let's keep it that way !
    
    It is rather the MB$CONFIG stuff that should be changed to something
    like what MRMMAN or MRT$CONTROL (MR-TELEX) provide.
    
    		Marc VH.
    
           
    

    
    Re .12
    
    Thanks for the support Marc, we think so too :-)
    
    However I'm sure this is a real requirement from a real customer, and a
    big one at that. Nevertheless I can almost promise that we will *not*
    provide support for MB$CONFIG. 
    
    We could in theory do it by using calls to MRMMAN from the various
    MB$CONFIG command procedures (obviously, we will never abandon MRMMAN).
    But the MB$CONFIG concept doesn't fit very well into the MRMEMO
    architecture, because MB$CONFIG more or less assumes that you're
    configuring ONE gateway only, whereas MRMMAN in effect lets you define
    and handle 1-9 servers (gateways) independent of each other.

	Re : .12.

	I also agree, MB$CONFIG is like the punishment for all our
	forefathers sins taken together....

	MRMMAN is the best thing that happened to MAILbus since they invented
	binary numbers.... 

	H�kan

    
    could you improve the performance  ?
    
    I try to send a lot of  message (1000 char) from to mr or mr TO memo 
    
    the microvax 3600 have idle time and i can receive or send only
     6 message / minute 
    
    have you any idea ?
    
    thanks

	I've found one more detail to add with regards to MEMO<->X.400
	interoperations. This basically fits in with my earlier notes,
	so I add it even now (past the deadline).

	If automatic delivery recipts are requested from X.400 recipients
	the delivery notification is passed to the MEMO gateway and onto
	MEMO but it does not affect the status of the X.400 message sent.

	What should heppen is that the message status should change from
	EXCEPTION , X - delivery not confirmed 
	to something less alarming....

	Still on the Easynet.. H�kan

I just keep adding these things, it seems. Is anybody still registering?

Now I'm onto the subject of distribution lists and what they should contain.

This first entry is a distribution list from a message sent by MRX to MRX to
MEMO. Four comments :

	1/ The MEMO user id, in an X.400 adressed message, could it be skipped?

	2/ The route elements should not be included in a receipient address
	   for X.400 addressed messages.

	3/ Surname and givenname could be assembled into one "freeform type"
	   name (no attribute tag) and put first in the message.

	4/ Use the ADMD and PRMD form of domain names as these in the future
	   wil be the only one supported by MRX et al.

Now :

Distribution List:
  VTKK.V1KHP..ROUTE=ELVI..ROUTE=VTKES4..COUNTRY=FI..AMDNAME=MAILNET..PRD
NAME=VTKK..SURNAME=PARVIAINEN..GIVENNAME=KIRSI

Suggest : KIRSI_PARVIAINEN..COUNTRY=FI..ADMDNAME=MAILNET..PRMDNAME=VTKK



Next is a message received from a non-MRX MTA and handed onto MEMO. Now, here
for some reason, the receipient is not on the distribution list. Also, the
distribition contains both gi/su and freeform attribites. As per the previous
point, ditch both and put "freeform type" name at had of distribution!


Received: 1989-12-12 10:50 by MRMEMO Server 1 on DECnet node VTKES4
Ident:    3132323730

sanoman sis{lt| oli t{ss{ kohdalla n. 10 rivi{

Raimo Vuonnala
Nokia Data
Projektip{{llikk|, X.400 ohjelmistokehitys toimistoj{rjestelmiin

Distribution List:
  JARMO_AHLSTROM..ROUTE=3=IVO..ROUTE=2=MAILNET..ROUTE=1=FI..ROUTE=PTL..R
OUTE=VTKES4..COUNTRY=FI..AMDNAME=MAILNET..PRDNAME=IVO..SURNAME=AHLSTROM.
.GIVENNAME=JARMO..FREEFORM=AHLSTROM_JARMO


As for MAILbus-internal ditribution lists, there also I think that ROUTE ele-
ments don't add to clarity. They might be wanted in some case for debugging,
but then there should be some other place to put them, like in the management
interface (logs and SHOW/CONT as I have allready suggested).

Can I still enter?

	H�kan

	As somebody seems to be reading this Notes conf.. here's a "cudo".

	Could you change the installation so that instead of a defining
	just a device for the root of the <MRMEMO> directory, you could
	instead give a device and a directory?

	Not big deal, heh?

	The longer you live, the more you learn....

	How about opening the MRMEMO log and accounting files so that you
	allow concurrent readers..?

	At least in civilized programming languages this is a simple matter
	of adding a "SHARE" or something parameter to the file OPEN.

	This way you cuold look at logs etc. without having to start and stop
	the server! I cannot really see any problem with allowing concurrent
	read.

	Regs, H�kan