Agreed without comment except
as inline. In general mainly +1 to your questions. However there are several
items below you have called out, like whether or not 106 was applied and the style
of the message element names used in the doc, that we should discuss and get
agreement on tomorrow’s call so the editors have clear direction.
I’ll note that I believe your line numbers are from the
diff version of WD13.
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Wednesday, June 07, 2006 7:39 PM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] WD13 comments
Using WD13.pdf
a few comments:
- there are a
couple of period+space+spaces - they should be period+space (fixed in wd14
already)
- Can we remove
sections 1.1 and 1.1 since there is no text in there?
MG: Yes I think so. Section 2 seems to cover this IMO.
- To be
consistent with Marc's previous comments we should replace "See Section
Namespace" with "See Section 1.3".
- Do we really
need line 114 in section 1.3? Its a dup of 112.
I agree.
- Section 2
uses "AD" before it is defined.
OK, so spell it our either with or without (AD)
- Section 2
should define RMS and RMD - e.g. add a "(RMS)" some place -
actually, I thought we never used RMS or RMD but they seem to have now
appeared in the spec - it should be RM Source and RM Destination instead.
I agree.
- Section 2,
replace "It is expected that the AD and RMD will implement as many of
these or as few of these characteristics as necessary to implement the
AD." with "It is expected that the AD and RMD will implement as many
of these or as few of these characteristics as necessary." To say
"foo will implement foo" just sounds odd.
I agree.
- Section 2,
"(RM)" isn't needed more than once
- Section 2 -
remove last sentence of "Deliver" - it was removed by resolution of
106 but not actually removed. Actually recheck issue 106 - I don't think
it was applied.
I can’t parse this right now. I suggest that we examine
this on the call tomorrow. We need to make sure that issue was applied if it
wasn’t.
- Section 3 -
lines 191/192 - we use <wsrm:CreateSequenceResponse> and
CreateSequenceRefused - Gil mentioned this before - we should be consistent -
either both have wsrm: or neither should - check entire spec.
I don’t have a strong preference beyond consistency. I
recall Gil mentioning that the use of the XML syntax style as seeming precise
but it actually isn’t. I agree with that and think using either the
element name with or without the prefix would be more readable. Without seems
better, it’s not like we have two namespaces in play that could case
confusion. We should discuss this on tomorrow’s call as well.
(Note, you seem to switch to the
version without diffs here for line numbers)
- Section 3 -
line 215 - "CreateSequence" isn't in courier nor does it have wsrm:
- Section 3 -
line 242 - is it just protocol messages or RM faults for the Offered sequence
too?
Sounds right.
- Section 3 -
line 245 & 246 - should say "offered Sequence" instead of just
"Sequence" (just to be clear)
I agree.
- Section 3 -
line 301 - "...specifies the duration after which the RM Destination will
transmit..." - after what? It should say 'after receipt of a
message' or something like that.
I’m not so sure about this one. The acks can flow
irrespective of receipt of a message right?
- Section 3 -
line 316 - instead of "SequenceAck/Final" should we say "the
final SequenceAck" ?
That does seem better.
- Section 3 -
line 308++ - should we define "discard" - its not clear to me that we
mean the discarded messages will NEVER (and have never) be delivered to the AD,
instead of just "from now on the RMD won't deliver them".
Your proposed definition? This might need an issue.
- Section 3 -
line 308++ - we don't say anything about the implied value of
IncompleteSequenceBehavior - we should say there is none if that's the case
I agree if it is absent there is no implied value. It does seem
better to specify that. Your proposed text? This might need an issue.
- Section 3 -
line 328 - just Acks go to Accept/AcksTo or RM faults too?
I think just the acks is more consistent, right?
- Section 3 -
line 362/363 - "SequenceClosed fault" should be in courier and
probably have wsrm: (same for SequenceTerminated fault)
- ok gonna stop
- we're totally inconsistent on when we have the protocol elements in courier
and when we use wsrm: or not - we need to recheck the entire doc and be
consistent
I agree.
- Section 3 -
line 373 - s/that is closed/that is already closed/
- Section 3 -
line 496 - s/thiselement/this element/ - note the space
- On line 190
we say that the wsrm:Identifier is a globally unique ID but then we never
actually say that again nor mandate it - which is it? Seems like the
CSR/Id should say it (and Offer/Id too).
This sounds right but I’m not sure I understand this
comment.
- Section 3 -
line 504 - s/increase/increase by 1/
- Section 3 -
line 527 - s/Header/header/ - line 559 too
- Section 3 -
line 557 - what does "valid" mean? non-terminated? not
true - we still send acks then. not reclaimed? Seems like we should just remove
that sentence.
Hmmm, sounds like that might be a good idea.
- Section 3 -
line 565 says "When the RM Source specifies the WSAddressing anonymous IRI
as the address of the <wsrm:AcksTo> EPR, the RM Destination MUST
transmit any
<wsrm:SequenceAcknowledgement> headers for the created Sequence in a SOAP
envelope to be transmitted on the protocol binding-specific channel. Such a
channel is provided by the context of a received message containing a SOAP
envelope that contains a <wsrm:Sequence> header block and/or a
<wsrm:AckRequested> header block for that same Sequence identifier."
I wonder if it should say "..RM Destination MUST only
transmit any..." to imply that its can only do it on these types of
messages, instead of implying that it MUST sent it on all of these types of
messages. Make sense?
Not to me. I don’t get how MUST only change the meaning
from just MUST. I‘m not sure I understand the problem you are seeing with
this text. I’ve looked at this for a while now, granted its late, but I’m
not seeing the problem.
- One day I'd
like to know why we always say "Upper" first instead of
"Lower" in acks :-)
The coin came up heads. J I never dislike consistency
though, glad you found some.
- We're
inconsistent w.r.t. references to WS-Addressing. A lot have
[WS-Addressing] after them but some do not. Isn't it usually just the
first?
I think so.
- Section 4 -
line 827 - I think this fault is also sent when duplicate CloseSeq messages
come in.
I think you are correct.
- Skipped
section 5 since security is still an open issue
- Will check
the schema, wsdl and state tables later.
Aside from the
first one I wanted feedback from others before this monkey went off and made
took some action on 'em.
thanks
-Doug