Re: html editors

[christopher ferris <chris.ferris@east.sun.com>]

It is but one. In my case, because I choose NOT to use the HTML
editor feature of the Netscape Mail client, but prefer the plaintext
editor that I cannot reply to emails that are HTML formatted unless
I change my settings and use the HTML editor or resort to similar
tactics to those you describe (send the message to myself in plaintext).

My problem with HTML in email is that it can be exploited and constitutes
a potential security hole.

Cheers,

Chris

Martin W Sachs wrote:
> 
> 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
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org