OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId


+1

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Thursday, December 06, 2001 10:26 AM
To: David Fischer
Cc: Ralph Berwanger; ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId


I don't think that we need to say anything about
this at all. As Marty has indicated, control over
the conversation is within the application/process management
domain, not the MSH. If anything, this would be something
in the realm of the infamous Service Interface layer
and not part of this spec.

We're writing a protocol spec, not an implementation design
specification.

Cheers,

Chris

David Fischer wrote:

> I'm sorry, I was not clear enough.
> 
> Conversations may not end, from the MSH perspective, because there is no
> notification to the MSH that a Conversation has ended -- at least we have not
> identified such a thing.  If we would specify such a thing, the notification
> must be made to both ends of the Conversation.
> 
> This sounds like new functionality.
> 
> Regards,
> 
> David.
> 
> -----Original Message-----
> From: Ralph Berwanger [mailto:rberwanger@bTrade.com]
> Sent: Thursday, December 06, 2001 9:13 AM
> To: ebxml-msg@lists.oasis-open.org
> Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
> 
> 
> Marty,
> 	Speaking from the legacy community point-of-view, we have been
> discussing the fact that each EDI interchange (set of purchase orders)
> would be a unique conversation.  I cannot recall a single discussion
> where the concept of a never-ending conversation came up (except for a
> couple standards bodies but that is a different subject all together).
> That does not mean that you are not correct in the assumption, only that
> it appears contrary to my experience. Also, I said that I do not
> 'recall' and that can provide some hints to my baseline.
> 
> Ralph
> ASC X12, Vice Chair
> 
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Thursday, December 06, 2001 9:05 AM
> To: David Fischer
> Cc: Christopher Ferris; Dan Weinreb; ebxml-msg@lists.oasis-open.org
> Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
> 
> 
> 
> David,
> 
> See comments below, MWS:
> 
> 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
> ************************************************************************
> *************
> 
> 
> 
> David Fischer <david@drummondgroup.com> on 12/05/2001 03:14:44 PM
> 
> To:    Martin W Sachs/Watson/IBM@IBMUS
> cc:    Christopher Ferris <chris.ferris@sun.com>, Dan Weinreb
>        <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org
> Subject:    RE: [ebxml-msg] Re: Comments on the 1.09 about
> ConversationId
> 
> 
> 
> Marty,
> 
> I was suggesting first that we might not need messageOrderSemantics and
> we
> could
> do away with this attribute.
> 
> I was suggesting second, that it is not particularly useful to tie
> MessageOrder
> to ConversationId.  I did not mean to imply that MessageOrder would be
> outside
> the confines of a Conversation.  We have no means of ending a
> Conversation
> and I
> suspect it will be common for Conversations to never end (why should
> they?).
> 
> MWS:  Someone else expressed the view that conversations will always
> end.
> In my mind,
> applications that are conversation-based will naturally equate a
> conversation with
> one unit of business (e.g. one purchase) and so, conversations will
> always
> end. I
> suspect that there will be edge cases of legacy software that is not
> ebXML-aware that
> does its own conversation mangement based on information in the payload
> (e.g purchase
> order number).  The MSH might see that as a single never-ending
> conversation.
> 
> MWS:  You have to have a means of ending a conversation. You don't
> actually
> end it.
> The application does that but you have to be notified that the
> conversation
> is ended
> precisely so you can purge obsolete stuff from the persistent store.
> Two
> approaches
> have already been suggested on this list:
> 
>    1. Software at each party notifies its MSH
>    2. Software on the side the sends the last message notifies its MSH
> and
>    the
>    message header contains a flag that notifies the To MSH.
> 
> We
> do not specify that a ConversationId must be kept in storage anywhere in
> the
> spec.
> 
> MWS:  No but since you can (and usually have to) use the convesationId
> for
> routing,
> there is an implication that you keep information around that enables
> that
> routing
> to be done.
> Since there is only a single conversationId, one or both parties has to
> do
> mapping,
> which requires some mapping issue to be kept in the persistent store
> with
> the
> conversationId.
> There is an alternative which the team rejected at least once:  The
> conversationId
> contains a piece that each party supplies (on the first message
> exchange)
> and that
> piece is the actual routing information about the conversation. Since
> the
> actual
> routing information, rather than a label, is in the message header, the
> MSH
> does
> not have to keep the conversationId and mapping information int he
> persistent store.
> 
> I am looking for another way -- say a new set of ordered messages could
> include
> the start number so the Receiving MSH does not have to keep messages
> past
> persistDuration?
> 
> MWS: I think that it has already been pointed out that the whole
> last-ordered message
> does not have to be saved in its entirety until the next in-order
> message
> arrives; only the
> conversationId, last ordered sequence number, and a few other header
> things
> have to
> be saved.
> 
> I don't know the solution but I think MessageOrder is broken.
> IMO, keeping information in persistent store forever is not the right
> answer,
> 
> MWS: Again, mostly not forever since most conversations end.
> 
> but I will go with that if it will get us past this problem.
> 
> David.
> 
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Wednesday, December 05, 2001 10:21 AM
> To: David Fischer
> Cc: Christopher Ferris; Dan Weinreb; ebxml-msg@lists.oasis-open.org
> Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
> 
> 
> 
> Some comments below, MWS:
> 
> 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
> ************************************************************************
> ********
> 
> *****
> 
> 
> 
> David Fischer <david@drummondgroup.com> on 12/05/2001 09:59:17 AM
> 
> To:    Martin W Sachs/Watson/IBM@IBMUS, Christopher Ferris
>        <chris.ferris@sun.com>
> cc:    Dan Weinreb <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org
> Subject:    RE: [ebxml-msg] Re: Comments on the 1.09 about
> ConversationId
> 
> 
> 
> Shimamura-san's modification of Marty's words (edited version):
> 
>    When messageOrderSemantics is set to "Guaranteed", the Receiving MSH
>    shall preserve in persistent storage all required SOAP Header
>    information, including SequenceNumber, needed to keep the
>    Message Order semantics of the last message in the conversation
>    sent in order to the application until either a subsequent
>    in-order message arrives or until the conversation ends
>    (no matter how long the conversation exists).
> 
>    The Receiving MSH shall preserve in persistent storage the
>    ConversationId of an in-progress conversation until that conversation
>    ends (no matter how long the conversation exists).
> 
> MWS:  I still think that a non-normative reminder is needed that these
> holding
> times might exceed the value of persistDuration
> 
> Does this meet everyone's requirements?  I think we will get some flack
> since
> this guarantees slow accumulation of old ConversationIds in persistent
> Storage.
> 
> MWS:  You can't avoid accumulating old conversationIds since a
> conversation
> can last a long time.  The conversationIds will eventually be purged as
> each
> conversation ends.  A never-ending conversation will only contribute one
> conversationId, so it shouldn't be a big deal.
> 
> In the second paragraph, do we need to say Conversations with
> messageOrderSemantics set to "Guaranteed"?
> 
> Do we need messageOrderSemantics?  If MessageOrder is present, why would
> messageOrderSemantics ever be "NotGuaranteed"?  The problem is
> MessageOrder
> tied
> to ConversationId.  MessageOrder is a very time limited situation while
> ConversationId can be unlimited -- not a good match.
> 
> MWS: As long as the sequencing is within a conversation, that's the way
> it
> is.
> If you try to do message ordering over the entire stream, you need
> sequence
> numbers across the entire stream and you are spinning your wheels
> ordering
> message that have no functional time relationship to each other.
> 
> Regards,
> 
> David.
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Wednesday, December 05, 2001 8:08 AM
> To: Christopher Ferris
> Cc: David Fischer; Dan Weinreb; ebxml-msg@lists.oasis-open.org
> Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
> 
> 
> 
> You need to say enough in the MSG spec to inform an implementer that
> persistDuration follows different rules for conversationId and
> last-ordered-message than for reliable messaging.  Considering the
> amount
> of discussion we have had on this point, we cannot assume that a
> "reasonable implementer" will know what to do. There are plenty of
> examples
> in the newspapers about deadly mistakes made by reasonable implementers.
> The Risks Forum mut be full of them.
> 
> 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@sun.com> on 12/04/2001 09:39:42 PM
> 
> To:    David Fischer <david@drummondgroup.com>
> cc:    Martin W Sachs/Watson/IBM@IBMUS, Dan Weinreb
> <dlw@exceloncorp.com>,
>        ebxml-msg@lists.oasis-open.org
> Subject:    Re: [ebxml-msg] Re: Comments on the 1.09 about
> ConversationId
> 
> 
> 
> The thing I have trouble with here is why we have to say anything
> in the spec. This is too suggestive of implementation detail
> IMO (although probably accurate). Why do we need to say anything
> about this at all?
> 
> Cheers,
> 
> Chris
> 
> David Fischer wrote:
> 
> 
>>OK, I think that will work, but it is not the whole message which
>>
> needs
> to be
> 
>>saved.  Once the message is delivered to the application, just the
>>
> MessageId,
> 
>>CPAId, persistDuration, ConversationId, SequenceNumber (did I get
>>
> everything?)
> 
>>need to be saved.  The spec says now only the MessageId needs to be
>>
> saved
> but
> 
>>that's not enough for MessageOrder.
>>
>>David.
>>
>>-----Original Message-----
>>From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
>>Sent: Tuesday, December 04, 2001 5:01 PM
>>To: Christopher Ferris
>>Cc: David Fischer; Dan Weinreb; ebxml-msg@lists.oasis-open.org;
>>ebxml-cppa@lists.oasis-open.org
>>Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>>
>>
>>
>>Then it should only be necessary to add to the MSG spec words that
>>
> say:
> 
>>   The MSH shall preserve in persistent storage the last message in
>>
> the
> 
>>   conversation that was sent in order to the application until either
>>
> a
> 
>>   subseqent in-order message arrives or until the conversation ends
>>   (regardless of how long that takes). These words probably should be
>>   modified if preserving some header information is all that is
>>
> needed.
> 
>>   The MSH shall preserve in persistent storage the conversationId of
>>
> an
> 
>>   in-progress conversation until that conversation ends (no matter
>>
> how
> 
>>   long that takes).
>>
>>
>>No change is needed to the CPPA spec unless it now does not say that
>>persistDuration is the mininum length of time... (see Chris' words
>>
> below).
> 
>>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@sun.com> on 12/04/2001 05:46:11 PM
>>
>>To:    Martin W Sachs/Watson/IBM@IBMUS
>>cc:    David Fischer <david@drummondgroup.com>, Dan Weinreb
>>       <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org
>>Subject:    Re: [ebxml-msg] Re: Comments on the 1.09 about
>>
> ConversationId
> 
>>
>>
>>right now, the spec suggests #1 which is that pd is the
>>minimum length of time that a party will commit to
>>preserving a message (or its relevant artifacts) in
>>persistent store for purposes of filtering duplicate
>>messages.
>>
>>Cheers,
>>
>>Chris
>>
>>Martin W Sachs wrote:
>>
>>
>>
>>>One of these possibilities:
>>>
>>>1. If the MSG spec states that persistDuration is a minimum length of
>>>
>>>
>>time,
>>
>>
>>>then all you need is to add words to the MSG spec conveying additional
>>>rules when message ordering is in effect.
>>>
>>>2. If the MSG spec states that messages that live until
>>>
> persistDuration
> 
>>>MUST be discarded right away, then we probably need additional text in
>>>
>>>
>>both
>>
>>
>>>the MSG and the CPA spec.
>>>
>>>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
>>>
>>>
>>>
> ************************************************************************
> ********
> 
> 
> 
> 
>>*****
>>
>>
>>
>>>
>>>David Fischer <david@drummondgroup.com> on 12/04/2001 02:39:43 PM
>>>
>>>To:    Martin W Sachs/Watson/IBM@IBMUS
>>>cc:    Dan Weinreb <dlw@exceloncorp.com>,
>>>
> ebxml-msg@lists.oasis-open.org
> 
>>>Subject:    RE: [ebxml-msg] Re: Comments on the 1.09 about
>>>
> ConversationId
> 
>>>
>>>
>>>Yes Marty, absolutely.  I think there are potential problems
>>>
> (discussed
> 
>>>below)
>>>which make MessageOrder quite fragile.  I am shuddering over the
>>>
> thought
> 
>>of
>>
>>
>>>changing the persistDuration rules depending upon whether or not
>>>MessageOrder is
>>>present (wouldn't this constitute a CPA override!).
>>>
>>>I still like your other solution.
>>>
>>>Regards,
>>>
>>>David Fischer
>>>Drummond Group.
>>>
>>>-----Original Message-----
>>>From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
>>>Sent: Tuesday, December 04, 2001 10:50 AM
>>>To: David Fischer
>>>Cc: Dan Weinreb; ebxml-msg@lists.oasis-open.org
>>>Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>>>
>>>
>>>
>>>Some comments below.
>>>
>>>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
>>>
>>>
>>>
> ************************************************************************
> ********
> 
> 
> 
> 
>>
>>>*****
>>>
>>>
>>>
>>>David Fischer <david@drummondgroup.com> on 12/04/2001 11:16:21 AM
>>>
>>>To:    Dan Weinreb <dlw@exceloncorp.com>
>>>cc:    ebxml-msg@lists.oasis-open.org
>>>Subject:    RE: [ebxml-msg] Re: Comments on the 1.09 about
>>>
> ConversationId
> 
>>>
>>>
>>>Dan, did you mean to imply that messages are no longer stored once
>>>
> they
> 
>>are
>>
>>
>>>acknowledged?  This is not the case.  Messages must be stored longer
>>>
> than
> 
>>>persistDuration.  In your scenario, when 12 got to the Receiving MSH,
>>>
>>>
>>1-10
>>
>>
>>>are
>>>still in the store.  If you wait so long that 1-10 have passed
>>>persistDuration,
>>>then I think you have waited so long that it does not matter any more.
>>>
>>>I see your point about what happens if there is nothing in the store
>>>
> and
> 
>>>the
>>>Receiving MSH gets a message with a number larger than 1.  However,
>>>
> this
> 
>>>implies
>>>the last ordered message/MessageId (which has been delivered in order)
>>>
>>>
>>must
>>
>>
>>>be
>>>stored indefinitely (forever?) which is probably not acceptable.
>>>
>>>MWS:  For most conversations, there will be an indication of an end,
>>>
> at
> 
>>>which time
>>>the last ordered message can be discarded.  I guess if storage is
>>>
> tight,
> 
>>>you
>>>only need to keep the sequence number and conversationId of the last
>>>ordered message
>>>
>>>
>>>This also
>>>points out the conflict between Message Order and persistDuration.
>>>
> What
> 
>>if
>>
>>
>>>messages 1,2,3,4 have persistDuration of 2 days.  Messages 1,2,4 are
>>>delivered.
>>>The MSH hands 1,2 to the application but holds 4.  For some reason, 3
>>>
> is
> 
>>>not
>>>delivered for 3 days.  In this case 3,4 have already passed
>>>
>>>
>>persistDuration
>>
>>
>>>so
>>>they are not delivered.  The next day, 5 is delivered.  Since 3,4 were
>>>
>>>
>>not
>>
>>
>>>delivered, then 5 cannot be delivered (nor any subsequent messages)
>>>
> even
> 
>>>though
>>>it is still within TTL, and the ordering is forever broken for this
>>>ConversationId.  We may have to say Message Ordering does not work if
>>>
> any
> 
>>>message in the order fails to be delivered within its persistDuration
>>>
> (or
> 
>>>maybe
>>>TTL)?  Of course, all this can be adjusted at run time by increasing
>>>
> the
> 
>>>value
>>>of persistDuration in the CPA.  Once again, MessageOrdering is based
>>>
> on
> 
>>>persistDuration.
>>>
>>>MWS:  All of which says that some additional rules are needed on
>>>
>>>
>>discarding
>>
>>
>>>messages
>>>in the presence of ordering.  The last ordered message cannot be
>>>
>>>
>>discarded
>>
>>
>>>until
>>>either the next message in the sequence arrives or the application
>>>
> ends
> 
>>the
>>
>>
>>>conversation,
>>>regardless of its persist duration.  Similary, if there is a gap in
>>>
> the
> 
>>>sequence numbers,
>>>all the out of sequence messages must be preserved, regardless of
>>>persistDuration,
>>>until they can be delivered.  The MSG or CPPA specification must
>>>
> provide
> 
>>>advice on
>>>how long to set persistDuration depending on what combination of
>>>
> reliable
> 
>>>messaging
>>>and ordering is being used.
>>>
>>>I am wondering why are we messing with all of this?  Did I see Marty
>>>suggest, if
>>>messages are order dependant, just wait for acknowledgment from the
>>>
> end
> 
>>>before
>>>sending the next message?  Sounds good.
>>>
>>>MWS:  Ahhh... the light begins to dawn.
>>>
>>>Regards,
>>>
>>>David.
>>>
>>>-----Original Message-----
>>>From: Dan Weinreb [mailto:dlw@exceloncorp.com]
>>>Sent: Monday, December 03, 2001 9:40 PM
>>>To: david@drummondgroup.com
>>>Cc: rberwanger@btrade.com; ebxml-msg@lists.oasis-open.org
>>>Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>>>
>>>
>>>  Date: Mon, 03 Dec 2001 20:30:08 -0600
>>>  From: David Fischer <david@drummondgroup.com>
>>>
>>>         If there
>>>  are no messages in the persistent store pertaining to a
>>>
> conversation,
> 
>>>  then
>>>there
>>>  is no need to store it any longer for the purposes of maintaining
>>>  message
>>>order.
>>>
>>>I'm not sure that would work.  Suppose two parties establish a
>>>conversation with ID 5551212.  Party A sends messages numbered 1
>>>through 10 to Party B, and party B's application reads all the
>>>messages and acknowledges them, so that there aren't any messages
>>>still waiting to be delivered to B.  Now a message arrives at B with
>>>conversation ID 5551212 and a sequence number of 12.  The MSH at B's
>>>end has to realize that is should not deliver this message to the
>>>application because message 11 hasn't arrived yet.  So the MSH at B's
>>>end has to be storing somewhere the fact that the most recent message
>>>delivered to the application from conversation 5551212 is 10.
>>>
>>>-- Dan
>>>
>>>
>>>
>>>----------------------------------------------------------------
>>>To subscribe or unsubscribe from this elist use the subscription
>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>----------------------------------------------------------------
>>>To subscribe or unsubscribe from this elist use the subscription
>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>>
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>
>>
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC