Re: Are nested assertions part of the policy vocabulary?

regarding the compatability of an empty ws addressing assertion and one 
which has the nested policy assertion present, I would like to
add a clarificiaton. It is ok that the empty ws addressing assertion 
will not intersect with a ws addressing assertion with the anonymous
nested assertion. The anonymous nested assertion implies that only 
anonymous replies can be sent from the server endpoint making the assertion.

If a server expresses that it can only send anonymous responses, that 
would be incompatible with a client who needs to request that some of 
its responses need to be send non anonymous (a client which specifies 
only an empty addressing assertion implies it needs to be able to 
request both types of responses).

With regards to scalablity concerns, ws addressing has only two mutually 
exclusive types of responses. That is why the scalability is not
an issue for this alternative G solution for ws addressing metadata.

Tom Rutt

Katy Warr wrote:
>
> Ashok
>
> As Ram states - we agreed on solution G.
>
> In order to express full WS-Addressing support (and intersection with 
> all WS-Addressing clients), a service provider would need to specify:
> <policy>
> <wsam:UsingAddressing>
> <policy/>
> </wsam:UsingAddressing>
> </policy>
> <policy>
> <wsam:UsingAddressing>
> <policy>
> <wsam:AnonymousResponses>
> </policy>
> </wsam:UsingAddressing>
> </policy
> <policy>
> <wsam:UsingAddressing>
> <policy>
> <wsam:NonAnonymousResponses>
> </policy>
> </wsam:UsingAddressing>
> </policy>
> As you say, the empty assertion allows for replyTo=anon and faultTo= 
> nonAnon (or vice-versa) in a single message.
>
> Best regards
> Katy
>
>
>
> *Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>*
> Sent by: public-ws-addressing-request@w3.org
>
> 09/05/2007 04:09
>
> 	
> To
> 	Ashok Malhotra <ashok.malhotra@oracle.com>
> cc
> 	"public-ws-addressing@w3.org" <public-ws-addressing@w3.org>, 
> "public-ws-policy@w3.org" <public-ws-policy@w3.org>, Daniel Roth 
> <Daniel.Roth@microsoft.com>, Sergey Beryozkin 
> <sergey.beryozkin@iona.com>, Bob Freund <bob@freunds.com>, Maryann 
> Hondo <mhondo@us.ibm.com>, Anthony Nadalin <drsecure@us.ibm.com>
> Subject
> 	RE: Are nested assertions part of the policy vocabulary?
>
>
>
> 	
>
>
>
>
>
> Ashok,
>
> > but this seems to be the behavior that WS-Addressing folks want.
>
> I believe the WS-Addressing WG agreed that proposal G satisfies the 
> WS-Addressing use case sufficiently during the penultimate WG call 
> [1][2]. Currently, the WS-Addressing WG is just waiting for feedback 
> [3] from the WS-Policy WG, before entering the Last Call stage.
>
> Section 3.1.6 [4] of the WS-Addressing specification provides guidance 
> [5] on policy intersection and sufficiently warns the consumer to 
> carefully craft its policy alternatives so as to increase its chances 
> of being compatible. So, a policy consumer should be able to 
> successfully intersect as long as it is careful about maximizing its 
> chances of intersection by following the guidance [4].
>
> Thank you.
>
> [1] _http://www.w3.org/2002/ws/addr/7/04/23-ws-addressing-minutes.html_
> [2] _http://www.w3.org/2002/ws/addr/7/04/02-ws-addressing-minutes.html_
> [3] 
> _http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/0094.html_
> [4] 
> _http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html?content-type=text/html;%20charset=utf-8#usingintersection_ 
> <http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-wsdl..html?content-type=text/html;%20charset=utf-8#usingintersection> 
>
> [5] “The policy used by the client must be written carefully to avoid 
> unexpected results.”
>
> *From:* public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] *On Behalf Of *Ashok 
> Malhotra*
> Sent:* Tuesday, May 08, 2007 2:30 PM*
> To:* Daniel Roth; Sergey Beryozkin; Bob Freund; Maryann Hondo; Anthony 
> Nadalin*
> Cc:* public-ws-addressing@w3.org; public-ws-policy@w3.org*
> Subject:* RE: Are nested assertions part of the policy vocabulary?
>
> Hi Dan:
> You made a very important point that I want to highlight. You said:
> “In some cases a single message may specify both an anonymous ReplyTo 
> EPR and a non-anonymous FaultsTo EPR. To satisfy this scenario you 
> need to have some way of saying that addressing is fully supported 
> without qualifications.”
>
> By your final sentence I presume you are saying that
>
> <policy>
> <wsp:Addressing>
> <policy/>
> </wsp:Addressing>
> </policy>
>
> means that addressing is fully supported without qualifications. Is 
> this correct? If so, then the above policy should intersect 
> successfully with, for example:
>
> <policy>
> <wsp:Addressing>
> <policy>
> <wsp:AnonymousReplies/>
> <policy/>
> </wsp:Addressing>
> </policy>
>
> Do you agree? We understand that this is not what the spec says but 
> this seems to be the behavior that WS-Addressing folks want.
>
> All the best, Ashok
>
>
> ------------------------------------------------------------------------
>
> *From:* public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] *On Behalf Of *Daniel Roth*
> Sent:* Tuesday, May 08, 2007 1:26 PM*
> To:* Sergey Beryozkin; Bob Freund; Ashok Malhotra; Maryann Hondo; 
> Anthony Nadalin*
> Cc:* public-ws-addressing@w3.org; public-ws-policy@w3.org*
> Subject:* RE: Are nested assertions part of the policy vocabulary?
>
> Hi Sergey,
>
> > According to [1] If the provider uses <Policy/> then it means this 
> provider will work with consumers using either anonymous or 
> non-anonymous WSA qualifications.
> > And yet, the requester saying, by using 
> <ws-addressing><Policy><AnonymousResponses/></Policy></ws-addressing>, 
> that it wishes a provider to support
> > <AnonymousResponses/> will fail to intersect with the provider using 
> <Policy/> which says that all types of responses are supported
>
> A client that requires a service that supports anonymous responses 
> will work with a service that supports all of addressing or just 
> anonymous responses. This means, the client should reflect that by 
> including both alternatives in its policy. The client policy with both 
> alternatives intersects with the service policy and is specifically 
> recommended in section 3.6.1 of the WS-Addressing Metadata spec.
>
> > I'd even say that the empty nested ws-adressing <Policy> should be 
> prohibited
>
> In some cases a single message may specify both an anonymous ReplyTo 
> EPR and a non-anonymous FaultsTo EPR. To satisfy this scenario you 
> need to have some way of saying that addressing is fully supported 
> without qualifications.
>
> I hope this helps.
>
> Daniel Roth
>
>
> *From:* Sergey Beryozkin [mailto:sergey.beryozkin@iona.com] *
> Sent:* Tuesday, May 08, 2007 2:25 AM*
> To:* Bob Freund; Daniel Roth; Ashok Malhotra; Maryann Hondo; Anthony 
> Nadalin*
> Cc:* public-ws-addressing@w3.org; public-ws-addressing-request@w3.org; 
> public-ws-policy@w3.org; public-ws-policy-request@w3.org*
> Subject:* Re: Are nested assertions part of the policy vocabulary?
>
> Hi
>
> What confuses me is that it appears to be some inconsistency in the 
> definition of what the empty nested Policy means in the scope of 
> ws-addressing (see [1]), <ws-addressing><Policy/></ws-addressing> and 
> the fact that this nested <Policy> does not intersect with a more 
> qualified nested Policy such as 
> <ws-addressing><Policy><AnonymousResponses/></Policy></ws-addressing>.
>
> According to [1] If the provider uses <Policy/> then it means this 
> provider will work with consumers using either anonymous or 
> non-anonymous WSA qualifications. And yet, the requester saying, by 
> using 
> <ws-addressing><Policy><AnonymousResponses/></Policy></ws-addressing>, 
> that it wishes a provider to support <AnonymousResponses/> will fail 
> to intersect with the provider using <Policy/> which says that all 
> types of responses are supported...
>
> I think what this means is using an all inclusive <Policy> alternative 
> alone on the server is just not safe as it will cause compliant 
> clients (say those wishing a provider to support 
> <AnonymousResponses/>) to break...I'd even say that the empty nested 
> ws-adressing <Policy> should be prohibited...Just have two nested 
> policies, one allowing anonymous responses, another one allowing 
> non-anonymous ones...That way a provider supporting all types of 
> responses can list two alternatives and it will match all clients....
>
>
> Thanks, Sergey
>
> [1] 
> _http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/att-0094/WSAddrPolicyAlgerntiveGprime.htm_ 
>
> ----- Original Message -----
> *From:* _Bob Freund_ <mailto:bob@freunds.com>
> *To:* _Daniel Roth_ <mailto:Daniel.Roth@microsoft.com> ; _Ashok 
> Malhotra_ <mailto:ashok.malhotra@oracle.com> ; _Maryann Hondo_ 
> <mailto:mhondo@us.ibm.com> ; _Anthony Nadalin_ 
> <mailto:drsecure@us.ibm.com>
> *Cc:* _public-ws-addressing@w3.org_ 
> <mailto:public-ws-addressing@w3.org> ; 
> _public-ws-addressing-request@w3.org_ 
> <mailto:public-ws-addressing-request@w3.org> ; 
> _public-ws-policy@w3.org_ <mailto:public-ws-policy@w3.org> ; 
> _public-ws-policy-request@w3.org_ 
> <mailto:public-ws-policy-request@w3.org>
> *Sent:* Tuesday, May 08, 2007 12:22 AM
> *Subject:* RE: Are nested assertions part of the policy vocabulary?
>
> +1
> From a plain reading of the WS-Policy intersection algorithm, these 
> policies indeed are not compatible per the WS-Policy 1.5 framework CR 
> spec.
> -bob
>
> *From:* _public-ws-addressing-request@w3.org_ 
> <mailto:public-ws-addressing-request@w3.org> 
> [mailto:public-ws-addressing-request@w3.org] *On Behalf Of *Daniel Roth*
> Sent:* Tuesday, May 01, 2007 4:52 PM*
> To:* Ashok Malhotra; Maryann Hondo; Anthony Nadalin*
> Cc:* _public-ws-addressing@w3.org_ 
> <mailto:public-ws-addressing@w3.org>; 
> _public-ws-addressing-request@w3.org_ 
> <mailto:public-ws-addressing-request@w3.org>; 
> _public-ws-policy@w3.org_ <mailto:public-ws-policy@w3.org>; 
> _public-ws-policy-request@w3..org_ 
> <mailto:public-ws-policy-request@w3.org>*
> Subject:* RE: Are nested assertions part of the policy vocabulary?
>
> Hi Ashok,
>
> These two policies do not intersect and we believe this is verified in 
> the test cases. If Policy 2 is the policy for a requester then this 
> intersection result may at first seem incorrect, so let me explain:
>
> It is incumbent on the Addressing authors to specify the semantics of 
> the assertions. The Addressing assertion expresses a requirement that 
> WS-Addressing be used to exchange messages without qualifications. The 
> nested addressing assertions (which indicate additional 
> characteristics of the base WS-Addressing assertion) qualify this 
> semantic to say that either only non-anonymous responses are supported 
> or that only anonymous responses are supported. In the WS-Addressing 
> protocol it’s the requester’s message that requests a specific kind of 
> response – anonymous, non-anonymous, or maybe even a mixture of the two.
>
> The thing to recognize is that if Policy 2 is a requester policy then 
> it is incomplete in that it is not acknowledging that the base 
> assertion also reflects support for anonymous responses. The requester 
> determines what response type should be used. So, a client that needs 
> non-anonymous responses will also work with a service that supports 
> all of addressing. The client’s policy should reflect that it is 
> compatible with an endpoint that supports all of addressing by adding 
> a second alternative. This can be easily done using the Optional 
> attribute as is shown in section 3.1.6 in the WS-Addressing Metadata 
> spec:
> <Policy><Addressing ><Policy><AnonymousResponses wsp:Optional=”true” > 
> </Policy></Addressing ></Policy>
>
> Note that if Policy 2 is a provider policy and Policy 1 is the 
> requester policy – where the requester wants unqualified support for 
> addressing, but the provider only supports a specific response type – 
> then there is no issue. These policies should not intersect and they 
> don’t.
>
> We hope this helps.
>
> Daniel Roth
>
> *From:* public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Ashok Malhotra*
> Sent:* Thursday, April 19, 2007 12:33 PM*
> To:* Maryann Hondo; Anthony Nadalin*
> Cc:* public-ws-addressing@w3.org; public-ws-addressing-request@w3.org; 
> public-ws-policy@w3.org; public-ws-policy-request@w3.org*
> Subject:* RE: Are nested assertions part of the policy vocabulary?
>
> Hi Maryann:
> Perhaps I misunderstood. Let me rephrase my comments as questions.
>
> Since Policy 1
> <Policy>
> <ws-addressing>
> <Policy/>
> </ws-addressing>
> </Policy>
> was intended to mean that ALL options ( anonymous, non-anonymous) are 
> supported.
>
> And Policy 2
> <Policy>
> <ws-addressing>
> <Policy>
> <ws-addressing: Anonymous>
> </Policy>
> </ws-addressing>
> </Policy>
> was intended to mean that ONLY anonymous was supported.
> Should Policy 1 match Policy 2 in the intersection algorithm?
>
> All the best, Ashok
>
>
> ------------------------------------------------------------------------
>
> *From:* public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3..org] *On Behalf Of *Maryann 
> Hondo*
> Sent:* Thursday, April 19, 2007 5:55 AM*
> To:* Ashok Malhotra; Anthony Nadalin*
> Cc:* Ashok Malhotra; public-ws-addressing@w3.org; 
> public-ws-addressing-request@w3.org; public-ws-policy@w3.org; 
> public-ws-policy-request@w3.org*
> Subject:* RE: Are nested assertions part of the policy vocabulary?
>
>
> Ashok,
> I would like to clarify my comments.
>
> I was trying to say, that the WS-Addressing group seemed to be trying 
> to use nested assertions to indicate a "constraint".
> My understanding of the semantics are the following:
> <Policy>
> <ws-addressing>
> <Policy/>
> </ws-addressing>
> </Policy>
> was intended to mean that ALL options ( anonymous, non-anonymous) are 
> supported.
>
> and
> <Policy>
> <ws-addressing>
> <Policy>
> <ws-addressing: Anonymous>
> </Policy>
> </ws-addressing>
> </Policy>
> was intended to mean that ONLY anonymous was supported.
>
> This to me, ths meant that the "intent" of the base assertion was 
> being "constrained" by the presence off a nested assertion
> and that was ok if the working group understood the semantics they 
> were expressing ( i.e. the "absence" of a nested assertion
> means "no constraints" or "all options are supported")
>
> and I thought the language of the ws-policy spec allowed this 
> interpretation since a nested assertion could be seen to be
> qualifying the base assertion with a constraint rather than a capability.
>
> Authors MAY define that an assertion contains a _policy expression_ 
> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_expression> 
> (as defined in *_4. Policy Expression_* 
> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#rPolicy_Expression>) 
> as one of its *[children]*. _Nested policy expression(s)_ 
> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#nested_policy_expression> 
> are used by authors to further qualify one or more specific aspects of 
> the original assertion.
>
>
> The spec already says the following so I don't think alternative 1 
> really adds anything, unless I'm missing something, like Tony, I need 
> more of an explanation of what you are suggesting you want the 
> intersection to do:
>
> Because the set of behaviors indicated by a _policy alternative_ 
> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_alternative> 
> depends on the domain-specific semantics of the collected assertions, 
> determining whether two policy alternatives are compatible generally 
> involves domain-specific processing.
>
> Maryann
>
> *Anthony Nadalin/Austin/IBM@IBMUS*
> Sent by: public-ws-addressing-request@w3.org
>
> 04/19/2007 03:41 AM
>
> 	
> To
> 	"Ashok Malhotra" <ashok.malhotra@oracle.com>
> cc
> 	"public-ws-addressing@w3.org" <public-ws-addressing@w3.org>, 
> "public-ws-policy@w3.org" <public-ws-policy@w3.org>, 
> public-ws-policy-request@w3.org
> Subject
> 	RE: Are nested assertions part of the policy vocabulary?
>
>
>
> 	
>
>
>
>
>
>
> #1 " dependent on the semantics of the parent assertion." not sure 
> what this would mean can you give some guidance here ?
> #2 is real dangerous as you have no idea what you are matching on, one 
> day it could be XYZ and another day it could be ABC.
>
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> Inactive hide details for "Ashok Malhotra" 
> <ashok.malhotra@oracle.com>"Ashok Malhotra" <ashok.malhotra@oracle.com>
>
> *"Ashok Malhotra" <ashok.malhotra@oracle.com>*
> Sent by: public-ws-policy-request@w3.org
>
> 04/16/2007 04:23 PM
>
> 	
>
>
>
>
> To
> 	
> "public-ws-policy@w3.org" <public-ws-policy@w3.org>, 
> "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
>
>
> cc
> 	
>
>
> Subject
> 	
> RE: Are nested assertions part of the policy vocabulary?
>
>
>
> 	
>
>
>
>
>
> I’m at the OASIS Symposium and have had extensive discussions with the 
> WS-Addressing folks re. the problems they are having in using 
> WS-Policy to express their requirements.
>
> As I see it, the sticky usecase is where the provider wants to say 
> this it supports WS-Addressing in all its manifestations and the 
> requester specifies that it supports a particular variation of 
> WS-Addressing. These two policies must match. Thus, the provider says:
>
> <Policy>
> <ws-addressing>
> <Policy/>
> </ws-addressing>
> </Policy>
>
> And the requester says:
>
> <Policy>
> <ws-addressing>
> <Policy>
> <ws-addressing-specific-assertions>
> </Policy>
> </ws-addressing>
> </Policy>
>
> These two policies must match in the intersection algorithm. The text 
> that prevents them from matching says:
>
> “If either assertion contains a nested _policy expression_ 
> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_expression>, 
> the two assertions are compatible if they both have a nested policy 
> expression and the alternative in the nested policy expression of one 
> is compatible with the alternative in the nested policy expression of 
> the other.”
>
> In the note below (which Glen +1ed), Maryann suggests that a Policy 
> with just the <ws-addressing> assertion is expressing a constraint 
> which can be met in several ways – at least that’s how I read her 
> note. She does not, however, suggest concrete wording. Here are a 
> couple of suggestions:
> 1. Change the quoted text above to say that matching of nested policy 
> assertions is dependent on the semantics of the parent assertion. This 
> way, WS-Addressing could define its own semantics for matching and 
> solving their usecase.
> 2. Bob Freund suggested a wildcard assertion that could be included 
> within a nested Policy that would match any other nested policy.
>
> All the best, Ashok
>
>
>
> ------------------------------------------------------------------------
>
> *
> From:* Maryann Hondo [_mailto:mhondo@us.ibm.com_] *
> Sent:* Wednesday, April 04, 2007 7:37 AM*
> To:* Glen Daniels*
> Cc:* Ashok Malhotra; Monica J. Martin; public-ws-policy@w3.org; 
> public-ws-policy-request@w3.org*
> Subject:* RE: Are nested assertions part of the policy vocabulary?
>
>
> Glen,
> I think the problem is that the assertions are really trying to 
> express a constraint .....and should be something
> like "nonAnonymousONLY". so the absence, is not the absence of support 
> but rather the absence of the constraint.
>
> And in this case I think the " no constraints" is sufficient for your 
> use case
> The client has no constraints on what the provider will do.
> That should intersect with all the provider options.
>
> I hope we can talk this through on the call.
> Maryann
>
> *"Glen Daniels" <gdaniels@progress.com>*
> Sent by: public-ws-policy-request@w3.org
>
> 04/04/2007 09:59 AM
>
> 	
>
>
> To
> 	"Monica J. Martin" <Monica.Martin@Sun.COM>, "Ashok Malhotra" 
> <ashok.malhotra@oracle.com>
> cc
> 	<public-ws-policy@w3.org>
> Subject
> 	RE: Are nested assertions part of the policy vocabulary?
>
>
> 	
>
>
>
>
>
>
> Hi Monica:
>
> I'm a little confused here. Are you and MaryAnn indeed saying that
> selecting the first alternative in Ashok's (and indeed WS-Addressing's)
> example means that neither anonymous nor non-anonymous responses are
> allowed? That certainly isn't the goal of the policy, and indeed this
> interpretation would seem to disallow ANY kind of response.
>
> How would you write a consumer policy which was meant to successfully
> intersect with endpoint policies which either a) express nothing about
> anonymous responses, b) express a requirement for anonymous responses,
> or c) express a requirement for non-anonymous responses?
>
> --Glen
>
> > -----Original Message-----
> > From: public-ws-policy-request@w3.org
> > [_mailto:public-ws-policy-request@w3.org_] On Behalf Of Monica J. Martin
> > Sent: Tuesday, April 03, 2007 5:30 PM
> > To: Ashok Malhotra
> > Cc: public-ws-policy@w3.org
> > Subject: Re: Are nested assertions part of the policy vocabulary?
> >
> >
> >
> > hondo: Ashok,
> > My response is yes.
> > Maryann
> >
> > >>mm1: Ashok, agree with MaryAnn on question one answer - this point
> > has been made that the nested assertions are part of the policy
> > vocabulary. Yet, an important point associated with this surrounds
> > whether or not the guiding conformance [1] requires support for those
> > response types - that provides substance on your second
> > question and its
> > disposition.. [2]
> >
> > We also state in Section 3.2 Framework before the statement you cite:
> >
> > An alternative with zero assertions indicates no behaviors. An
> > alternative with one or more assertions indicates
> > behaviors implied
> > by those, and only those assertions.
> >
> > Remember: (no position just stating the action-result), we augmented
> > this text in
> > _http://www.w3.org/Bugs/Public/show_bug.cgi?id=3602_ Issue 3602.
> >
> > [1] WS-A specification(s) referenced
> > [2] Related to empty and the base assumptions of WS-Addressing.
> >
> > >Ashok Malhotra wrote: Section 3.2 of Framework says "When an
> > assertion whose type is part of the policy's vocabulary is
> > not included in a policy alternative, the policy alternative
> > without the assertion type indicates that the assertion will
> > not be applied in the context of the attached policy
> > subject." Are nested assertions included in the policy's
> > vocabulary?
> > >
> > >Consider the following example:
> > >
> > > <wsp:ExactlyOne>
> > > <wsp:All>
> > > <wsam:Addressing> <-- supports all response
> > types --> Alternative 1
> > > <wsp:Policy>
> > > </wsp:Policy>
> > > </wsam:Addressing>
> > > </wsp:All>
> > > <wsp:All>
> > > <wsam:Addressing> <-- requires Anonymous
> > responses --> Alternative 2
> > > <wsp:Policy>
> > > <AnonymousResponses />
> > > </wsp:Policy>
> > > </wsam:Addressing>
> > > </wsp:All>
> > > <wsp:All>
> > > <wsam:Addressing> <- requires nonAnonymous
> > responses --> Alternative 3
> > > <wsp:Policy>
> > > <NonAnonymousResponses />
> > > </wsp:Policy>
> > > </wsam:Addressing>
> > > </wsp:All>
> > > </wsp:ExactlyOne>
> > ></wsp:Policy>
> > >
> > >If Alternative 1 is selected, does this mean that neither
> > Anonymous responses nor NonAnonymous responses are allowed as
> > both are part of the policy vocabulary but not included in
> > the alternative.
> > >
> > >All the best, Ashok
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU/
>
>
>
>
>
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Wednesday, 9 May 2007 17:03:38 UTC