W3C home > Mailing lists > Public > public-ws-addressing@w3.org > April 2007

Re: Consolodated changes for alterngive G prime

From: Maryann Hondo <mhondo@us.ibm.com>
Date: Tue, 3 Apr 2007 15:43:18 -0600
To: tom@coastin.com
Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, David Illsley <david.illsley@uk.ibm.com>, WS-Addressing <public-ws-addressing@w3.org>, public-ws-addressing-request@w3.org
Message-ID: <OF54E6A38E.AC9F913A-ON872572B2.00743C55-852572B2.0076F87A@us.ibm.com>
Tom,

In my opinion, negation is part of the policy framework when there are 
alternatives within a policy vocabulary, which is what you currently
have in your example.  I think you will need 2 different endpoint policies 
to support the variations you want.

endpoint 1
<wsp:Policy>
        <wsp:All>
            <wsam:Addressing> <-- supports all response types --> 
          </wsp:All>
</wsp:Policy> 

endpoint 2
<wsp:Policy> 
  <wsp:ExactlyOne>
         <wsp:All>
             <wsam:Addressing> <-- requires Anonymous responses --> 
Alternative 1
                 <wsp:Policy>
                     <wsp:ExactlyOne>
                        <wsp:All>
                             <AnonymousResponses />
                         </wsp:All>
                     </wsp:ExactlyOne>
                 </wsp:Policy>
             </wsam:Addressing>
         </wsp:All>
         <wsp:All>
             <wsam:Addressing> <-  requires nonAnonymous responses --> 
Alternative 2
                <wsp:Policy>
                    <wsp:ExactlyOne>
                         <wsp:All>
                             <NonAnonymousResponses />
                         </wsp:All>
                     </wsp:ExactlyOne>
                 </wsp:Policy>
             </wsam:Addressing>
         </wsp:All>
     </wsp:ExactlyOne>
</wsp:Policy>

Maryann



Tom Rutt <tom@coastin.com> 
Sent by: public-ws-addressing-request@w3.org
04/03/2007 05:01 PM
Please respond to
tom@coastin.com


To
David Illsley <david.illsley@uk.ibm.com>
cc
Anish Karmarkar <Anish.Karmarkar@oracle.com>, WS-Addressing 
<public-ws-addressing@w3.org>, public-ws-addressing-request@w3.org
Subject
Re: Consolodated changes for alterngive G prime







Negation is never mentioned in either alternative G or F.

The idea for alternative G is unqualified "addressing" assertion means 
adressing supported, while the nested policy assertions are
expressing application restrictions (i.e., anon only or non anon only).

Alternative F states that empty implies no response eprs other than NONE 
may be used.  This is closer to negation, but still does not use the word
:negation or negatory or whatever.

Tom

We are hoping to define this without discussion negation whatsoever.

Tom

David Illsley wrote:
> Hi Anish,
> Unfortunately, in speaking to one of our policy experts, there seems to 
be 
> a negation concern with at least one scenario - the one in the example 
in 
> fact... consider the following
>
> What is the meaning of Alternative 1 in this situation?
>
> Example 3-8. Client looking for an endpoint which supports Addressing, 
and 
> does not require support for responses (will intersect with anything)
> <wsp:Policy>
>     <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>
>                     <wsp:ExactlyOne>
>                         <wsp:All>
>                             <AnonymousResponses />
>                         </wsp:All>
>                     </wsp:ExactlyOne>
>                 </wsp:Policy>
>             </wsam:Addressing>
>         </wsp:All>
>         <wsp:All>
>             <wsam:Addressing> <-  requires nonAnonymous responses --> 
> Alternative 3
>                 <wsp:Policy>
>                     <wsp:ExactlyOne>
>                         <wsp:All>
>                             <NonAnonymousResponses />
>                         </wsp:All>
>                     </wsp:ExactlyOne>
>                 </wsp:Policy>
>             </wsam:Addressing>
>         </wsp:All>
>     </wsp:ExactlyOne>
> </wsp:Policy>
>
> My reading (of Framework, 3.2) is that because the AnonymousResponses 
> assertion is found in Alternative 2 that the negation rule means that 
> Alternative 1 includes a 'must not do AnonymousResponses meaning'. And 
> similarly that because of Alternative 3, Alternative 1 includes a 'must 
> not do NonAnonymousResponses meaning'.  If so, Alternative 1 (in this 
> context) does not mean "supports all response types", but in fact 
> "Addressing is supported but you must not send Anonymous or 
Non-Anonymous 
> response EPRs". 
>
> Do you agree with this interpretation? 
> David
>
>
> David Illsley
> Web Services Development
> MP211, IBM Hursley Park, SO21 2JN
> +44 (0)1962 815049 (Int. 245049)
> david.illsley@uk.ibm.com
>
> public-ws-addressing-request@w3.org wrote on 04/03/2007 12:30:50 AM:
>
> 
>> On the negation of nested assertion issue that we talked about today on 

>> the call. I asked our internal policy expert (aka Ashok) about this and 

>> his explanation was that the proposal as it is written, wrt the 
negation 
>> 
>
> 
>> issue, is fine. I.e., we can say (as we have) that absence of either of 

>> the nested assertion means support for both (or that no claim is made).
>>
>> Negation applies *only* when there are two (or more) alternatives: P 
and 
>> 
>
> 
>> Q. P contains an assertion A (either top-level or nested) and Q does 
>> not. If one chooses alternative Q, then that is equivalent to negation 
>> 
> of A.
> 
>> HTH.
>>
>> -Anish
>> --
>>
>> Tom Rutt wrote:
>> 
>>> attached is html showing all changes agreed today
>>>
>>> MarcG alternative G proposal: 
>>>
>>> 
> 
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Mar/0043.html
> 
>>> as amended by Tom Rutt Email 
>>>
>>> 
> 
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Mar/0053.html
> 
>>>
>>> 
> ------------------------------------------------------------------------
> 
>>>     3. Indicating Use of WS-Addressing
>>>
>>> This specification supports a mechanism for indicating, in a WSDL 
>>> description, that the endpoint conforms to the WS-Addressing 
>>> specification. That mechanism uses WS-Policy Framework [WS Policy 1.5 
>>> 
> - 
> 
>>> Framework <#WSPolicy>].
>>>
>>>
>>>       3.1 WS-Policy Assertions
>>>
>>> The mechanism for indicating that a binding or endpoint conforms to 
>>> 
> the 
> 
>>> WS-Addressing specification is through the use of the Web Services 
>>> Policy - Framework [WS Policy 1.5 - Framework <#WSPolicy>] and Web 
>>> Services Policy - Attachment [WS Policy 1.5 - Attachment 
>>> <#WSPolicyAttachment>] specifications. This specification defines 
>>> 
> three 
> 
>>> policy assertions.
>>>
>>> The wsam:Addressing policy assertion applies to the endpoint policy 
>>> 
> subject.
> 
>>> For WSDL 1.1, these assertions may be attached to |wsdl11:port| or 
>>> |wsdl11:binding|. For WSDL 2.0, they may be attached to 
>>> |wsdl20:endpoint| or |wsdl20:binding|.
>>>
>>> A policy expression containing the wsam:Addressing policy assertion 
>>> 
> MUST 
> 
>>> NOT be attached to a wsdl:portType or wsdl20:interface. The 
>>> wsam:Addressing policy assertion specifies a concrete behavior whereas 

>>> 
>
> 
>>> the wsdl:portType or wsdl20:interface is an abstract construct.
>>>
>>>
>>>         3.1.1 Addressing Assertion
>>>
>>> The wsam:Addressing policy assertion is a nested policy container 
>>> assertion. The meaning of this assertion, when present in a policy 
>>> alternative, is that WS-Addressing is required to communicate with the 

>>> 
>
> 
>>> subject. The wsam:Addressing assertion indicates that there are no 
>>> restrictions on the use of WS-Addressing unless otherwise qualified by 

>>> 
>
> 
>>> assertions in its nested policy expression.  In order to indicate that 

>>> 
>
> 
>>> the subject supports WS-Addressing but does not require its use, an 
>>> additional policy alternative should be provided which does not 
>>> 
> contain 
> 
>>> this assertion. This may be done in WS-Policy compact form by adding 
>>> 
> the 
> 
>>> attribute wsp:Optional="true" to the wsam:Addressing assertion.
>>>
>>>
>>>
>>>
>>>         3.1.2 AnonymousResponses Assertion
>>>
>>> The wsam:AnonymousResponses element MAY be used as a policy assertion 
>>> nested within the wsam:Addressing assertion in accordance with the 
>>> 
> rules 
> 
>>> laid down by WS-Policy Framework 1.5 section 4.3.2.
>>>
>>> The appearance of this element within a policy alternativethe 
>>> wsam:Addressing policy assertion indicates that the endpoint expresses 

>>> 
>
> 
>>> explicitrequires support for request messages with to use response 
>>> endpoint EPRs that contain the anonymous URI 
>>> ("http://www.w3.org/2005/08/addressing/anonymous") as the value of 
>>> [address]. In other words, the endpoint guarantees support forrequires 

>>> 
>
> 
>>> the use of anonymous responses.
>>>
>>> The absence of the wsam:AnonymousResponses policy assertion within a 
>>> policy alternative does *not* indicate that the endpoint will not 
>>> 
> accept 
> 
>>> request messages with response endpoint EPRs that contain the 
>>> 
> anonymous 
> 
>>> URI as an address; it simply indicates the lack of any affirmation of 
>>> support for anonymous URIs.
>>>
>>> The None URI ("http://www.w3.org/2005/08/addressing/none") may appear 
>>> 
> as 
> 
>>> the value of [address] in place of the anonymous URI; this value MUST 
>>> 
> be 
> 
>>> accepted.
>>>
>>>
>>>         3.1.3 NonAnonymousResponses Assertion
>>>
>>> The wsam:NonAnonymousResponses element MAY be used as a policy 
>>> 
> assertion 
> 
>>> nested within the Addressing assertion in accordance with the rules 
>>> 
> laid 
> 
>>> down by WS-Policy Framework 1.5 section 4.3.2. The 
>>> wsam:NonAnonymousResponses policy assertion MUST NOT be used in the 
>>> 
> same 
> 
>>> policy alternative as the wsam:AnonymousResponses policy assertion.
>>>
>>> The appearance of this element within a policy alternativethe 
>>> wsam:Addressing assertion indicates that the endpoint expresses 
>>> 
> explicit 
> 
>>> support forrequires request messages with to use response endpoint 
>>> 
> EPRs 
> 
>>> that contain something other than the anonymous URI as the value of 
>>> [address]. In other words, the endpoint guarantees support forrequires 

>>> 
>
> 
>>> the use of non-anonymous responses. This assertion is deliberately 
>>> vague; its presence indicates that some non-anonymous addresses will 
>>> 
> be 
> 
>>> accepted but doesn't constrain what such an address might look like. A 

>>> 
>
> 
>>> receiver can still reject a request that contains an address that it 
>>> doesn't understand or that requires a binding it doesn't support.
>>>
>>> As with the other assertions, the absence of the 
>>> wsam:NonAnonymousResponses policy assertion within a policy 
>>> 
> alternative 
> 
>>> does *not* indicate that the endpoint will not accept request messages 

>>> 
>
> 
>>> with response endpoint EPRs that contain something other than the 
>>> anonymous URI address; it simply indicates the lack of any affirmation 

>>> 
>
> 
>>> of support for them.
>>>
>>> The None URI ("http://www.w3.org/2005/08/addressing/none") may appear 
>>> 
> as 
> 
>>> the value of [address] in place of a non-anonymous address; this value 

>>> 
>
> 
>>> MUST be accepted.
>>>
>>>
>>>         3.1.4 Examples (Compact Form)
>>>
>>> /Example 3-1.// Subject supports WS-Addressing, no statement on 
>>> supported response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsam:Addressing wsp:Optional="true">
>>>
>>>         <wsp:Policy/>
>>>
>>>     </wsam:Addressing>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-2.// Subject requires WS-Addressing, no statement on 
>>> supported response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsam:Addressing>
>>>
>>>         <wsp:Policy/>
>>>
>>>     </wsam:Addressing>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-3. Subject supports WS-Addressing, explicitly (and 
>>> optionally) supports anonymous and non-anonymous response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsam:Addressing wsp:Optional="true">
>>>
>>>         <wsp:Policy>
>>>
>>>             <wsam:AnonymousResponses wsp:Optional="true"/>
>>>
>>>             <wsam:NonAnonymousResponses wsp:Optional="true"/>
>>>
>>>         </wsp:Policy>
>>>
>>>     </wsam:Addressing>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-4. Subject requires WS-Addressing, requires explicit 
>>> 
> support 
> 
>>> of anonymous or non-anonymous response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsam:Addressing>
>>>
>>>         <wsp:Policy>
>>>
>>>             <wsp:ExactlyOne>
>>>
>>>                 <wsam:AnonymousResponses/>
>>>
>>>                 <wsam:NonAnonymousResponses/>
>>>
>>>             </wsp:ExactlyOne>
>>>
>>>         </wsp:Policy>
>>>
>>>     </wsam:Addressing>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-53.// Subject requires WS-Addressing and explicit 
>>> supportrequires the use of non-anonymous response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsam:Addressing>
>>>
>>>         <wsp:Policy>
>>>
>>>             <wsam:NonAnonymousResponses/>
>>>
>>>         </wsp:Policy>
>>>
>>>     </wsam:Addressing>
>>>
>>> </wsp:Policy>
>>>
>>>
>>>         3.1.5 Examples (Normal Form)
>>>
>>> /Example 3-46. Subject supports WS-Addressing, no statement on 
>>> 
> supported 
> 
>>> response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsp:ExactlyOne>
>>>
>>>         <wsp:All/>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All/>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>     </wsp:ExactlyOne>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-57. Subject requires WS-Addressing, no statement on 
>>> 
> supported 
> 
>>> response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsp:ExactlyOne>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All/>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>     </wsp:ExactlyOne>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-8. Subject supports WS-Addressing, explicitly (and 
>>> optionally) supports anonymous and non-anonymous response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsp:ExactlyOne>
>>>
>>>         <wsp:All/>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All/>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <wsam:AnonymousResponses/>
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <wsam:NonAnonymousResponses/>
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <wsam:AnonymousResponses/>
>>>
>>>                             <wsam:NonAnonymousResponses/>
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>     </wsp:ExactlyOne>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-9. Subject requires WS-Addressing, requires explicit 
>>> 
> support 
> 
>>> of anonymous or non-anonymous response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsp:ExactlyOne>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <wsam:AnonymousResponses/>
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <wsam:NonAnonymousResponses/>
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>     </wsp:ExactlyOne>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-610. Subject requires WS-Addressing and explicit support 
>>> ofrequires the use of non-anonymous response EPRs/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsp:ExactlyOne>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <wsam:NonAnonymousResponses/>
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>     </wsp:ExactlyOne>
>>>
>>> </wsp:Policy>
>>>
>>>
>>>         3.1.6 Finding Compatible Policies
>>>
>>>
>>>         When a client is looking for an endpoint with compatible 
>>> 
> policy,
> 
>>>         one common method used is to take the policy intersection
>>>         between the policy which the client is looking for, and the
>>>         policy asserted in the WSDL document; a non-empty intersection
>>>         is sought. The policy used by the client must be written
>>>         carefully to avoid unexpected results. This is most obvious 
>>> 
> when
> 
>>>         the client is not looking for explicit support of a particular
>>>         kind of response; failing to take care could mean missing a
>>>         compatible policy.
>>>
>>> /Example 3-7. Client looking for an endpoint which supports 
>>> 
> Addressing, 
> 
>>> and which supports anonymous responses/
>>>
>>> <wsp:Policy>
>>>
>>>     <wsp:ExactlyOne>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing>
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <AnonymousResponses Optional=?true? />
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>     </wsp:ExactlyOne>
>>>
>>> </wsp:Policy>
>>>
>>> /Example 3-8. Client looking for an endpoint which supports 
>>> 
> Addressing, 
> 
>>> and does not require support for responses (will intersect with 
>>> 
> anything)/
> 
>>> <wsp:Policy>
>>>
>>>     <wsp:ExactlyOne>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing> <-- supports all response types -->
>>>
>>>                 <wsp:Policy>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing> <-- requires Anonymous responses -->
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <AnonymousResponses />
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>         <wsp:All>
>>>
>>>             <wsam:Addressing> <-  requires nonAnonymous responses -->
>>>
>>>                 <wsp:Policy>
>>>
>>>                     <wsp:ExactlyOne>
>>>
>>>                         <wsp:All>
>>>
>>>                             <NonAnonymousResponses />
>>>
>>>                         </wsp:All>
>>>
>>>                     </wsp:ExactlyOne>
>>>
>>>                 </wsp:Policy>
>>>
>>>             </wsam:Addressing>
>>>
>>>         </wsp:All>
>>>
>>>     </wsp:ExactlyOne>
>>>
>>> </wsp:Policy>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>         For more detailed descriptions of the use of wsp:Optional,
>>>         wsp:Ignorable, and strict and lax intersection, please refer 
>>> 
> to
> 
>>>         the WS-Policy Primer [WS Policy 1.5 - Primer 
>>> 
> <#WSPolicyPrimer>].
> 
>>>
>>>
>>> 
>
>
>
>
>
>
> 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 Tuesday, 3 April 2007 21:41:18 GMT

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