RE: [ws-rx] WD13 comments

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

Sorry - should have sent the pdf that
had all of the red-lines - see new attachment.
-Doug

Doug Davis/Raleigh/IBM@IBMUS

06/08/2006 11:39 PM

To	ws-rx@lists.oasis-open.org
cc
Subject	RE: [ws-rx] WD13 comments

FYI - see comments inline about which ones I applied (to wd14) - please
let the editors know 
if any of these were not simply editoral and we can back them out and open
issues 
for them instead. 
While not an official WD, I've included the current WD14 for those who
want to see it. 
This includes all of the stuff in this note, plus issues 119, 131, 132,
and Marc's edits. 
I'm hoping to have an official WD14 with all pending issues soon.
thanks 
-Doug 


Doug Davis/Raleigh/IBM@IBMUS wrote on 06/08/2006 02:02:00 PM:

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

done in wd14 as part of one of today's issues
 
> 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".
done in wd14 

> > - Do we really need line 114 in section 1.3?  Its a dup
of 112. 
> > I agree. 
done in wd14 

> > - Section 2 uses "AD" before it is defined. 
> > OK, so spell it our either with or without (AD) 
done in wd14 

> > - 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. 
done in wd14 - s/RMD/RM Destination/g and s/RMS/RM Source/g 

> > - 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. 
done in wd14 

> > - Section 2, "(RM)" isn't needed more than once 
done in wd14 

> > - 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.
not done yet 

> > - 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) 
new issue opened 

> > (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. 
Right - I messed up - no change needed. 

> > - Section 3 - line 245 & 246 - should say "offered Sequence"
instead
> > of just "Sequence" (just to be clear) 
> > I agree. 
done in wd14 

> > - 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) 
new issue opened 

> > - Section 3 - line 316 - instead of "SequenceAck/Final"
should we 
> > say "the final SequenceAck" ? 
> > That does seem better. 
done in wd14 
 
> > - 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) 
new issue opened 
 
> > - 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) 
new issue opened/closed w/no action - my bad 
  
> > - 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)
new issue opened 
 
> > - 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. 
new issue opened 
 
> > - Section 3 - line 373 - s/that is closed/that is already closed/
done in wd14 - there were two spots not just one (2nd was in the seqClosed
Fault) 

> > - Section 3 - line 496 - s/thiselement/this element/   -
note the space 
done in wd14 

> > - 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) 
New issue opened 
 
> > - Section 3 - line 504 - s/increase/increase by 1/ 
done in wd14 

> > - Section 3 - line 527 - s/Header/header/   - line 559 too
done in wd14 

> > - 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. 
TC please speak up if you don't like this - I removed this sentence
from WD14. 

 
> > - 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
justthe first?
> > I think so. 
done in wd14 

> > - Section 4 - line 827 - I think this fault is also sent when
> > duplicate CloseSeq messages come in. 
> > I think you are correct. 
done in wd14 
 
> > - 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 [attachment "wsrm-1.1-spec-wd-14.pdf" deleted
by Doug Davis/Raleigh/IBM]

wsrm-1.1-spec-wd-14-diff.pdf