RE: Checked in soap 1.2 part 3

Hi Noah,

We did your first 2 comments, we think the 3rd one is overtaken by
events, and we had a recollection that we'd have one table given that
the table is simpler than before.   The latest version of the doc is at

http://www.w3.org/2000/xp/Group/6/soap12-part3-20070516.html

Please let us know if you have any dissatisfaction with our handling of
your comments,

Cheers,
Dave on behalf of XMLP=20

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]=20
> Sent: Friday, May 04, 2007 12:30 PM
> To: David Orchard
> Cc: [email protected]
> Subject: Re: Checked in soap 1.2 part 3
>=20
> Hi Dave.  Mostly this looks very good to me, modulo the fact=20
> that I've never been thrilled about including the multicast=20
> in this.  Anyway, here are a few more specific comments:
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > A receiver might, in exceptional circumstances, treat as=20
> erroneous, or
> lost, a message that has been received intact.=20
>=20
> That "might" seems odd given our use of RFC 2119 terminology=20
> elsewhere.  I=20
> wonder whether that might better be phrased as:
>=20
> A receiver MAY (though typically only in exceptional=20
> circumstances) treat=20
> as erroneous, or lost, a message that has been received intact.=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> (editorial) I'm not 100% sure, but I think it's preferred to say=20
> "binding-specific" rather than "binding specific".
>=20
> Anyway, paragraphs 2 & 3 of section 2.2 are inconsistent on=20
> this. Probably=20
> you should do it one way throughout.
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > Determination of abnormal operation is outside the scope of this=20
> specification.=20
>=20
> Might it be more appropriate to say that:
>=20
> "Except insofar as certain error processing is required or=20
> suggested by=20
> the use of the SOAP processing model, determination of=20
> abnormal operation=20
> is outside the scope of this specification."=20
>=20
> I think, for example, that faulting on an mU header you don't=20
> recognize is=20
> required.  Though the details are in SOAP Part 1, this MEP=20
> normatively=20
> appeals to use of that.
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Editorial:  long ago and far away, when I was in the=20
> workgroup, I thought=20
> we were leaning toward splitting the table in 2.3 into two=20
> tables, one for=20
> sender and one for receiver.  That seems to me to make=20
> clearer that the=20
> properties really do apply to one or the other, but never=20
> both.  I can=20
> certainly live with what you have if you prefer.
>=20
> While it's always nice to hear from you all again, I don't need any=20
> explicit followup on these points.  They are offered for your=20
> consideration in case you all find them helpful.  So, if you=20
> decide for=20
> your own reasons to open formal issues to track any of them,=20
> that's up to=20
> you, but you don't need to respond formally with dispositions on my=20
> account.
>=20
> Thanks!  I hope I'll be seeing some of you in Banff next week.
>=20
> Noah
>=20
> --------------------------------------
> Noah Mendelsohn=20
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>=20
>=20
>=20
>=20
>=20