OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Proposal to accomodate Chris Ferris comments - batch 2


Proposed clarification text to accommodate Chris Ferris comments – second
batch

Comment 4: Improper reference for ws security

Proposed resolutions:

Lines 151: change
“
OASIS WS-Security 2004
“
to
“
OASIS Soap Message Security 1.0
“

Line 155: change:
“
WS-Security 2004
“
to
“
OASIS SOAP Message Security 1.0 [WSS]
“

Line 250: change:
“
WS-Security
“
to
“
OASIS Soap Message Security 1.0 [WSS]
“

Comment 6: Better definition for Reliable message

Proposed clarification:

Line 171-172: change
“
Reliable Message:
A message for which some level of reliable delivery is required.
“
to
“
Reliable Message:
A SOAP message carrying a wsrm:request header block.
“

Comment 8: Definition of PollRequest message

Proposed clarification:

Lines 221-225: change
“
PollRequest Message:
A polling message for Acknowledgment Indication(s). A Sending RMP may send
a PollRequest Message for polling of Acknowledgment Indication(s)
regardless of RM-Reply Pattern of the original Reliable Message. For
example, the Sending RMP may send PollRequest Message to retrieve
Acknowledgment Indication for a message originally sent using Callback
RM-Reply Pattern.
“
to
“
PollRequest Message:
A message sent by the Sending RMP to the Receiving RMP that requests that
it respond with RM-Reply information.“
“



Comment 11: Table does not show Reply to as complex type

Proposed clarification:

Lines 758-766: change
“
4.2.3.2 Element: Request/ReplyPattern/ReplyTo
A Sending RMP MUST include this element for a message with “Callback”
value for Value element.  The Sending RMP MUST NOT include this element
for a message with “Response” or “Poll” value for Value element.  It is to
specify the endpoint for the initial Sending RMP to receive a callback
Acknowledgment Indication or RM Fault Indication.

If present, the format of ReplyTo element MUST be specified by the
reference-schema attribute.  If the attribute is omitted, the default
format of ReplyTo element is URI as defined in [RFC 2396].

                 Table 10 ReplyTo Element
        Cardinality             1
        Value                   String
        Attributes              reference-schema
        Child elements          None

4.2.3.2.1 Attribute: Request/ReplyPattern/ReplyTo/@reference-schema
This attribute is to specify the format or schema of the value of the the
ReplyTo element. The Sending RMP MAY omit this attribute, when the value
of the ReplyTo element is expressed with a value of type URI.
 “
to
“
4.2.3.2 Element: Request/ReplyPattern/ReplyTo
A Sending RMP MUST include this element for a message with “Callback”
value for the Request/ReplyPattern/Value element.  The Sending RMP MUST
NOT include this element for a message with “Response” or “Poll” value for
the Request/ReplyPattern/Value element.  It is used to specify the
endpoint for the initial Sending RMP to receive RM-Reply information.

The format of the child element of Request/ReplyPattern/ReplyTo/Ref MUST
be specified by Request/ReplyPattern/ReplyTo/@reference-scheme, if the
attribute is present.  If the attribute is omitted, the default format of
the child element of Request/ReplyPattern/ReplyTo is URI as defined in
[RFC 2396].

                    Table 10 ReplyTo Element
        Cardinality             0 or 1
        Value                   None
        Attributes              reference-scheme
        Child elements          {Any} (representing the reference)

4.2.3.2.1 Attribute: Request/ReplyPattern/ReplyTo/@reference-scheme
This attribute is to specify the format or scheme of the value of the
child element of Request/ReplyPattern/ReplyTo. The Sending RMP MAY omit
this attribute, when the child element of Request/ReplyPattern/ReplyTo is
expressed with a value of type URI.

The type of this attribute is xsd:anyURI.

“


Lines 863-875  change
“
4.3.1 Element: PollRequest/ReplyTo
A Sending RMP MAY include this element. If present, then the Receiving RMP
MUST send the RMReply information in a new request to the endpoint
specified by this element. If not present, the RM-Reply MUST be sent back
on the response of the Poll request itself. The format or schema of the
value of this element is specified by the reference-schema attribute. If
the attribute is omitted, the default format of ReplyTo element is URI as
defined in [RFC 2396].

                   Table 15 ReplyTo Element
        Cardinality             1
        Value                   String
        Attributes              reference-schema
        Child elements          None

4.3.1.1 Attribute: PollRequest/ReplyTo/@reference-schema
This attribute is to specify the format or schema of the value of the
ReplyTo element. The Sending RMP MAY omit this attribute, when the value
of the ReplyTo element is expressed with a value of type URI.
“
to
“
4.3.1 Element: PollRequest/ReplyTo
A Sending RMP MAY include this element.  If present, the Receiving RMP
MUST send the RMReply information in a new request to the endpoint
specified by this element. If not present, the RM-Reply MUST be sent back
on the response of the Poll request itself.

The format of the child element of PollRequest/ReplyTo MUST be specified
by the PollRequest/ReplyTo/@reference-scheme, if the attribute is present.
 If the attribute is omitted, the default format of the child element of
PollRequest/ReplyTo/Ref is URI as defined in [RFC 2396].

                   Table 15 ReplyTo Element
        Cardinality             0 or 1
        Value                   None
        Attributes              reference-schema
        Child elements          {Any} (representing the reference)

4.3.1.1 Attribute: PollRequest/ReplyTo/@reference-scheme
This attribute is to specify the format or schema of the value of the
child element of PollRequest/ReplyTo.  The Sending RMP MAY omit this
attribute when the child element of PollRequest/ReplyTo is expressed with
a value of type URI.

The type of this attribute is xsd:anyURI.

“



Comment 12: Clarification of scope

Proposed clarification:

Lines 430-431: change
“
• If GroupExpiryTime is used for a messaging scope, then the item
GroupMaxIdleTime
MUST NOT be used, and vice versa.
“
to
“
• If GroupExpiryTime is used for a group scope, then the item
GroupMaxIdleTime
MUST NOT be used, and vice versa.
“


Comment 13: Wording

Proposed clarification:

Lines 484-485: change
“
A Sending RMP that has not been able to receive an acknowledgment for a
sent message, MUST notify the Payload Producer of a delivery error.
“
to
“
A Sending RMP that has not received an acknowledgment for a sent message,
after applying its resend policy, MUST notify the Payload Producer of a
delivery error.
“


Comment 14: Implication that Sending RMP must compare payloads

Proposed clarification

Lines 507-508: change
“
• Two message instances that carry different payloads MUST NOT share the
same Message Identifier.
“
to
“
• Message instances resulting from separate invocations of Submit MUST NOT
share the same Message Identifier.
“


Comment 15: Message is what Sending RMP deals with, not payload

Proposed clarification

Lines 509-511: change
“
• Two message instances that share the same Message Identifier - such as the
resending mechanism generates - MUST carry exactly the same payload(s) and
the
same reliability headers.
“
to
“
• Two message instances that share the same Message Identifier (such as
generated by the resending mechanism) MUST have identical reliability
headers and convey the payload from the same Submit invocation.
“



Comment 17: constraints on sequence number for ordered deliver in wrong place

Proposed clarification:

Lines 669-767: Delete
“
If the MessageOrder element appears in the message received, the Receiving
RMP MUST NOT deliver the message until all messages with the same groupId
value and a lower number value have been delivered.
“
and add the following new paragraph after Line 793:
“
If the MessageOrder element appears in the message received, the Receiving
RMP MUST NOT deliver the message until all messages with the same
Request/MessageId/@groupId value and a lower Request/MessageId/@number
value have been delivered.
“


Comment 20: clarification of term scope

Proposed clarification

Line 402: change “messaging scope” to “scope”


Comment 22: Redundant text is not clear

Proposed clarification

Lines 496-497: remove
“
When the NoDuplicateDelivery agreement item is enabled, a payload
submitted only once to the Sending RMP MUST NOT be delivered twice or more
to the consumer party.
“

since the following paragraph states the same requirement more clearly.


Comment 27: redundant text should be removed

Proposed clarification

Lines 217-218: remove
“
For the Callback and Poll RM-Reply Patterns, RM-Replies for multiple
Reliable Messages MAY be included in a single Reliable Messaging response.
“
since this constraint is clearly stated in specification of Response element.


Comment 28: Term “smallest scope” is unclear

Proposed clarification

Line 408: change
“
The smallest scope of applicability for each RM Agreement item is:
“
to
“
Agreement items applying to the Message Scope MAY be applied at the Group
Scope.

The default scope of applicability for each RM Agreement item is:
“


Comment 29: redundant constraint is misleading

Proposed clarification

Lines 541-542: remove
“
• From one sent message to the next in the same group, the sequence number
MUST
increase by one, starting with value 0.
“

since this is clearly stated in the definition of sequence number values.


Comment 30: Exclusive Or not clear

Lines 666-668: change
“
In a request message, the sender MAY include either a @groupExpiryTime or
a @groupMaxIdleDuration corresponding to the group termination parameters
specified in Section 5.1.2.
“
to
“
In a request message, the sender MAY include either a @groupExpiryTime or
a @groupMaxIdleDuration, but not both, corresponding to the group
termination parameters specified in Section 5.1.2.
“


Comment 36 and 37: Fault specs are misleading

Proposed clarification

Line 1081: change the table row
“
InvalidMessageId

This fault is sent in any of the following cases:
1. If @groupId (for MessageId or RefToMessageIds ) doesn’t exist, or if
exists, and the value is wrong or invalid.
2. If number attribute in SequenceNum element doesn’t exist, or if exist,
the value is invalid or wrong.
3. Attributes (from and to) of SequenceNumRange doesn’t exist, or if
exists, the values are invalid or wrong.
“
To:
“
InvalidMessageId

This fault is sent in any of the following cases:
1. If @groupId (for MessageId or RefToMessageIds ) is not present, or is
present with an invalid value.
2. If @number in SequenceNum element is not present, or is present with an
invalid value.
3. Attributes (from and to) of SequenceNumRange are not present, or are
present with invalid values.
“


Comment 42  extensibility not described in Specification Text


Chris Ferris pointed out that the main body text which specifies the
header elements does not describe the extensibility expressed in the
schema.

In fact, the only place where extensibility is shown, which is in the
figures 6 and 7, shows it incorrectly (with the any at the end).

Proposed clarification:

Lines 562, 567, and 588: remove the boxes with “any” from figures 6 and 7.


Lines 600 – 602: change
“
In a case where the text of the specification is shown to be in conflict
with schema statements, the schema statement prevails. If a message
contains additional elements not described in this specification, the
Reliable Messaging Processor MUST ignore those elements.
“
to
“
In a case where the text of the specification is shown to be in conflict
with schema statements, the schema statement prevails.

The schema for some of the elements specified in this section includes
specification of extensibility elements and attributes.  The extensibility
features expressed formally in the schema are specified in section 4.6.

If a message contains additional elements or attributes not described in
this specification, the Reliable Messaging Processor MAY ignore them.
“


Line 1128:  add new section 4.6
“
4.6 Extensibility features of Schema

The schema namespace with prefix wsrm, which is part of this
specification, specifies extension mechanisms for some schema elements.

The following elements, which have a complex sequence type, are specified
in the schema to allow the presence one or more extension elements, of
type xsd:any, at the beginning of the sequence, as well as one or more
extension attributes:
* Request
* Response
* PollRequest
* NonSequenceReply
* SequenceReplies
* ReplyRange

“







-- 
Tom Rutt
Tel: +1 732 801 5744
Fax: +1 732 774 5133
email: tom@coastin.com; trutt@fsw.fujitsu.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]