html editors

[Martin W Sachs <mwsachs@us.ibm.com>]

Chris,

What is there about using HTML editors that is annoying?  I have been
receiving a flow of postings lately in which the posting is displayed in a
font size (240 point, I think) that permits 4 characters per line.  I have
to forward each one to myself so I can change the font size in order to
read it.  Is that the symptom?

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



christopher ferris <chris.ferris@east.sun.com>@Sun.COM on 07/31/2001
02:59:48 PM

Please respond to ebXML Msg <ebxml-msg@lists.oasis-open.org>

Sent by:  Chris.Ferris@Sun.COM


To:   ebXML Msg <ebxml-msg@lists.oasis-open.org>
cc:
Subject:  Re: T2 Reliable Messaging w/o CPA or VIA...



First off, can those of you using HTML editors to compose
email please refrain from doing so. Not everyone has a MUA
that can handle this effectively. Besides, it is really annoying;-)

More comments below.

Cheers,

Chris

[1] http://lists.ebxml.org/archives/ebxml-transport/200104/msg00016.html
[2] http://lists.oasis-open.org/archives/ebxml-msg/200107/msg00146.html

David Fischer wrote:
>
> Comments in-line...Regards,David FischerDrummond Group.
>
>      -----Original Message-----
>      From: Burdett, David [mailto:david.burdett@commerceone.com]
>      Sent: Monday, July 30, 2001 2:30 PM
>      To: 'David Fischer'
>      Cc: ebXML Msg
>      Subject: RE: T2 Reliable Messaging w/o CPA or VIA...
>
>      DavidLet's take of these in turn ...
>
>      mshTimeAccuracy
>      >>>This is the accuracy to which a recipient of a message claims to
keep their internal
>      system clocks. This should probably be part of a CPP and not vary
from message to message
>      therefore it does not need to be in the MessageHeader
>      [David Fischer] Agreed, but what if there is no CPP?  I'm not sure
why this is necessary.

It isn't represented in the CPP, nor should it be. I have repeatedly
expressed my
belief that this is unnecessary at best, and more likely unimplementable in
any event [1].

If anything, I could see parties agreeing to a requirement that their
respective
system's system clock be synchronized using something like NTP or some
similar
service and having this reflected in some manner within the CPP/A, but not
mshTimeAccuracy!

I for one would like to see this removed from the 1.1 specification.

>
>      reliableMessagingMethod
>      >>>This needs to be in the Via since it can vary on each hop of a
multi-hop message. I
>      suppose though that, if you are not doing multi-hop then it forces
use of the Via element.
>      I think we could either:
>      1. Put reliableMessagingMethod in the main MessageHeader with the
copy in the Via element
>      over-riding it, or
>      2. Change the definition of the Via element to suggest that it to be
used when there is no
>      intermediary
>      Thoughts?
>      [David Fischer] Option 1.  Let's not muddle the Via.  What if the
MessageHeader
>      reliability is higher (I assume "ebXML" is higher than "Transport").
Should an
>      intermediate hop have a lower reliability than the end-to-end?  Or
do we care since it is
>      a "black box"?  Methods "ebXML" and "Transport" do not seem to be
defined.

I agree with David F (let's not muddle Via).

>
>      ackRequested
>      >>>This is in Via for the same reason as for reliableMessagingMethod
- it can vary from
>      hop-to-hop
>      [David Fischer] How do we accomplish single-hop Reliable Messaging?
We need to be able to
>      request an Acknowledgement without the Via.  We could say that a
DeliveryReceipt is
>      equivalent.  This means the receiver will have to process
DeliveryReceipt as an
>      Acknowledgement (set the Acknowledgement flag in the message
database when a
>      DeliveryReceipt is received and do all the other Reliable Messaging
tasks
>      equivalently--sequencing, persistent store etc.) which would be OK.
Acknowledgement would
>      then NEVER be used except in conjunction with VIA.  This would
uncomplicate Reliable
>      Messaging but chapter 10 would have to be significantly re-written
(replace/combine
>      Acknowledgement with DeliveryReceipt in lots of places).  What about
10.3.3 which
>      specifies that an Acknowledgement MUST be sent.  How is the
receiving MSH to know if this
>      is single-hop or multi-hop (whether to send Acknowledgement or
DeliveryReceipt) by the
>      presence of a VIA element?  I don't think the Via actually get
passed to the end-point
>      since SOAP-Actor=next gets consumed in-route.  How does the last
hop/end know to send an
>      Acknowledgement w/o the VIA?

The MessageHeader/QualityOfService/@deliverySemantics determines whether an
acknowledgment
is sent to the party originating the message.

What I hear you (David F) saying is "how do we accomplish single-hop
reliable messaging
*without a CPA*? To which I would respond, you are (still) interpreting
'doesn't require
a CPA' as 'doesn't require that some representation of the information that
is identified
in the specification is shared by the parties exchanging messages' which is
not the
case at all. The specification *clearly* states in section 10.3.3 on line
1811 that
an Acknowledgment message MUST be generated when the deliverySemantics
="OnceAndOnlyOnce"
and reliableMessagingMethod="ebXML" (default).

If you insist on not having a CPA, then either you find some other
mechanism for
configuring your runtime software to understand how the two parties are
going
to effect reliable messaging or you go with the default behavior that is
described
in the specification, you generate an Acknowledgment message as prescribed
above.

>
>      retries & retryInterval
>      >>>These are both parameters that apply to the sender of a message
and over which the
>      receiver of message can have no effective control. There is
therefore no need for them to
>      be in the header. They should however be in the CPP for the sender
>      [David Fischer] What if there is no CPP?  Is there never a need for
the receiver to know
>      how often and how many times the message will be resent?  Maybe not.
In my experience,
>      the receiver usually ends up calling the sender on the phone for
this info.  This is not
>      needed very often

The receiver probably doesn't ever need to know what values the sender will
use as you point out. Of course, the whole purpose of a CPP/A is to
eliminate the
need for the receiver to pick up the phone in the first place!

>
>      -- only to troubleshoot
>        problems.  I have seen many cases of "why did you send
>        that message to me three times?" when the answer was related to
>        retries.   Agreed.
>
>      persistDuration
>      >>>PersistDuration only applies to the recipient of a message
>        as it specifies the minimum time the recipient will keep a
message. The sender
>        cannot (should not?) control this, therefore there is no need for
it to go in
>        the header.
>      [David Fischer] Agreed.  How is the sender to
>        know?  Should this be in the DeliveryReceipt?  While this should
be

See my previous email regarding persistDuration [2]. I agree with David B
that
it need not be represented in the envelope.

>        agreed to in the CPA, we cannot assume the existence of a CPA.  I
am
>        still on the fence about whether there will be more
implementations with or
>        without a CPP/CPA.  Could go either way depending upon the number
of SME
>        implementations vs. LE.

What makes you think that SME implementations wouldn't benefit from a CPA?
If
you believe that a CPA configured MSH is a more complex/complicated thing
than an MSH without one, then I would have to disagree. In fact, I think
that it makes things much simpler than they might otherwise be.

What is it that makes you so adamant in your opposition to what I and
others consider
to be one of the most compelling aspects of ebXML?

>
>      I'd appreciate your thoughts.
>
>      David
>
>           -----Original Message-----
>           From: David Fischer [mailto:david@drummondgroup.com]
>           Sent: Monday, July 23, 2001 7:07 PM
>           To: Burdett, David
>           Cc: ebXML Msg
>           Subject: T2 Reliable Messaging w/o CPA or VIA...
>
>           Section 10.2 (line 1695) says:
>
>           This parameter information can be specified in the CPA or in
the MessageHeader
>
>           But I can't find anywhere in the MessageHeader to set the
following parameters:
>
>           mshTimeAccuracy
>           reliableMessagingMethod
>           ackRequested
>           retries
>           retryInterval
>           persistDuration
>
>           This seems like a formidable problem when doing reliable
messaging
>           (ackRequested) without an intermediary (no Via).  If we put
this information
>           back in the MessageHeader, why is it also in the Via?  This was
in the
>           MessageHeader in v0.91 but it was taken out... probably
shouldn't have been.
>
>           Regards,
>
>           David Fischer
>           Drummond Group.

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org