Marko's ID on table distribution

Urs Eppenberger <Eppenberger@switch.ch> Fri, 19 March 1993 16:34 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08124; 19 Mar 93 11:34 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08120; 19 Mar 93 11:34 EST
Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa06804; 19 Mar 93 11:34 EST
X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Fri, 19 Mar 1993 10:13:55 +0000
Date: Fri, 19 Mar 1993 10:13:55 +0000
X400-Originator: cargille@cs.wisc.edu
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/; mhs-relay..146:19.02.93.16.13.55]
Priority: Non-Urgent
DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Fri, 19 Mar 1993 10:13:55 +0000;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Urs Eppenberger <Eppenberger@switch.ch>
Message-ID: <1230*/S=Eppenberger/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS>
To: ietf-osi-x400ops <ietf-osi-x400ops@cs.wisc.edu>
Subject: Marko's ID on table distribution

Since it gets a big slot at the next IETf meeting, I post my first comments
to this list.

I suggest to announce/request/send only one table per message.

The goal of your document is that a recipient has the most up-to-date
versions of the tables he needs in his archive. In chapter 4.2 all possible
error cases are covered. It is missing the actions that the recipient of such
an error should undertake.

If a client receives an IHAVE note, does it request the newest version
from all known servers or just from the server it got the IHAVE from?

Please extend the graph in chapter three with the keywords IHAVE/SENDME/DATA
at the correct places. It already clear but it will make it even more
understandable.

I do not like the version format HHMMSS-DDMMYY, due to easier sorting I
suggest to use YYMMDD-HHMMSS.

I do not think the directory information is needed for the table
identification. I'd rather use clear table names instead.

It is not stated anywhere but I think the version number must be kept from
the root to the leaves. (If the version is always recalculated according the
local date and time, we will certainly end up in version confusion.)

The formal definition has the <start-separator> <table> <end-separator>
as always present, which is not true in case of an error. You need to
make it optional.

What happens if the client receives a positive answer with a wrong serial
number?

The example of the end separator uses two spaces here:
----------  end cosine-mhs/mapping-1  ----------
          ^^                        ^^
this is not allowed according the specification. The definition is
ok, the example would cause me headaches if I try to think of a PERL
matching statement (ok HTA of Felix probably already built the code in
their head while reading Marko's doc.)

In general I would like to have it extended to cover all possible
actions and reactions between server and client.


That's it for the moment.

Kind regards,

Urs.