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


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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

Subject: Draft F2F minutes

Martin Chapman                                 
Consulting Member of Technical Staff           
P: +353 87 687 6654                           
e: martin.chapman@oracle.com                   
Minutes WS-CAF F2F 25th to 27th February, Paris, France

Hosted by Attachmate


Day 1 - AM -- Jeff
Day 1 - PM -- Doug
Day 2 - AM -- Simeon
Day 2 - PM -- Peter
Day 3 - AM -- Greg


  Jean Jacques Dubray,  Malik Saheb, Peter Furniss, Doug Bunting, Greg
  Pavlik, Simeon Greene, Jeff Mischkinsky, Martin Chapman, Dale Moberg,
  Alstair Greene

Not quorate (10 out of 28)

Agenda Review:

Push ws-rf discussion into FAQ topic, which will now start at 2:30

Since we are not quorate, we will establish positions via consensus and
then vote to ratify (or not) at the next quorate opportunity.

Previous Minutes:

Review of minutes from 16 Feb.

Process for minutes and agendas -- minutes and agendas should be sent to
the email list in an open format -- text (or pdf). Chairs will copy into
Kavi but turning member notification OFF -- so that we're not bombarded by
the update messages. End result is that you will be able to view minutes
off the event listing in Kavi and have an email record for yourself.

Issue 16 - Doug reported that the notes I believe my proposed (and
accepted) amendment for issue 16 was a follow up to an earlier question
about the follow-up to any items discovered using the testing tools.
Replace both bulletted items with: "Minor items discovered through this
testing will be handled within the editorial team.  Any important concerns
will become separate issues for TC consideration".

Minutes 16th feb approved Unanimously at the meeting

Action Item Review
Eric post editorial issues for issues 12-20 ... NOT DONE

Mark - Automatic update of bugzilla -- NOT DONE

Eric to contact WS-RF folks -- NOT DONE

Editor's Report/spec logistics
Editor's had a discussion to iron out document and issue management. One
thing was a need to separate the "pre-TC" issues and docs with post-TC
formation. Mark has the AI to go in and tidy up the bugzilla db, so that it
only contains  relevant issues.

The spec actually is made of several pieces -- text, schema, and
wsdl. Since these wind up in different files, there is an issue of
management to keep versions in synch.

After some discussion it was decided that the editors will maintain and
publish a single zip file which will contain a complete consistent set of
all the constituent parts of the spec, including source.
[chairs note - recent viruses relatedto zip files might make us revist this decision] 

Resolved status meanings in Bugzilla:

ASSIGNED -- issue is in the system
LATER -- means group has voted on resolution, but has not yet been
incorporated into a working draft, although in all likelihood the editors
will have folded the resolution into the latest editing draft
FIXED - means group has adopted a working draft -- blessing an editor's
draft as correctly reflecting decisions of the group

Mark has updated bugzilla to reflect the above scheme. Mark still needs to
sanitize the bugzilla list to remove pre-TC issues.

An editors subgroup will be set up (anyone can sign up, but it is for
editors's use). Editors' call will occur at 4PM GMT (8 AM Pacific) on
alternate Thursdays. dates tbd

Issues as they are resolved need to have the resolution in its full final
form need to be pasted into bugzilla after the minutes are
approved. Currently they are only in the minutes.

Action: chairs, Person responsible for updating resolutions in bugzilla to be identified.

Issue 15 - consensus is - issue is valid (it is in the last official
adopted WD), and the resolution is to fix as suggested in bugzilla --

 *** Unanimous ***

Action: chairs to determine if  bugzilla db backed up and if  access to account creation
restricted to WS-CAF members.

Issue 41 - mis-labeled = re-categorized to WS-CF

Issue 12 -- no change, it's ok

Issue 52, 53, 54 -- defer discussion until later in meeting

Issue 59 - AI Greg to produce sequence diagrams to vote on.

Motion: TC adopts policy that sequence shall be used to depict
interactions. Consensus to do so.

 *** Unanimous ***

Issue 60 -- discuss later today

Issue 62 -- issue needs clarification -- AI Simeon to ask proposer to
elucidate and explain, otherwise we will close the issue

Issue 68 -- close fixed resolved by previous discussion about zip files,

Issue 14 -- AI Greg/Mark to restructure the status type

Issue 20 -- AI editor's need to make the spec consistent

Issue 43 -- In all the schemas, the any element should be moved to be the
first element to allow for "true" extensibility. (##other extension points
should be put at the beginning).

 *** Unanimous ***

Issue 46 -- defer discussion to later

Issue 47 -- Need clarification/risk analysis/scoping work - volunteer tbd

Issue 48 -- defer discussion to later

Issue 49 -- AI Simeon to put a proposal on the table -- general agreement
to not use substitution groups if possible

Issue 50 -- mismatch between text and wsdl -- resolution needs to be
proposed. Note the answer to this question is intimately bound with issue
103 -- what is indentity? 


** Question 1
   Jeff proposes some wording: "to define a generic" -> "to provide an open
   industry forum", add "As the work of the TC progresses, it will refine
   and develop this framework.  This FAQ will be updated as appropriate."

** Question 2

   When looking at questions 2 and 3, it is hard to answer question "what
   is WS-CAF?" until the TC has completed its work.  Must say the input
   documents are not completed but early working drafts for TC use.  Need
   some term to describe the input documents (not "WS-CAF Framework").
   For this question: Just ask what the input was?  Make sure people know
   the WS-CAF documents out there are not competitive in any way but are
   the input for this TC.
   Resolved, change question to "What was the original input for the TC's
   work?"  Change answer to begin "The TC bases its work upon the WS-CAF
   specifications published by ..."

** Question 3
   Really, asking more about the input documents.  Change second sentence
   of answer to read "WS-CAF currently includes three specifications:"
   Note: We are assuming this FAQ will be living document and will be
   updated as we progress.  Ensure our FAQ is dated and updated as changes
   Specifically, we are having a current discussion around the structure of
   the document set.
   Resolved: Change last sentence to "WS-TXM is designed so that other
   transaction models could be added if the need arose."

** Question 4
   Allastair notes that BTP at least used open processes to discuss some of
   these issues.  While it did not reach the status of an OASIS Standard,
   this answer should avoid the implication nothing had been done in the
   Change "of the last remaining items to be standardized" to "key items
   not yet standardized".
   Change "menas" to "provides" and "into a single transaction" to "into a
   coordinated set" in the third paragraph.  Delete comma after "various".
   Delete everything after "known state".
   Last sentence does not clearly make the point about distinction between
   business process management and business transactions.  Change to "
   "compensations and asynchronous business process flows" to
   "compensations and the transactional apsects of business process flows"
   Add "WS-CAF directly includes support of three transaction protocols:
   ACID, long running action (LRA) and business process".

** Question 5
   Questions on meaning of "You’ll want to make sure that the work they do
   is associated with your work somehow."  Who is "you"?  Replace this
   sentence with "The work of the travel providers must be associated with
   your overall travel plans."  Change "flight shops, hotels and car rental
   organizations" to "flight, hotel and car rental organizations".
   Next sentence begins with a definition not true in our current
   specifications and "shared resource" is not truely as constrained as the
   examples indicate.  Travel example does not fit either (no single
   distributed context or shared resource), in that case you have unshared
   resources that are used within a larger business context.  Context in
   our framework can both be directly accessed (updated) and identify
   non-shared information of interest to just one service.  Trying to get
   to the common thread through the many examples we have of context.

    Allastair proposes changing definition to read "for the purpose of
    carrying out multiple related operations.  The most basic means of
    establishing the relationship between operations is through a shared
    context."  Also, remove "defined as" from first sentence.
    New issue: As previously defined (mentioning a "specified sequence"),
    context management may be useful outside of a composite application.
    Ended up rephrasing first sentence of second paragraph to "A composite
    is a collection of related Web service operations."

** Question 7
   What does reciprocal royalty free terms mean?  Jeff is not a lawyer but
   current OASIS rules prohibit chartering a TC on purely RF terms.  Went
   through some of the history in setting up the TC.  Referred to the
   charter for clear description of the TC intents and directions in the
   area of licensing.  May answer this question using words copied from the
   charter or link to that document.
   Change answer to "The goal of this TC is to define a set of royalty-free
   related, interoperable and modular specifications.  See the charter
   (http://www.oasis-open.org/committees/ws-caf/charter.php) for further

** Question 6
   Change first sentence to start with "The TC will work..."  Delete second
   paragraph of answer.  Delete "also" in third paragraph and change
   "definitions" to "mechanisms".  Last sentence is more an answer to "What
   is the benefit of this framework for all web services specifications?"
   but will remain.

Action: Eric to updtae FAQ based on f2f comments

* WSRF discussion

  On our list, a number of issues touching on WSRF have been discussed.
  Questions include:
	. Should future versions of WSRF make use of WS-Context?
	. What is the current state of our attempts to influence WSRF "community"?
	. Is WSRF useful and are people of a mind to use it?
	. Does WSRF represent a distribute OO model where we lean toward SOA?
  Questions of identifying true termination of a reference (addressing
  issues) have also emerged in this TC.

  Do you build object reference into the addressing mechanism or place key
  separately; say, in the context?
  Analogy: Service endpoint for each individual bank account or one
  (multiplexing) service location for all of Bank of America with account
  as an explicit parameter to the interface?  Both are extreme points on a
 General agreement on likelihood of coarse grained services that are
  parameterized to distinguish the bits.  Level the service actually
  breaks apart the URI is immaterial to the client.
  Some comments about recognizing what clearly lies in the client space
  and how to consolidate protocol for (say) various application servers.
  Should higher level application protocols govern the protocol?  How much
  of the key must be standardized and understood by every application
  Is it a problem that URI alone is defined to be opaque to the client?
  This was a complaint against one of the Corba mechanisms.
  Manner of doing reference creation invites same complaint?  Wish
  disciplines on how these references are created to avoid falling into
  that pit.  Do not leave everything to be implementation driven rather
  than protocol driven.  Make it explicit on platform creators that these
  references are not created under their control.
  WS-Addressing somewhat overspecified in implementation terms: Required
  to dispatch based on the content of the reference properties.
  WS-Context allows such a choice but also allows many other choices.
  WS-Context also identifies the specific type of context in the headers
  that arrive.
 Choices: include account number in application parameter (SOAP Body),
   include it (somehow) in the URL (opaque address) or place it somewhere
   in the header (WS-Addressing or WS-Context).  Design pattern is
   different in each of these cases.  How much about use of this parameter
   must the client and client application layer know in each case?
   Deft avoidance of "why web services are a poor choice to do RPC"
   WSRF encourages people to use opaque identification in circumstances
   where semantic (broadly understood) identification may be more
   appropriate; that is, it discourages distributed or shared understanding
   of the identifiers or algorithmic generation of the identifiers.  WSRF
   hinders automatic generation of the resource keys.  This may be a
   philisophical issue that is difficult to fix.
   Still have not had the conversation about distinguishing WS-Context from
   generic header(s) containing similar information.
   Generic question of requirement for demultiplexing headers also not
   completely answered.  Have not discussed overall model, just addressing

Jean-Jacques gives presentation on XRI and XDI:

- Slide presentation will be made available on Oasis site as a URL.

- XRI is basically an extension of URIs.  XRI is a URI scheme.
- Discussed the differences between XRIs and URIs.
- Martin asked how XRI is relevant to context
- Jean Jacques explained that when passing Context by reference, an XRI instead of a URI can be used.  XDI on the other hand can be used for updating the Context.
- Alistair asked whether XRI is currently being used.
- Concerns were raised as to what is the cost of using XRI.
- Both XRI and XDI have Oasis TCs.
- These specs have been around for about 10 years.
- The specs were found to be interested but their usefulness with regards to WS-Context or the WS-CAF spec in general was not fully determined.

Discussion of Peter Furnis' Email and Value of WS-Context:

presentation at http://www.oasis-open.org/apps/org/workgroup/ws-caf/download.php/5669/WS-CAF%20radical%20treatment.ppt

- Chair (Martin): This discussion should only occur once and tease out individual issues
- Peter Furnis delivered a presentation entitled “WS-Context radical treatment?”
- A discussion ensued 
- Question: Are generic contexts (application specific contexts) included in the assumptions of this presentation?  i.e. Context services aren't required to only accept a list of predefined context types.
- Answer:  Yes.
- Suggestion: drop the switching between pass-by-value and pass-by-reference.
- Passing by value can be useful for stuff like transactions, while pass-by-reference is useful for state storage.
- Currently the spec does not specify whether you can switch these two.
- Eric/Greg: Perhaps the spec needs to clearer on this.  Currently the spec is merely silent on this issue.
- Suggestion: drop pass-by-value from WS-CTX.  Passing by value is just repeating what is already in soap header.
- This slide sparked a lot of discussion.  Only some text from these discussions have been recorded.
- Eric: the option is available to facilitate ease of access to the entire context.
- Martin: passing the context by value keeps things standardized.
- Dale: the issue is that that notion is already provided by SOAP header.
- Eric: Does it break the spec to have the pass-by-value mode?  No.  So making the case for dropping it is moot in my opinion.
- Greg (to Dale/: pass-by-value may be useful for tree building as used by WS-Coordination.
- Dale: agrees.
- A suggestion was made that rather than having the TC convince Peter/Dale that WS-Context is useful, Peter/Dale should focus on showing how WS-Context is not.
- A lively debate ensued over this point (details have been omitted).
- Headers which are context headers are a benefit because they can be easily identifiable.  Similar to a base class.
- Dale: Context is useful in TBP (Tree Building Protocol).  Dale feels in the case of TBP ws-context is useful.
- Suggestion: Re-examine pass-by-reference.  It should work as a central-state-repository. The dereferencing mechanism should be specified preciely.  Creation and update mechanism should be outlined but protocol constructs should not be provided.
- Greg: What is the meaning of dereferencing a context refernce?  i.e. Does the uri represent a web service that can be used to get the context data or does it represent the location of the context data itself (ex. a url to context data).
- This is not clear in the specs.
- Discussion of mechanisms for updating the context...
- Updating the Context is out of band in the spec.
- Discussion of ALS registration.
- ALSs are registered with Context service (Activity Service) for augmenting contexts.
- Doug: What is the semantic difference between performing an ALS registration and adding a child, by-reference context that is maintained in another service.
- Eric: ALS tries to track the lifecycle of a context... i.e. which services are using this context over its lifetime.
- Martin: There is also augmenting of the context.
- Peter: no point in having ALS:CTX registration and interfaces.
- Peter: when the context service creates a context it knows what the ctx is being used for... it doesn't create a generic thingy that needs to be filled in.  Thus no need for an ALS.
- Greg: but the spec suggests that multiple ALSs can be registered to augment a context.
- Malik explained protocol registration in WS-CTX.
- Peter: How will the Activity merge the information/functionality provided by ALSs?  For example: A security ALS and a Transaction ALS have registered with a Context Service to provide secure transactions.  How for example will the activity service make sure that the security ALS gets called first or that the augmented context makes sense after both ALSs are called?
- This is not properly defined in the spec.
- Peter: If it is not fully defined in the spec, should it be defined at all?  Is there any point in completing it?
- Eric: Just because it's not fully defined doesn't mean it should be thrown away.
- Dale: agrees.
- The specs may need to address this.

Discussion points arising from this discussion session:
i. Absolute necessity of an “application” protocol governing the use/meaning of a context.
ii. Switching/Compoint usage hierarchy + relationships.
iii.  Tree building
iv. Must propagate flag.
v.  Facilitate interception.
vi. Mutation
vii. Context Service + HTTP utilization.
viii. ALS.

Alastair: Would be good to get clarity on Activity lifecycle; and on tree-building – different 
ways of building a tree.

Greg: there are 2 trees associated with an activity
      participant/registration tree
      activities in hierarchy, nesting
      there is a 1:1 relationship between activity and context
      or not (Eric) – hasn’t been finalized
Greg draws some diagrams

begin ->				begin+ctx ->
		ActSvc/CtxSve	<- begun +augmented ctx		ALS

Ctxsvc makes the context, passes to ALS, which augments context

Later, user may pass begin + existing context to CtxSvc which creates a new child ctx 
(unclear exactly what is passed to the ALS in this case)

Then, using addParticipant (from ws-cf), or equivalent, Participants register within a 
particular activity 

Question: does /should a context involve more than one ALS ?
	Spec not entirely clear (or assumes NO).

Simplifying assumption would be to say no: one context only involves a single ALS (and 
thus one using protocol)

Can there be more than one ALS for a single protocol ?

Question revived: is there/should there be a mechanism for more than one ALS 
augmenting a pcol.

What is an activity (or Activity). Is it a first-class citizen of ws-caf/ws-context ?	
Is it created by the begin (to ctx service)

Concepts to be sorted out:
	Activity Service
	Context Service
	Activity Lifecycle Service

Eric (in reply to question “what’s the Activity Service”): an extension of context service 
that could be merged back into it, including lifecycle mgt, context mgmt.

Martin starts a UML diagram

Webservice operation invocation  -- is associated with 0..N Activities

Webservice operation invocation is associated with 0..1 WS-Context contexts. 
(simplifying – in fact there can be multiple in hierarchic, related [or unrelated ?] 
relationship, but will be presented as one for now.

WS-Context context : Activity is 1:1

(do we want to have multiple contexts for the same Activity)

An Activity can be related to other Activities ( this is reflected in the corresponding 
Context’s, but we don’t show that)

Context is for a single activity, but is it 1 context : 1 activity ? or can there be synonyms 
(shadows, multiple representations)

Martin: If 1:1, then should drop one (and just have context)

Further discussion on whether an Activity is a concept that needs to defined and/or 
included in the ws-ctx spec.

Eric: activity references the execution environments

Martin draws another diagram – four web-service invocations in an activity, each labelled 
with context X. Can there be another invocation labeled with context FOO, which is part 
of the same activity.

Martin:  would like to see a diagram showing the concepts
	In the primer or the spec
	Ask the authors to produce such ?

ACTION: editors to draft a model diagram from which the normative specification is 

(See also issue 65)

For future consideration, after sorting out the concepts – 

	Diagram of different trees
	List of subjects/issues from this morning (repeated here)

1.	Absolute necessity of an “application protocol” governing the meaning of a 
context ?
2.	Switching/compound usage hierarchy and relationship
3.	Tree building
4.	Must propagate
5.	Facilitate interception
6.	Mutation
7.	Context service and HTTP utilization
8.	ALS

Implementation group:

Malik showed the plan as in 

Q: are we on schedule – deferred for tomorrow’s discussion

Group charter (included in some msg)
      Purpose is to show that WS-CAF implementations (will) exist 
      Intent is to have running code before our very eyes – this is not explicitly stated in 
group charter
What exactly is the target in terms of demonstration ? Possibilities:
	Workshop = we got it working in the lab last week
	Stage demo = look it works, on a particular day
	Continuing interoperation = standing access over the net between implems

Main charter says we will have a testing/interop program but doesn’t detail which of the 
Subgroup charter improved by adding “showing sample application implementations 

Charter document should NOT include the sample application description – will be 
moved to separate document as design document.
Deliverables list will continue to be in the charter.

(Note implementation group is a separate subgroup in OASIS, but kavi may not show it’s 
existence to non-members)

	Action: Peter whinge at OASIS staff to get subgroups shown to members of parent 
TC even if not member of subgroup.

Deliverables timetable follows the schedule of the specification documents (ctx first etc).  
Document names should follow current pattern: WS-CTX, WS-CF, WS-TXM. For each 
there will first be a description of the application, later the demonstrated 
implementations. Associated artifacts (e.g. WSDL) may be made publically available but 
there is no requirement to make source code available.

The subgroup charter will be put up for ballot by main group (strictly, a subgroup doesn’t 
need a charter, but it is helpful to them)

Action: Malik to update Impl team charter to reflect f2f discussion

Demo application

Martin resiles authorship of the draft

Greg: purpose of demo is to show interoperability and basic validation of spec, not to 
necessarily show best practice or range of functionality. Is this correct ?

Doug: there is marketing value in showing that it works

Martin: this plan is modeled on WS-RelMsg; occasional events. Not expecting the scale 
of WS-I.

Alastair: if this is ornamenting the existing WS-I app, could the involved companies 
make a beauteous version using WS-CAF

Martin: it is a question for us now as to how fancy to make this. (Oracle & Sun have WS-
I apps running, but Arjuna don’t, so they would have uneven starting points)

We are basing on the WS-I application, but this is not the same. It’s the WS-CAF demo 
application. IPR is ok if we don’t call it the WS-I application.

Simeon summarises:

Our demo take just the retailer from the ws-I sample app.

Each implementation will use the context service of another.

Propagated context is the shopping cart, being moved around between the stores – one of 
the issues is whether to propagate by value or by reference.
Alastair: if the updates to the shopping cart are not using the ctx mgmt service, then the 
demo will test the interoperation of the application implementations, not the ws-context 
implem. If each client calls its own context svc, passes the ctx by value, then the service 
adds to the ctx and (in the final case) fires its own checkout svc, there is isn’t any (or very 
much) ws-context demonstrated.,

Martin: yes, starting very basic.
Pass-by-reference will show more.

Involvement of which service
	Current draft does not expect to show ALS:CTX interoperation
	Will show application:ctx service (to get ctx)
	If checkout svc is ctx mgr using pass-by-reference the ctx mgr interfaces are 

Alastair: problem is that with checkout just being the printing of a collected list of things, 
it rather undercuts the claim of independent utility of ws-context – a genuine case of 
multi-merchant shopping cart is a coordination and transactional use-case.

Eric: this is a ref. implem to show that it works, rather than showing the utility of ws-
context as such.
Malik (& general) : it would be good to show the utility

Alastair: this is but a step on the way to the full demo of all layers which would show.

Greg: Newcastle GAF work might show the pure use of ws-context. Would be worth 
checking with them to see if that is a possible source.

Simeon took us through the scenarios:
	UC-1: 1 stores (doesn’t actually show any ws-ctx interop)
	UC-2: 2 stores (and thus does have ws-ctx)
	UC-3: 3 stores, and one of the items is the same from two stores
Doug: not clear if there is any more complex of ws-context use, just more complex 
application use between the cases. Doesn’t necessarily add to things for our purposes.

Are items identified by “manufacturer” or opaquely by the store ?

Alastair: if the additions made to the context are opaque (specific to the store), then ..

Does the shopping cart contain lists of globally-understood items, subdivided by supply 
store; or lineitems each of which is store-and-item.

Greg: cf. amazon current bookselling – allows purchases from other sellers.

Alastair: in doing a demo, as it goes through the stages, only change one thing at a time, 
or people will focus on the non-significant.

Alastair: main importance is to show ws-context interoperability – should work out which 
interfaces, and which operations of ws-context are exercised (rather than worrying too 
much about business model reality)



Martin: what's happened? Eric: not much; Add to agenda: WS-Transactions 
(and dependent specs) Workshop is March 10.

JJ: new ebXML architecture 
group; CAF may be new way to think about 
architecture for ebXML.
Dale: ebXML messaging may be relevant

OASIS Plenary

Doug: ebXML 2.0: eq. to reliability, manifest, security profile. 
EMEA/AsiaPac adoption. Canada, some US gov. White paper from TC about 
possible directions for ebms 3.0 (white paper available). ebms has some 
context like things, so interest exists in TC particularly in royalty 
free standards. Time frame: early requirements phase.
Dale: BPSS potential interest in coordination.
Action for chairs: request time with ebXML ebms in New Orleans.

WS-Transaction hosted by Microsoft, March 10.

Open discussion: Do we as a group want to send a rep? Individual 
companies are concerned with legal issues associated with participation. 

Action: chairs to draft statement on behalf of TC calling for industry 
to work together.


Meeting schedule:
    March 8 (F2Freview/votes)
    March 15 (model discussion)
    March 29 (impact assessment of model on specs)
    April 12 (continue on issues)

Editor action item on model description: March 8.

Editor call 11am EST: March 4.

Impact assessment of model for consideration in draft: March 25.

WS Context Draft by April 22.

Summary of actions:

Action: Eric post editorial issues for issues 12-20 

Action: Mark - Automatic update of bugzilla 

Action: Eric to contact WS-RF folks 

Action: chairs, Person responsible for updating resolutions in bugzilla to be identified

Action: chairs to determine if  bugzilla db backed up and if  access to account creation
restricted to WS-CAF members.

Action: Eric to updtae FAQ based on f2f comments

ACTION: editors to draft a model diagram from which the normative specification is 
derived. by March 8

Action: Malik to update Impl team charter to reflect f2f discussion

Action: chairs to draft statement on behalf of TC calling for industry 
to work together.

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