[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 ) doesnt exist, or if exists, and the value is wrong or invalid. 2. If number attribute in SequenceNum element doesnt exist, or if exist, the value is invalid or wrong. 3. Attributes (from and to) of SequenceNumRange doesnt 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]