RE: [AMG]: Revised Abstract Model draft document.

Ray,

> -----Original Message-----
> From: Ray Denenberg [mailto:rden@loc.gov]
> Sent: 15 February 2001 21:55
> To: Williams, Stuart
> Cc: 'rden@loc.gov'; 'xml-dist-app@w3.org'
> Subject: Re: [AMG]: Revised Abstract Model draft document.
> 
> 
> Stuart -- thanks much for your thoughtful treatment of my comments.
> 
> "Williams, Stuart" wrote:
> 
> > Alternatively, .request and .indication could be relabelled as .send and
> > .receive for both Data and UnitData operations
> >
> 
> Have you considered relabelling .response and .confirm (rather than
.request and
> .indication) as .send and .receive for both Data and UnitData.  (I.e. get
rid of
> .response and .confirm altogether).  That would take care of the 
> too-many-primitives problem.  It would also solve the problem of .confirm
> semantics (though I think the suggestion to use .status also would solve
that
> problem and I think the .status primitive  is fine).   This is a somewhat
> radical suggestion, but consider this: we view UnitData as essentially
half of a
> Data operation;  by the conventional view, it's the first half (so one
would
> think, from the abstract model). I think it more resembles the second
half. Put
> another way: a Data operation is (first half) a request for information,
> followed by (second half) delivery of information; a UnitData operation
could be
> viewed as just the delivery, without the request.

I think I'd get myself confused if I relabeled the Data .response and
.confirm as .send and .receive. It would get the direction messed up (for
me). I'm inlined to confine the relabeling just to the Unitdata primitives.

As regards the radical suggestion, I'm almost to the point where we'd
ideally want just UnitData. However, I think our commitment to an HTTP
binding means that we *have* to have a expose the request/reponse nature of
HTTP through the expression of the services provided by the XMLP layer. Your
'radical' suggestion suggests going the other way and suggestion that
verything is two-way, except that the response may be 'null'. Which is kind
of ok, and we could do that... in that circumstance you would expect a
.confirm with a 'null' message and some delivery status.

Where things come a little adrift for me is if you consider an XMLP/HTTP to
XMLP/SMTP gateway... that just repackages to message for transport over
SMTP. How is it to know whether to hold open the HTTP/TCP connection back to
the initiating device in anticipation of an actual response returned via
email to the gateway, or whether to close off the HTTP/TCP connection with a
'null' XMLP response.

The other concern that I have is that UnitData only implies a sense of
symmetry (anyone can sent to anyone whenever they like) which isn't there
when layered over HTTP unless you implement HTTP clients and HTTP servers at
both ends. An HTTP server can not arbitrarily send a message to an HTTP
client - it also can't send more responses than it receives requests - which
was one of scenarios you offered around Z39.50. Certainly, we can go for a
nice uniform UnitData world if we make the assumption that all nodes
implement an HTTP server and an HTTP client.

> > I guess I'm heavily influenced by the primitive style from the IEEE 802
LAN
> > specs which (for me) is where  .request, .indication, .response and
.confirm
> > come from
> >
> 
> My memory of the history of this isn't entirely clear (it's been about 20
years)
> but I think that 802 spec simply adopted the OSI service conventions (I
may be
> wrong, it may be that the OSI conventions followed the LAN conventions).

I only meant to imply thats where I first came across them... not that the
originated with the 802 community.

> The
> LAN standards are among very few OSI protocols that have survived.  And
along
> those lines let me relate personal experience. Z39.50 (which I'm the
editor of)
> was originally an OSI standard, and continues to employ these conventions,
which
> have confused people so much (for many years now) that they are almost
certain
> to be refined along the lines I'm suggesting, in the next major release.

I'd be interested to chat with you about this. I've always found them an
appealing way of modeling the fact that you have to  'poke' protocol
machinary with some sort of events. Something happens, packets flow...

> Regarding my first concern,  the revised definitions 
> certainly address them very
> well; thanks.

Good.

>  One  comment:
> 
> >
> > XMLP_Data.indication: Invoked by the responding XML protocol  processor
and
> > directed at a local responding XML protocol application to deliver the
> > outbound XML protocol message.
> >
> > This primitive is invoked as a result of the arrival of a XML protocol
message
> > from the underlying protocol layers.
> 
> I suggest "...arrival of an XML protocol message from the 
> initiating XML protocol  processor (via the underlying protocol layers)"  
> because I think that modeling protocol exchange as peer-to-peer
communication, in 
> my experience, is a useful tool towards explaining these abstractions.
> 
> Similar comment for XMLP_Data.confirm.
> 
> >
> > For section 3.2 I have tried the following relabeling of the primitives
(in
> > relation to observation 2):
> > XMLP_UnitData.request      -> XMLP_UnitData.send
> >
> > XMLP_UnitData.indication   -> XMLP_UnitData.receive
> >
> > XMLP_UnitData.confirm      -> XMLP_UnitData.status
> >
> > On the UnitData.confirm I felt that both .acknowledge and .deliver also
have
> > the potential to mislead, .status seems more in tune with what I think
> > happens.
> 
> The .status primitive seems fine to me.  If you were to adopt my
suggestion
> above about dropping request and confirm altogether for the Data operation
(and
> Ill grant, it's a radical suggestion), then .Confirm would be fine too.

I'm going to stick at where we got to. The radical is certainly up for
discussion, but for now I need to freeze a version for the F2F to consider.

BTW... given your contributions I would be very happy to credit you as
contributor to the document provided that you feel it would be appropriate.

> 
> Thanks again, for considering my suggestions.
> 
> --Ray

Best regards

Stuart

Received on Friday, 16 February 2001 10:50:47 UTC