New proposed issues for Aug 10th call

All
new proposed issues are attached since we still do not have archives. I would
suggest that as these are all editorial we could possibly accept them all as
one issue for the issue list to process rather than taking each individually.
We could of course separate out any from such a grouping that did need
discussion.

 

Propoes-01
location of normative XSD

 

Propoes-02
runon sentence in section 2

 

Propoes-03
editorial def'n of RMS and RMD

 

Propoes-04
clarify second bullet in Protocol Invariants

 

Propoes-05
RM Protocol Elements dives right into extensibility discussion, no intro

 

Propoes-06
use of capitalization for defined terms

 

Propoes-07
Inconsistent use of single and double quotes for values

 

Propoes-08
WS-RX Public Review

 

Propoes-09
Text describing extensibility syntax in WS-RM needed in WS-RM Policy

 

Propoes-10
Missing period on line 347 of WS-RM

 

Propoes-11
Weird gap on page 21

--- Begin Message ---

From: "Christopher B Ferris" <>

To: <>

Date: Tue, 8 Aug 2006 09:54:08 -0700

Title: editorial RM Protocol Elements
dives right into extensibility discussion, no intro

Description:

Section 3 seems to jump right in with
a note to implementers, without at all introducing what the RM protocol

elements are, are for, etc.

It starts out, on line 265 (CD4 draft):

        The
following protocol elements define extensibility points at various places.
Implementations MAY add

        child
elements and/or attributes at the indicated extension points but MUST NOT
contradict the semantics

        of
the parent and/or owner, respectively. If a receiver does not recognize
an extension, the receiver

        SHOULD
ignore the extension.

        ...

Target: spec

Type: editorial

Proposal:

It would seem to me that the content
of section 3 is really separate sub-sections that deals specifically with

extensibility considerations, composition,
etc. I would think that the spec would be better off if these were called
out in their own 

subsections, and some introductory text
were provided, that explains what is in the sub-sections that follow.

Thus, I think that the following would
do the trick:

3 RM Protocol Elements

The following sub-sections define the
various RM protocol elements, and prescribe their usage by a conformant

implementation.

3.1 Considerations on the Use of Extensibility
Points

        (first
para of current section 3)

3.2 Considerations on the Use of "Piggy-backing"

        (2ndpara
of current section 3)

3.3 Composition with WS-Addressing

        (remainder
of section 3 prose)

and renumber sub-sections 3.1 through
3.8 accordingly.

Cheers,

Christopher Ferris

STSM, Software Group Standards Strategy

email: 

blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440

phone: +1 508 377 9295--- End Message ---
--- Begin Message ---

From: "Christopher B Ferris" <>

To: <>

Date: Tue, 8 Aug 2006 09:23:11 -0700

Title:  editorial clarify second
bullet in Protocol Invariants

Description:

the second bullet, on line 219 of CD4
draft, could be clearer, and use the defined

terms appropriately.

target: spec

type: editorial

Proposal:

Change:

line 219: Within every acknowledgement
it issues, the RM Destination MUST include one or more

acknowledgement ranges that contain
the message number of every message accepted by the RM

Destination. The RM Destination MUST
exclude the message numbers of any messages it has not

accepted.

to:

line 219: Within every Acknowledgement
Message it issues, the RM Destination MUST include one or more

<AcknowledgementRange> child elements
that contain, in their collective ranges, the message numbers of every
message 

accepted by the RM Destination. The
RM Destination MUST exclude, in the <AcknowledgementRange> elements,

the message numbers of any messages
it has not accepted.

Cheers,

Christopher Ferris

STSM, Software Group Standards Strategy

email: 

blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440

phone: +1 508 377 9295--- End Message ---
--- Begin Message ---

From: "Christopher B Ferris" <>

To: <>

Date: Tue, 8 Aug 2006 09:13:00 -0700

Title: editorial def'n of RMS and RMD

Description: 

the definitions of RMS and RMD could
be clarified. Also, the term Send should be defined in 

a similar manner to Deliver.

Target: spec

Type: editorial

Proposal:

Change:

line 195: RM Destination: For any one
reliably sent message the endpoint that receives the message.

line 197: RM Source: The endpoint that
transmits the message.

line 198: Send: The act of submitting
a message to the RM Source for reliable transfer.

To:

line 195: RM Destination: The endpoint
that receives messages transmitted reliably from an RM Source.

line 197: RM Source: The endpoint that
transmits messages reliably to an RM Destination.

line 198: Send: The act of transferring
a message from the Application Source to the RM Source for reliable transfer.

Cheers,

Christopher Ferris

STSM, Software Group Standards Strategy

email: 

blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440

phone: +1 508 377 9295--- End Message ---
--- Begin Message ---

From: "Christopher B Ferris" <>

To: <>

Date: Tue, 8 Aug 2006 08:42:19 -0700

Title: runon sentence in section 2

Description:

The following sentence at line of CD4
draft  is what most would consider to be a run-on sentence.

        The
WS-ReliableMessaging specification defines an interoperable protocol that
requires a Reliable

        Messaging
(RM) Source and Reliable Messaging Destination to ensure that each message
transmitted by

        the
RM Source is accepted by an RM Destination, or barring acceptance, that
an RM Source can, except

        in
the most extreme circumstances, accurately determine the disposition of
each message transmitted as

        perceived
by the RM Destination, so as to resolve any in-doubt status regarding receipt
of the messages

        transmitted.

Target: spec

Type: editorial

Proposal:

Replace the sentence starting on line
of CD4 draft with the following:

The WS-ReliableMessaging specification
defines an interoperable protocol that enables a Reliable

Messaging (RM) Source to accurately
determine the disposition of each message it transmits as

perceived by the RM Destination, so
as to allow it to resolve any in-doubt status regarding receipt of the
messages

transmitted. The protocol also enables
an RM Destination to efficiently determine which of those messages it receives

have been previously received, enabling
it to filter out duplicate message transmissions caused by the retransmission,

by the RM Source, of perceived unacknowledged
messages.. It also enables an RM Destination to deliver the messages 

it receives to the Application Destination
in the order in which they were sent by an Application Source, in the event
that they 

are received out of order.

Cheers,

Christopher Ferris

STSM, Software Group Standards Strategy

email: 

blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440

phone: +1 508 377 9295--- End Message ---
--- Begin Message ---

From: "Christopher B Ferris" <>

To: <>

Date: Tue, 8 Aug 2006 07:21:37 -0700

All,

A minor editorial issue for the CD4
draft.

Title: location of normative XSD

Descrpiption:

Section 1.2 adds the following text
to indicate the location of the normative XSD

for the spec.

        The
normative schema for WS-ReliableMessaging can be found at:

         
      http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-schema-200608.xsd

I think that we should indicate that
the namespace URI resolves to a RDDL document that

provides a link to the normative version
of the schema. 

My reasoning is that I believe it possible
that we might address errata, etc. without requiring a namespace 

name change, and yet need to post a
different version of the schema and update the RDDL document

to either change the link to the normative
schema or add a link to the version that addresses errata.

Target: spec

Type: editorial

Proposal:

Replace the text above (line 144 in
the CD4 draft) with the following:

        The
normative schema for WS-ReliableMessaging can be found linked from the

        namespace
document that is located at the namespace URI:

         
      http://docs.oasis-open.org/ws-rx/wsrm/200608

Cheers,

Christopher Ferris

STSM, Software Group Standards Strategy

email: 

blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440

phone: +1 508 377 9295--- End Message ---
--- Begin Message ---

From: "Christopher B Ferris" <>

To: <>

Date: Tue, 8 Aug 2006 09:43:51 -0700

Title:

Description:

In the spec, there are a number of cases
where defined terms are used in their un-capitalized form. This makes it

difficult to determine just when a word
is used as a defined term or when it is being used in the conversational
sense.

As an example, in CD4 draft, starting
at line 250, it reads:

        The
RM Source will expect to receive acknowledgements from the RM Destination
during the course of a

        message
exchange at occasions described in Section 3 below. Should an acknowledgement
not be

        received
in a timely fashion, the RM Source MUST re-transmit the message since either
the message or

        the
associated acknowledgement might have been lost.

Is the use of "acknowledgements"
intended to be the defined term? Hard to tell. Also, is it "acknowledgements"

or should it more correctly be "Acknowledgement
Messages"?

Target: spec

Type: editorial

proposal:

When using defined terms, use the Capitalized
form, or choose a different font styling, such as 

italics so as to make it clear when
a defined term is being used in the formal sense.

Cheers,

Christopher Ferris

STSM, Software Group Standards Strategy

email: 

blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440

phone: +1 508 377 9295--- End Message ---
--- Begin Message ---

From: "Marc Goodner" <>

To: "[WS-RX]" <>

Date: Wed, 9 Aug 2006 12:01:34 -0700

Title:
 Inconsistent use of single and double quotes for values

Description:

The spec is inconsistent in its use of quotes for values of elements and
attributes. In some cases it use a single quote such as ‘PT0S’ to
state a potential value for Expires on line 359. In other cases double quotes
as in stating the possible values of IncompleteSequenceBehavior on lines 368,
371 and 373.

Target: spec

Type: editorial

proposal:

Pick one and
apply throughout spec.

--- End Message ---
--- Begin Message ---

From: "Patil, Sanjay" <>

To: <>

Date: Wed, 9 Aug 2006 17:02:08 -0700

Title: [ws-rx] FW: [Fwd: WS-RX Public Review]

In preparation for the PR, the OASIS staff has suggested the following

update to our specifications. This is a boiler-plate, pro forma change

and I would not expect any objections to this as such.  Nevertheless, we

could talk about this on tomorrow's call and decide to apply this change

for the next revision (due after tomorrow's call), which would be a PR

candidate as per our current plans. 

Marc, could you please include Mary's suggestion in your list of new

issues.

Kudos to our editors team that the OASIS staff could not raise any major

red flags.

-- Sanjay

-----Original Message-----

From: Mary McRae [mailto:] 

Sent: Wednesday, Aug 09, 2006 16:19 PM

To: Patil, Sanjay; ; 'Paul Fremantle'

Subject: RE: [Fwd: WS-RX Public Review]

Hi Patil,

  It looks fine, except for the status section. Please update the text

to match

the template - particularly noting how to submit comments - as shown

below:

------------

 This document was last revised or approved by the [TC name] on the

above date.

The level of approval is also listed above. Check the current location

noted

above for possible later revisions of this document. This document is

updated

periodically on no particular schedule.

Technical Committee members should send comments on this specification

to the

Technical Committee's email list. Others should send comments to the

Technical

Committee by using the "Send A Comment" button on the Technical

Committee's web

page at www.oasis-open.org/committees/[specific-location].

For information on whether any patents have been disclosed that may be

essential

to implementing this specification, and any offers of patent licensing

terms,

please refer to the Intellectual Property Rights section of the

Technical

Committee web page ( www.oasis-open.org/committees/[specific-location]/

ipr.php.

The non-normative errata page for this specification is located at

www.oasis-open.org/committees/[specific-location]. 

------------

Other than that it looks good to go. The good news is that both comment

lists

and the members announce list appear to be functioning properly (other

than

archives) so I can actually make the announcement once the documents are

approved and submitted.

Regards,

Mary

> -----Original Message-----

> From: Patil, Sanjay [mailto:] 

> Sent: Wednesday, August 09, 2006 6:09 PM

> To: ; Paul Fremantle

> Subject: RE: [Fwd: WS-RX Public Review]

> 

> 

> Hi Mary,

> 

> The candidate PR drafts are at

> http://www.oasis-open.org/committees/download.php/19583/WSRM-CD4.zip.

> This package does not yet include an HTML version and our 

> editors team is currently working on it. Meanwhile, could you 

> please take a look at the other formats (PDF, ODT) and let us 

> know if they look alright. It will be great to get your 

> feedback by tomorrow (8/10) before 1 PM Pacific, since that's 

> when our TC meets and we plan to finalize the content of PR 

> drafts during this meeting. Sorry for the short notice.

> 

> -- Sanjay 

> 

> > -----Original Message-----

> > From: Mary McRae [mailto:]

> > Sent: Thursday, Aug 03, 2006 14:06 PM

> > To: 'Paul Fremantle'; Patil, Sanjay

> > Subject: RE: [Fwd: WS-RX Public Review]

> > 

> > Hi Paul,

> > 

> >   Hopefully the comment lists will be functional in the next day or 

> > two; there's no need to *set up* anything as this was done 

> for all TCs 

> > at the same time. The most important thing is to make sure the 

> > specification is in the proper format - please check the 

> templates at 

> > docs.oasis-open.org/templates/ and make sure that you have the 

> > appropriate cover page boilerplate text, notice, etc.

> > 

> >   When you're ready to make the formal submission, note 

> that I'll need 

> > the spec in three formats: editable source, HTML, and PDF.

> > 

> >   That should be it, but please feel free to send me a 

> pointer to the 

> > spec and I'll do a quick check before you produce all of 

> the versions 

> > and point out anything that should be changed.

> > 

> > Mary

> > 

> > 

> > > 

> > > -------- Original Message --------

> > > Subject:  WS-RX Public Review

> > > Date:     Mon, 31 Jul 2006 23:05:45 +0100

> > > From:     Paul Fremantle <>

> > > To:       Mary McRae <>, "Patil, Sanjay"

> > > <>

> > > 

> > > 

> > > 

> > > Mary

> > > 

> > > The WS-RX TC has now closed all substantive issues, and we are 

> > > aiming to have a vote for CD and PR on the call 8/17. We 

> would like 

> > > to be ahead of the game in terms of getting

> > ready for that.

> > > 

> > > Our issues editor is starting to prepare for capturing any raised 

> > > issues. I believe we need to setup the comments list 

> using the new 

> > > comments facility. And we need to inform you.

> > > Have I missed anything?

> > > 

> > > What else can we do to be aforehand in our preparations?

> > > 

> > > Yours,

> > > Paul

> > > 

> > > --

> > > 

> > > Paul Fremantle

> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

> > > 

> > > http://feeds.feedburner.com/bloglines/pzf

> > > 

> > > 

> > > "Oxygenating the Web Service Platform", www.wso2.com

> > > 

> > > 

> > > 

> > > 

> > > --

> > > 

> > > Paul Fremantle

> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

> > > 

> > > http://feeds.feedburner.com/bloglines/pzf

> > > 

> > > 

> > > "Oxygenating the Web Service Platform", www.wso2.com

> > > 

> > 

> > 

--- End Message ---
--- Begin Message ---

From: "Marc Goodner" <>

To: <>

Date: Thu, 10 Aug 2006 09:59:31 -0700

Title:
 Weird gap on page 21

Description:

There is a weird gap between lines 748 and 749 on page 21.

Target: spec

Type: editorial

proposal:

Get rid of the
gap.

 

--- End Message ---
--- Begin Message ---

From: "Marc Goodner" <>

To: <>

Date: Thu, 10 Aug 2006 09:58:14 -0700

Title:
 Missing period on line 347 of WS-RM

Description:

Missing period on line 347 of WS-RM after “WS-Addressing)”

Target: spec

Type: editorial

proposal:

Add the period.

 

--- End Message ---
--- Begin Message ---

From: "Marc Goodner" <>

To: <>

Date: Thu, 10 Aug 2006 09:56:37 -0700

Title:
 Text describing extensibility syntax in WS-RM needed in WS-RM Policy

Description:

The text added to WS-RM on lines 127 – 135 explaining the extensibility
syntax is not present in WS-RM Policy.

Target: spec

Type: editorial

proposal:

Add lines 127-
135 of WS-RM to WS-RM Policy after line 75.

 

--- End Message ---