2004/ws/addressing ws-addr-soap.xml,1.129,1.130

Update of /sources/public/2004/ws/addressing
In directory homer:/tmp/cvs-serv7090

Modified Files:
	ws-addr-soap.xml 
Log Message:
Fixed typos


Index: ws-addr-soap.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-soap.xml,v
retrieving revision 1.129
retrieving revision 1.130
diff -C2 -d -r1.129 -r1.130
*** ws-addr-soap.xml	14 Mar 2006 09:45:20 -0000	1.129
--- ws-addr-soap.xml	14 Mar 2006 10:59:04 -0000	1.130
***************
*** 285,289 ****
                message is forwarded along the message path. The specification for a SOAP header used as
                a reference property or use of the soap:relay attribute can override this default
!               behaviour.</p>
            </note>
          </div3>
--- 285,289 ----
                message is forwarded along the message path. The specification for a SOAP header used as
                a reference property or use of the soap:relay attribute can override this default
!               behavior.</p>
            </note>
          </div3>
***************
*** 330,334 ****
              <p>Each header block added as a result of the above rule is annotated with a
                wsa:IsReferenceParameter attribute (see <specref ref="additionalinfoset"/>) whose
!               value is a valid xs:boolean representaion of <attval>true</attval>. Any existing
                wsa:IsReferenceParameter attribute on the header block is replaced.</p>
              <note>
--- 330,334 ----
              <p>Each header block added as a result of the above rule is annotated with a
                wsa:IsReferenceParameter attribute (see <specref ref="additionalinfoset"/>) whose
!               value is a valid xs:boolean representation of <attval>true</attval>. Any existing
                wsa:IsReferenceParameter attribute on the header block is replaced.</p>
              <note>
***************
*** 479,483 ****
              response message SHOULD be sent using a separate connection and using the address value
              specified by response endpoint. Note that other specifications MAY define special URIs
!             that have other behaviours (similar to the anonymous URI).</p>
          </div3>
          <div3>
--- 479,483 ----
              response message SHOULD be sent using a separate connection and using the address value
              specified by response endpoint. Note that other specifications MAY define special URIs
!             that have other behaviors (similar to the anonymous URI).</p>
          </div3>
          <div3>
***************
*** 489,493 ****
              binding that supports a one-way MEP could put the reply message in a separate one-way
              MEP and a separate HTTP request. As in SOAP 1.1/HTTP, note that other specifications MAY
!             define special URIs that have other behaviours (similar to the anonymous URI).</p>
          </div3>
        </div2>
--- 489,493 ----
              binding that supports a one-way MEP could put the reply message in a separate one-way
              MEP and a separate HTTP request. As in SOAP 1.1/HTTP, note that other specifications MAY
!             define special URIs that have other behaviors (similar to the anonymous URI).</p>
          </div3>
        </div2>
***************
*** 915,919 ****
            appearing as reference parameters in an EPR as a possible attack.</p>
          <p>There are known XML ID and re-structuring attacks which should be considered by message
!           processors, see [<bibref ref="WS-Security"/>] - Security Conciderations: Removal and
            modification of XML elements.</p>
        </div2>
--- 915,919 ----
            appearing as reference parameters in an EPR as a possible attack.</p>
          <p>There are known XML ID and re-structuring attacks which should be considered by message
!           processors, see [<bibref ref="WS-Security"/>] - Security Considerations: Removal and
            modification of XML elements.</p>
        </div2>

Received on Tuesday, 14 March 2006 14:25:17 UTC