+1.
When (and if) we visit the (infamous) Service Interface Layer, there are a
few more points we need to look at, anyway.
cheers
| -----Original Message-----
| From: Christopher Ferris [mailto:]
| Sent: Thursday, December 06, 2001 8:26 AM
| To: David Fischer
| Cc: Ralph Berwanger;
| 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:]
| > Sent: Thursday, December 06, 2001 9:13 AM
| > To:
| > 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:]
| > Sent: Thursday, December 06, 2001 9:05 AM
| > To: David Fischer
| > Cc: Christopher Ferris; Dan Weinreb;
| > 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 <> on 12/05/2001 03:14:44 PM
| >
| > To: Martin W Sachs/Watson/IBM@IBMUS
| > cc: Christopher Ferris <>, Dan Weinreb
| > <>,
| > 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:]
| > Sent: Wednesday, December 05, 2001 10:21 AM
| > To: David Fischer
| > Cc: Christopher Ferris; Dan Weinreb;
| > 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 <> on 12/05/2001 09:59:17 AM
| >
| > To: Martin W Sachs/Watson/IBM@IBMUS, Christopher Ferris
| > <>
| > cc: Dan Weinreb <>,
|
| > 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:]
| > Sent: Wednesday, December 05, 2001 8:08 AM
| > To: Christopher Ferris
| > Cc: David Fischer; Dan Weinreb;
| > 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 <> on 12/04/2001 09:39:42 PM
| >
| > To: David Fischer <>
| > cc: Martin W Sachs/Watson/IBM@IBMUS, Dan Weinreb
| > <>,
| >
| > 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:]
| >>Sent: Tuesday, December 04, 2001 5:01 PM
| >>To: Christopher Ferris
| >>Cc: David Fischer; Dan Weinreb; ;
| >>
| >>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 <> on 12/04/2001 05:46:11 PM
| >>
| >>To: Martin W Sachs/Watson/IBM@IBMUS
| >>cc: David Fischer <>, Dan Weinreb
| >> <>,
| >>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 <> on 12/04/2001 02:39:43 PM
| >>>
| >>>To: Martin W Sachs/Watson/IBM@IBMUS
| >>>cc: Dan Weinreb <>,
| >>>
| >
| >
| >>>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:]
| >>>Sent: Tuesday, December 04, 2001 10:50 AM
| >>>To: David Fischer
| >>>Cc: Dan Weinreb;
| >>>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 <> on 12/04/2001 11:16:21 AM
| >>>
| >>>To: Dan Weinreb <>
| >>>cc:
| >>>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:]
| >>>Sent: Monday, December 03, 2001 9:40 PM
| >>>To:
| >>>Cc: ;
| >>>Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
| >>>
| >>>
| >>> Date: Mon, 03 Dec 2001 20:30:08 -0600
| >>> From: David Fischer <>
| >>>
| >>> 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>
| >
|
|
|
| ----------------------------------------------------------------
| To subscribe or unsubscribe from this elist use the subscription
| manager: <http://lists.oasis-open.org/ob/adm.pl>
|
