W3C home > Mailing lists > Public > public-ws-addressing@w3.org > July 2005

RE: LC 76 - What makes a msg WS-A?

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Mon, 18 Jul 2005 12:54:45 -0700
Message-ID: <2BA6015847F82645A9BB31C7F9D6416521491F@uspale20.pal.sap.corp>
To: "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, "Rogers, Tony" <Tony.Rogers@ca.com>
Cc: "Winkler, Steve" <steve.winkler@sap.com>, "Martin Gudgin" <mgudgin@microsoft.com>, "David Orchard" <dorchard@bea.com>, "David Hull" <dmh@tibco.com>, "Katy Warr" <katy_warr@uk.ibm.com>, <public-ws-addressing@w3.org>

After reading this thread for a while, I observe there is an
inconsistency that has been nagging me, which is not related to
generating Faults but ensuring the consistency of the consuming the
message that is regarded a WS-Addressing message. 

An endpoint may support but not mandate WS-Addressing. Engaging
WS-Addressing is indicated by the mU=1 on any header that is specified
by WS-Addressing. (There seems to me some disagreement about the level
of engagement as well in the wg). 

What happens in the following situation: 

Action mU=1, ReplyTo mU=1, FaultTo mU=0? 

There is clearly no problem here, but based on SOAP processing
semantics, I could conclude that FaultTo can safely be ignored. However,
clearly WS-Addressing is engaged, the headers are valid.   

Does the ultimate receiver have the luxury to ignore FaultTo? 

May the FaultTo address be utilized by the receiver in the example I
have given? Under which conditions can this happen at the ultimate
receiver? (provided that an intermediatery has not deleted it...) 

This is just an example. One can have a similar combination of valid
headers. It seems to me that Message Addressing headers should either
all be designated by mU=1 or mU=0, but not with a combination of mU=1
and mU=0. All Message Addressing Headers must be marked similarly to
designate that the addressing must be engaged, and all relevant ones
must be considered as a "bag". Some of them marked with 0 (vice versa)
does not provide a clean semantics with respect to what the client
intends to happen. 

I propose we require uniform treatment of the message addressing headers
with respect to mU, as a bag. 


--umit


 

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> Anish Karmarkar
> Sent: Friday, Jul 15, 2005 1:06 PM
> To: Rogers, Tony
> Cc: Winkler, Steve; Martin Gudgin; David Orchard; David Hull; 
> Katy Warr; public-ws-addressing@w3.org
> Subject: Re: LC 76 - What makes a msg WS-A?
> 
> 
> Rogers, Tony wrote:
> > I'm beginning to think that we regard a message as being 
> sent down the 
> > "this is a WS-A message" fork in the trail when it has an 
> Action header, 
> > or another WS-A header with mustUnderstand set to true. 
> Otherwise it 
> > goes down the "this is NOT a WS-A message" fork.
> >  
> > Agreed? Violently rejected?
> > 
> 
> I don't quite agree with the above formulation (the 'otherwise' part).
> The mU='1' simply states that the message must be processed as a WSA 
> message. If mU='0', it *may* still be processed as a WSA 
> message, if the 
> receiver chooses to do so. In which case the receiver has to 
> ensure that 
> all the WSA rules are adhered to. If not, then throw a fault.
> 
> -Anish
> --
> 
> > Tony
> > 
> >     -----Original Message-----
> >     *From:* public-ws-addressing-request@w3.org on behalf 
> of Winkler, Steve
> >     *Sent:* Fri 15-Jul-05 18:59
> >     *To:* Martin Gudgin; David Orchard; David Hull
> >     *Cc:* Katy Warr; public-ws-addressing@w3.org
> >     *Subject:* RE: LC 76 - What makes a msg WS-A?
> > 
> >      
> >     Hi Katy,
> >      
> >     Look what you started... ;-)
> >      
> >     In sifting through the mails, I've gathered that:
> >      
> >     If the client expects that WS-A machinery is to be 
> engaged on the
> >     endpoint to which they are sending, they need to 
> include at least
> >     one wsa:Header with a mustUnderstand attribute set to true.  The
> >     receiving side needs to check if any of the wsa:Header elements
> >     defined in the specification are present with the mU 
> attribute set
> >     to true, if so they need to process the message in 
> accordance with
> >     the WS-A spec (this includes faulting if wsa:Action is 
> not present,
> >     one reason why I wasn't happy with Gudge's original answer). 
> >      
> >     Now for some questions:
> >      
> >     Does this reflect an accurate understanding of the 
> discussion up to
> >     this point? 
> >     If so, Katy, does this satisfy your original question? 
> >     Is the group satisfied with this summary? 
> >     Should we state something like this explicitly in the spec?
> >      
> >      
> >     Cheers,
> >     Steve
> >      
> >      
> >     -------------------------
> >     Steve Winkler
> >     SAP AG
> >      
> > 
> >      
> > 
> >         
> --------------------------------------------------------------
> ----------
> >         *From:* public-ws-addressing-request@w3.org
> >         [mailto:public-ws-addressing-request@w3.org] *On Behalf Of
> >         *Martin Gudgin
> >         *Sent:* Thursday, Jul 14, 2005 3:08 PM
> >         *To:* David Orchard; David Hull
> >         *Cc:* Katy Warr; public-ws-addressing@w3.org
> >         *Subject:* RE: LC 76 - What makes a msg WS-A?
> > 
> >         I thought it was clear too. And it fits with the 
> SOAP processing
> >         model and so works for endpoints which were 
> deployed long before
> >         WS-A was a twinkle in the eye of it's multiple parents...
> >          
> >         Gudge
> > 
> >             
> --------------------------------------------------------------
> ----------
> >             *From:* David Orchard [mailto:dorchard@bea.com]
> >             *Sent:* 14 July 2005 22:32
> >             *To:* David Hull; Martin Gudgin
> >             *Cc:* Katy Warr; public-ws-addressing@w3.org
> >             *Subject:* RE: LC 76 - What makes a msg WS-A?
> > 
> >             I thought it was clear.  As soon as a single 
> ws-a header is
> >             marked with mU, then a fault will be thrown if 
> there are any
> >             missing headers like Action.  If there are no 
> headers marked
> >             with mU and there are missing headers, then 
> it's up to the
> >             receiver to decide whether to throw a fault or 
> ignore all
> >             the ws-a headers.
> > 
> >              
> > 
> >             Dave
> > 
> >              
> > 
> >              
> > 
> >             
> --------------------------------------------------------------
> ----------
> > 
> >             *From:* David Hull [mailto:dmh@tibco.com]
> >             *Sent:* Thursday, July 14, 2005 2:25 PM
> >             *To:* Martin Gudgin
> >             *Cc:* David Orchard; Katy Warr; 
> public-ws-addressing@w3.org
> >             *Subject:* Re: LC 76 - What makes a msg WS-A?
> > 
> >              
> > 
> >             Martin Gudgin wrote:
> > 
> >             +1
> > 
> >             Am I correct in reading that as "we should 
> throw a fault if
> >             there is a wsa:ReplyTo but no wsa:Action" and 
> we're back on
> >             the same page?  I hope so, but when you say 
> things like "I
> >             don't see why we want to mandate a fault in 
> such a case." it
> >             seems like you're saying that we shouldn't (or at least
> >             shouldn't feel obliged to) throw a fault in such cases.
> > 
> >             Perhaps you could enumerate with which combinations of
> >             headers a WSA-compliant endpoint should and should not
> >             produce a fault?  We can then check that 
> against the rules
> >             in section 3 and know whether we need to have 
> any further
> >             discussion.
> > 
> >              
> > 
> >             Gudge
> > 
> >                  
> > 
> >                 
> --------------------------------------------------------------
> ----------
> > 
> >                 *From:* David Orchard [mailto:dorchard@bea.com]
> >                 *Sent:* 14 July 2005 22:03
> >                 *To:* David Hull; Martin Gudgin
> >                 *Cc:* Katy Warr; public-ws-addressing@w3.org
> >                 <mailto:public-ws-addressing@w3.org>
> >                 *Subject:* RE: LC 76 - What makes a msg WS-A?
> > 
> >                 It seems to me that you can't pick and choose which
> >                 headers to support.  If there are any 
> insufficient ws-a
> >                 information (like contains a replyTo but no 
> Action) then
> >                 none of the ws-a processing can be invoked. 
>  It's not a
> >                 smorgasborg.
> > 
> >                  
> > 
> >                 Dave
> > 
> >                  
> > 
> >                 
> --------------------------------------------------------------
> ----------
> > 
> >                 *From:* public-ws-addressing-request@w3.org
> >                 <mailto:public-ws-addressing-request@w3.org>
> >                 
> [mailto:public-ws-addressing-request@w3.org] *On Behalf
> >                 Of *David Hull
> >                 *Sent:* Thursday, July 14, 2005 1:41 PM
> >                 *To:* Martin Gudgin
> >                 *Cc:* Katy Warr; public-ws-addressing@w3.org
> >                 <mailto:public-ws-addressing@w3.org>
> >                 *Subject:* Re: LC 76 - What makes a msg WS-A?
> > 
> >                  
> > 
> >                 Martin Gudgin wrote:
> > 
> >                 I agree with your analysis of the three 
> steps. I don't
> >                 see why we want to mandate a fault in such 
> a case. The
> >                 client gets to decide whether he wants a 
> fault or not
> >                 based on whether he marks the header 
> mU='true' or not...
> > 
> >                 What would happen to the [reply endpoint] 
> in this case
> >                 (or rather, these cases, as mU may be true or not)? 
> >                 Would it be used as a reply address?  Would it be
> >                 silently ignored? Something else?
> > 
> >                 In the first case, it seems strange to 
> follow WSA rules
> >                 but not complain about a missing mandatory 
> header.  In
> >                 the second case, it seems less than robust 
> to silently
> >                 ignore a field that would otherwise have a 
> significant
> >                 effect on processing.
> > 
> >                 Not sure about the third case.
> > 
> > 
> >                  
> > 
> >                 Gudge
> > 
> >                      
> > 
> >                     
> --------------------------------------------------------------
> ----------
> > 
> >                     *From:* David Hull [mailto:dmh@tibco.com]
> >                     *Sent:* 14 July 2005 21:21
> >                     *To:* Martin Gudgin
> >                     *Cc:* Katy Warr; public-ws-addressing@w3.org
> >                     <mailto:public-ws-addressing@w3.org>
> >                     *Subject:* Re: LC 76 - What makes a msg WS-A?
> > 
> >                     Martin Gudgin wrote:
> > 
> >                     Well, one could argue that the endpoint 
> that accepts
> >                     WS-A messages and the one that accepts non-WS-A
> >                     message are not actually the same 
> endpoint despite
> >                     the fact that they're listening on the 
> same URI, I
> >                     suppose...
> > 
> >                     Sure, but the multiplexing still has to 
> be done one
> >                     way or another.
> > 
> > 
> >                      
> > 
> >                     I'm still not seeing why the endpoint 
> can't use the
> >                     following sequence of steps;
> > 
> >                      
> > 
> >                     1.    Does the message contain a 
> wsa:Action header?
> > 
> >                     2.    If the answer to question 1. is 'Yes' then
> >                     look for other wsa: * headers and 
> populate abstract
> >                     properties as appropriate.
> > 
> >                     3.    If the answer to question 1 is 'No' then
> >                     process the message using normal SOAP rules
> >                     (including raising mU faults if there 
> are any other
> >                     wsa:* headers marked mU='true' )
> > 
> >                     That will not produce a fault if a 
> message contains
> >                     an explicit wsa:ReplyTo (with no mU) but no
> >                     wsa:Action, right?  The test in step 1 
> fails and we
> >                     go straight to step 3.  So it's OK iff 
> we don't want
> >                     a fault in such a case.  My 
> understanding is we /do/
> >                     want a fault in such a case.
> > 
> > 
> >                      
> > 
> >                     Gudge
> > 
> >                          
> > 
> >                         
> --------------------------------------------------------------
> ----------
> > 
> >                         *From:* David Hull [mailto:dmh@tibco.com]
> >                         *Sent:* 14 July 2005 20:58
> >                         *To:* Martin Gudgin
> >                         *Cc:* Katy Warr; public-ws-addressing@w3.org
> >                         <mailto:public-ws-addressing@w3.org>
> >                         *Subject:* Re: LC 76 - What makes a 
> msg WS-A?
> > 
> >                         Martin Gudgin wrote:
> > 
> >                         Why is it a problem if a message 
> which doesn't
> >                         have wsa:Action in it is NOT subject to
> >                         'validation' (what does that mean, 
> BTW) by the
> >                         receiver?
> > 
> >                         Yeah, I'm not comfortable with the 
> terminology
> >                         either.
> > 
> >                         The question is, should a WSA compliant
> >                         /endpoint/ throw a fault if it gets 
> a message
> >                         with (say) a [reply endpoint] and 
> no [action]?
> > 
> >                         If I understand right, you're saying that
> >                         (straightforwardly), it should.  That's
> >                         certainly how I'd interpret the 
> current core.
> > 
> >                         Section 3 (specifically section 
> 3.1) says that
> >                         [action] is required (i.e., its 
> cardinality is
> >                         (1..1)), so the only question (and the one I
> >                         think Katy was asking) is, when 
> does section 3
> >                         apply?
> > 
> >                         There appears to be consensus that endpoints
> >                         should be able to accept both old-style and
> >                         new-style requests without problem. 
>  This means
> >                         that such an endpoint must be 
> prepared to accept
> >                         messages with no wsa: headers at 
> all -- contrary
> >                         to as strict reading of section 3.  In
> >                         particular, such an endpoint should 
> /not/ fault
> >                         if wsa:Action is absent unless other wsa:
> >                         headers are present.  In such a 
> case, section 3
> >                         does not apply universally, and we 
> want to be
> >                         able to say when it does and doesn't apply.
> > 
> >                         So what's the best way to say this? 
>  We can't
> >                         use abstract properties, since they may be
> >                         defined even if there are no wsa: 
> headers in the
> >                         incoming message.  So we have to look at the
> >                         incoming infoset.  In short, an 
> endpoint capable
> >                         of handling both styles should apply the
> >                         constraints in section 3 if the 
> incoming SOAP
> >                         message contains any wsa: headers, 
> and should
> >                         follow the pre-WSA behavior 
> otherwise.  This is
> >                         fine as long as the underlying 
> transport binding
> >                         doesn't synthesize wsa: headers that aren't
> >                         explicitly there.  Otherwise, we'd need some
> >                         other way of figuring out if the 
> sender meant to
> >                         use WSA.
> > 
> >                         Does that make more sense?  I 
> believe this is a
> >                         long-standing and thoroughly 
> discussed issue. 
> >                         If you were thinking of something 
> else, let's
> >                         sort that out first.
> > 
> > 
> > 
> >                         Gudge
> > 
> >                              
> > 
> >                             
> --------------------------------------------------------------
> ----------
> > 
> >                             *From:* David Hull 
> [mailto:dmh@tibco.com]
> >                             *Sent:* 14 July 2005 20:29
> >                             *To:* Martin Gudgin
> >                             *Cc:* Katy Warr; 
> public-ws-addressing@w3.org
> >                             <mailto:public-ws-addressing@w3.org>
> >                             *Subject:* Re: LC 76 - What 
> makes a msg WS-A?
> > 
> >                             Martin Gudgin wrote:
> > 
> >                             OK, I'm confused.
> > 
> >                              
> > 
> >                             Why do you conclude that the 
> answer to my
> >                             question "Given that the 
> wsa:Action header
> >                             is mandatory, isn't it the 
> presence of that
> >                             header?" is 'No'.
> > 
> >                              
> > 
> >                             I would have come to the 
> opposite conclusion;
> > 
> >                              
> > 
> >                             I have an endpoint that understands
> >                             WS-Addressing. It receives a 
> message that
> >                             contains wsa:ReplyTo but no 
> wsa:Action. It
> >                             generates a fault. Seems pretty
> >                             straightforward to me.
> > 
> >                             Sure.  That is a perfectly 
> straightforward
> >                             rule.  In fact, it's implied by 
> what we say
> >                             in section 3.3.
> > 
> >                             I thought you were trying to answer the
> >                             question "When is an incoming 
> message deemed
> >                             to be a WS-Addressing message 
> and therefore
> >                             subject to the appropriate WS-Addressing
> >                             validation?" with (rephrasing 
> the reply as a
> >                             statement) "It's subject to WSA 
> validation
> >                             if the wsa:Action header is 
> present."  And
> >                             of course, this clearly won't 
> work, since it
> >                             specifically doesn't try to validate a
> >                             message with wsa:ReplyTo and no 
> wsa:Action.
> > 
> >                             If you meant something else, then never
> >                             mind.  It's probably not worth sorting.
> > 
> > 
> >                              
> > 
> >                             I have an endpoint that doesn't 
> understand
> >                             WS-Addressing. It receives a 
> message that
> >                             contains one or more wsa: 
> headers, it either
> >                             ignores them or generates a 
> mustUnderstand
> >                             fault depending on whether 
> those headers are
> >                             marked mustUnderstand='true' or 
> not. Again,
> >                             seems pretty straightforward to me.
> > 
> >                             Sure.  As I said, we're talking about
> >                             behavior of endpoints, not properties of
> >                             messages.
> > 
> >                             As DaveO says, the interesting 
> case is that
> >                             of an endpoint that wants to 
> accept non-WSA
> >                             messages without complaint but 
> also handle
> >                             WSA messages properly.
> > 
> > 
> >                              
> > 
> >                             Gudge
> > 
> >                                  
> > 
> >                                 
> --------------------------------------------------------------
> ----------
> > 
> >                                 *From:* David Hull 
> [mailto:dmh@tibco.com]
> >                                 *Sent:* 14 July 2005 18:02
> >                                 *To:* Martin Gudgin
> >                                 *Cc:* Katy Warr;
> >                                 public-ws-addressing@w3.org
> >                                 <mailto:public-ws-addressing@w3.org>
> >                                 *Subject:* Re: LC 76 - What 
> makes a msg
> >                                 WS-A?
> > 
> >                                 Martin Gudgin wrote:
> > 
> >                                  
> > 
> >                                      
> > 
> >                                     
> --------------------------------------------------------------
> ----------
> > 
> >                                     *From:* David Hull
> >                                     [mailto:dmh@tibco.com]
> >                                     *Sent:* 14 July 2005 16:32
> >                                     *To:* Martin Gudgin
> >                                     *Cc:* Katy Warr;
> >                                     public-ws-addressing@w3.org
> >                                     
> <mailto:public-ws-addressing@w3.org>
> >                                     *Subject:* Re: LC 76 - 
> What makes a
> >                                     msg WS-A?
> > 
> >                                     Is this really a 
> question of how to
> >                                     support both WSA and 
> old-style HTTP
> >                                     requests on the same endpoint?  
> >                                     [MJG] I don't know, I 
> didn't ask the
> >                                     original question.
> > 
> >                                 Hmm ... my message was in-reply-to
> >                                 yours, but the question was 
> really aimed
> >                                 more at Katy.  Maybe we 
> need BPEL here :-).
> > 
> > 
> > 
> >                                       I.e., if I don't see any WSA
> >                                     headers at all, I assume it's an
> >                                     old-style request and act
> >                                     accordingly, but if I 
> see anything
> >                                     WSA, I follow the rules 
> in section 3? 
> >                                     [MJG] I guess one could 
> do that...
> > 
> >                                 Well, one should do /something/ to
> >                                 ensure that old-style requests are
> >                                 accepted as such.
> > 
> > 
> > 
> >                                     The tricky bit is that, 
> since MAPs
> >                                     like [destination] and [reply
> >                                     endpoint] can default, a message
> >                                     with no wsa: elements 
> on the wire
> >                                     could still be assigned 
> values for
> >                                     some of its MAPs, since the
> >                                     /infoset/ will still 
> have values for
> >                                     the corresponding elements. 
> > 
> >                                     [MJG] Which Infoset are 
> you talking
> >                                     about? The XML Infoset 
> has no such
> >                                     values.
> > 
> >                                 Sorry, I didn't get that 
> quite right.  I
> >                                 was going by section 3.2, 
> particularly
> >                                 the descriptions of wsa:To:
> > 
> >                                 This OPTIONAL element 
> (whose content is
> >                                 of type xs:anyURI) provides 
> the value
> >                                 for the [destination] 
> property. If this
> >                                 element is NOT present then 
> the value of
> >                                 the [destination] property is
> >                                 
> "http://www.w3.org/@@@@/@@/addressing/anonymous"
> >                                 
> <http://www.w3.org/@@@@/@@/addressing/anonymous>.
> > 
> > 
> >                                 (and similarly for wsa:ReplyTo). I
> >                                 initially misread this as 
> stating that
> >                                 the element defaulted, as 
> opposed to the
> >                                 MAP.  So s/since the /infoset/ will
> >                                 still have values for the 
> corresponding
> >                                 elements/since the properties are
> >                                 defaulted in the absence of the
> >                                 corresponding elements in 
> the infoset/. 
> >                                 This sort of confusion 
> could be seen as
> >                                 an argument against the two-layered
> >                                 approach (or simply as an 
> argument that
> >                                 I read too quickly).
> > 
> >                                 In any case, you can't 
> simply look at
> >                                 the abstract properties and 
> say "some
> >                                 WSA properties are defined, 
> so it's a
> >                                 WSA message".
> > 
> > 
> > 
> >                                        So either we have to 
> drop down to
> >                                     look at the infoset 
> level, and in
> >                                     particular at the non-defaulted
> >                                     elements in the 
> infoset, or we have
> >                                     to find some marker 
> that can't be
> >                                     defaulted away.  This is why the
> >                                     [action] property looks 
> significant
> >                                     here.  But on the other 
> hand, what
> >                                     if I include a 
> wsa:ReplyTo element
> >                                     and no action?  By the 
> "it's WSA iff
> >                                     [action] is present" 
> rule, that's
> >                                     not a WSA message and 
> therefore not
> >                                     an error.  This seems wrong. 
> >                                     [MJG] Why does it seem wrong?
> > 
> >                                 It seems wrong not to fault for a
> >                                 message that contains a 
> wsa:ReplyTo on
> >                                 the wire but not a wsa:Action.
> > 
> > 
> > 
> >                                     Put another way, when 
> would one get
> >                                     a fault for omitting [action]? 
> >                                     [MJG] Whenever another wsa:
> >                                     header is present in a message.
> > 
> >                                 In other words, the answer to your
> >                                 question ("Given that the 
> wsa:Action is
> >                                 mandatory, isn't it the 
> presence of that
> >                                 header?") is "No."
> > 
> >                                 This is why at the Berlin meeting we
> >                                 tried to make sure that all the
> >                                 possibilities were covered 
> for various
> >                                 combinations of the MAPs.  I believe
> >                                 we've satisfied ourselves 
> that they are,
> >                                 but perhaps we need to 
> revisit this work?
> > 
> > 
> > 
> > 
> >                                     Martin Gudgin wrote:
> > 
> >>                                     Given that the wsa:Action is
> >>                                     mandatory, isn't it 
> the presence
> >>                                     of that header?
> >>
> >>                                      
> >>
> >>                                     Gudge
> >>
> >>                                          
> >>
> >>                                         
> --------------------------------------------------------------
> ----------
> >>
> >>                                         *From:*
> >>                                         
> public-ws-addressing-request@w3.org
> >>                                         
> <mailto:public-ws-addressing-request@w3.org>
> >>                                         
> [mailto:public-ws-addressing-request@w3.org]
> >>                                         *On Behalf Of *Katy Warr
> >>                                         *Sent:* 14 July 2005 16:07
> >>                                         *To:*
> >>                                         public-ws-addressing@w3.org
> >>                                         
> <mailto:public-ws-addressing@w3.org>
> >>                                         *Subject:* LC 76 - 
> What makes
> >>                                         a msg WS-A?
> >>
> >>
> >>                                         Please could we discuss the
> >>                                         following in the 
> context of LC76?
> >>
> >>                                         When is an incoming message
> >>                                         deemed to be a 
> WS-Addressing
> >>                                         message and 
> therefore subject
> >>                                         to the appropriate
> >>                                         WS-Addressing 
> validation?   Is
> >>                                         it based on the presence of
> >>                                         any WS-addressing Message
> >>                                         Addressing Property?  For
> >>                                         example, does a message
> >>                                         containing a reference
> >>                                         parameter (but no other
> >>                                         WS-Addressing information)
> >>                                         need to result in a
> >>                                         
> MessageAddressingHeaderRequired?
> >>                                            Or, for 
> example, does the
> >>                                         declaration of the wsa
> >>                                         namespace rendor 
> the message
> >>                                         WS-Addressing?
> >>
> >>                                         Thanks
> >>                                         Katy
> >>
> >                                      
> > 
> >                                  
> > 
> >                              
> > 
> >                          
> > 
> >                      
> > 
> >                  
> > 
> >              
> > 
> 
> 
Received on Monday, 18 July 2005 19:54:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:06 GMT