Conference virke::mrmemo

	I just skimmed thru the doc and wanted to post my first impression :

	I LOVE IT....!

	H�kan

	Nice job, guys! My initial impression with the docs were right.

	I've read the docs and only have a few minor comments :

	1/ In presenting additional addressing attributes in either a
	   <meta-string> or <ensure uniqueness> you have elected to use
	   the numeric format. I think this is fairly user-hostile and would
	   suggest that you use string prefixes, truncated to say 2 or 3
	   characters.

	   Example : vax.john__smith..org=acme..co=se.

	   This change would make this feature essentially selfexplanatory 
	   to end-users. Also, in the future MEMO apparently will support
	   address strings longer than now, and ecenomy with characters
	   would not be such an issue as to require numerix tags.

	2/ Some of the minor wishes that I've added to your input note (17)
	   hopefully were so small that you did not bother to add them to
	   the spec?

	3/ I hope I understood correct that now you only need one MRMEMO
	   server to be able to both 

	   a/ send meesages to DDS-defined recipients
	   b/ send messages to ad-hoc, external users not in the DDS

	   if address-translation is enabled and receiver validation is not!
	   If this is so, all my major concerns have been addressed!


	We are now at a stage where I think improved functionality has priority
	over time-to-market, so I suggest that everything you've specified be
	included even if this takes a little more time than you've expected
	now.. FT etc training i April in Stockholm would be MUCH appriciated!

	H�kan

    H�kan,
    
    >	1/ In presenting additional addressing attributes in either a
    >	   <meta-string> or <ensure uniqueness> you have elected to use
    >	   the numeric format. I think this is fairly user-hostile and would
    >	   suggest that you use string prefixes, truncated to say 2 or 3
    >	   characters.
    >
    >	   Example : vax.john__smith..org=acme..co=se.
    >
    >	   This change would make this feature essentially selfexplanatory 
    >	   to end-users. Also, in the future MEMO apparently will support
    >	   address strings longer than now, and ecenomy with characters
    >	   would not be such an issue as to require numerix tags.

    Yes, we have elected the numeric format, to make it as short as
    possible.  I agree that this makes the address a little more user
    hostile than if we used string prefixes, but only marginally so. We
    don't expect users to find either format very readable! The major
    objective is to make the address REPLYable. As far as future MEMO
    functionality goes, I'll beleive it when I see it.
    
    
    >	2/ Some of the minor wishes that I've added to your input note (17)
    >	   hopefully were so small that you did not bother to add them to
    >	   the spec?

    Don't expect anything that's not in the spec. We have had lots of
    requirements, some of which we have just had to set a lower priority on.
    We are trying to please most of the people most of the time.
    
    
    >	3/ I hope I understood correct that now you only need one MRMEMO
    >	   server to be able to both 
    >
    >	   a/ send meesages to DDS-defined recipients
    >	   b/ send messages to ad-hoc, external users not in the DDS
    >
    >	   if address-translation is enabled and receiver validation is not!
    >	   If this is so, all my major concerns have been addressed!

    Yes.
    
    
    >	We are now at a stage where I think improved functionality has priority
    >	over time-to-market, so I suggest that everything you've specified be
    >	included even if this takes a little more time than you've expected
    >	now. 

    I don't agree for the very reason that's stated in the spec. We want to
    release a proper version with acceptable quality as soon as possible,
    to make version 2.0A redundant. 
    
    
    > FT etc training i April in Stockholm would be MUCH appriciated!
    
    FT training is not currently planned.
    
    	cheers,
    
    		Stefan

    
    
    H�kan, and the rest of you,
    
    Following further off-line requirements that we use string presentation
    tags instead of numeric, we have decided to make it (yes, you've
    guessed it!) configurable. Below is an extract of the modified product
    spec, which tells how. The full modified spec will be available later.
    
    
    OK?
    
    ############################################################################
    
    

          DEFINE/ADDRESS_TRANSLATION=FORMAT=<META-STRING>

          When a meta string format is specified, the MR
          sender's address is specified as a reflection of the
          format specified in the META-STRING. The META-STRING
          is an arbitrary address presentation format. The
          format is specified with tags and route delimiters,
          where tags are string representations of all supported
          addressing attributes, and route delimiter is the '@'
          character. The attribute values are fetched from the
          DDS attributes associated to the tag strings. The tag
          strings can be specified in their numeric format, or
          as unambigous strings. The exact specified format will
          be used when presenting the address.

          Example 1 (Full length string tags):

          MRMMAN> DEFINE/ADDRESS_TRANSLATION = FORMAT =

          "<SURNAME> @ <ORGANIZATION>"

          Example 2 (Shortened string tags):

          MRMMAN> DEFINE/ADDRESS_TRANSLATION = FORMAT =

          "<SUR> @ <ORGA>"

          Example 3 (Numeric tags):

          MRMMAN> DEFINE/ADDRESS_TRANSLATION = FORMAT =

          "<6> @ <5>"

          The example above shows three different ways of
          defining a meta string of Surname + Organization.

          Let's assume that we have performed a DDS lookup for
          the sender with the resulting DDS record containing
          surname "SMITH" and organization "ACME". The sender
          addresses will look thus:

          Example 1 (Full length string tags):

          => VAX.SURNAME=SMITH..ORGANIZATION=ACME

          Example 2 (Shortened string tags):

          => VAX.SUR=SMITH..ORGA=ACME

          Example 3 (Numeric tags):

          => VAX.6=SMITH..5=ACME
    

All the plans necessary for the development of the new version 2.1 of 
VAX MAILGATE for MEMO are now available at:

STKOFF::MRMEMO$PUBLIC:<V021.PHASE_1>

If you're interested, please go ahead and take part of the plans. The 
directory contains:

Directory MRMEMO$PUBLIC:<V021.PHASE_1>

CERTPLAN021.LN03;1  CERTPLAN021.PS;4    CERTPLAN021.SDML;7  CERTPLAN021.TXT;1  
DEVPLAN021.LN03;1   DEVPLAN021.PS;10    DEVPLAN021.SDML;15  DEVPLAN021.TXT;1   
DOCPLAN021.LN03;1   DOCPLAN021.PS;6     DOCPLAN021.SDML;4   DOCPLAN021.TXT;1   
PRODSPEC021.LN03;1  PRODSPEC021.PS;26   PRODSPEC021.TXT;2   TESTPLAN021.LN03;2 
TESTPLAN021.PS;6    TESTPLAN021.SDML;8  TESTPLAN021.TXT;1   

Total of 19 files.

As far as the development project is concerned, we are now in phase 2.

Tobias Malmgren 
Project Leader
    

    
    Some of the files referred to in .-1 were too greedily protected. This
    has been corrected.
    
    A few minor modifications have been made to the product spec since the
    latest draft. The least insignificant change is that the
    MULTIPLE_MHSORADDRESS option for the /ADDRESS_TRANSLATION qualifier has
    changed name to MULTIPLE_ORADDRESS. No change in functionality.