RE: [ws-rx] WD13 comments

[Doug Davis <dug@us.ibm.com>]

Possibly 7 issues...

"Marc Goodner" <mgoodner@microsoft.com>
wrote on 06/08/2006 03:33:58 AM:
> 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.

Pretty sure I used the non-diff version since I don't
like looking at
all the red-lines - but as long as people know which
line I meant...

> 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.

I'll do a new issue to make sure everyone is ok with
this (1)

> - 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.

Just need to have the editors reexamine i106 to make
sure it was applied.
I think it might have been done and then over-written
by mistake.

> - 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.

Based on today's call we should file a new issue with
the resolution (2)

> (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?

True but what does the RMS think this duration is
based from?  Some
random point in time or from the time a message arrived
at the RMD?
I've always assumed that the ack interval is the max
amount of
time the RMD will wait before it sends an ACK after
it receives
an RM-enabled message. (3)

> - 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.

Will do a new issue  (4)

> - 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.

New issue (5)
 
> - Section 3 - line 328 - just Acks go to Accept/AcksTo or RM faults
too? 
> I think just the acks is more consistent, right?

Well, the AcksTo EPR is for acks and RM faults so
it seems like the
Accept/AcksTo should behave the same way.  Otherwise
we are inconsistent. (6)

> - 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.

I think I just want the CSR (and Offer) to say that
the ID needs to
be globally unique.  I'll do a new issue - unless
the TC thinks
the monkeys can deal with this.  (7)

> - 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.

Don't really need an issue but we should discuss this
on today's
call just to get general agreement.

> - 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?

> MG: 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.

OK - I reread it and I think its ok.  I was concerned
that it was
implying that every message from to the AcksTo EPR
MUST include
an Ack.  I must have been tired.

> - One day I'd like to know why we always say "Upper" first
instead 
> of "Lower" in acks  :-) 
> The coin came up heads. 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