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 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). 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.

Regarding my first concern,  the revised definitions certainly address them very
well; thanks.  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.

Thanks again, for considering my suggestions.

--Ray


--
Ray Denenberg
Library of Congress
rden@loc.gov
202-707-5795

Received on Thursday, 15 February 2001 16:55:21 UTC