Consolidated updates

[Jacques Durand <JDurand@us.fujitsu.com>]

includes pipe renaming, report from Ric, corrected updates from last call.

 

Jacques

Comments on Ebms_core-3.0-spec-wd-11 (pdf)
------------------------------------------

NOTE: line numbers given below are from the diff version of the draft 11.


============ General:
need to choose between: 
"ebMS Message Service" (e.g. ebMS Message Service Handler, etc.)
and:
"ebMS Messaging Service" (e.g. ebMS Messaging Service Handler, etc.)
The latter is more aligned with the spec title.

============ changes pipe --> MPF

General Rules:
- Replace "[message] pipe" by MPF in all sections (maybe spell out Message Partition Flow when first occurence of a major section)
- Replace expression "pulling [messages] from a pipe" with "pulling messages from an MPF" ("messages" not optional)

2.2.3.2 (L341), also in 4.2, also in 7:
error code "EmptyPipe”  --> error code "EmptyMessagePartitionFlow”  

2.3 (title)
Message Partition Flows

2.3.1:
(L343) replace:
Message pipes... --> Message Partition Flows (MPF)...
(L346) replace:
"which pipe to pull from first,..." --> "which MPF to pull messages from first,..." 

replace the URL ".../defaultPipe" with: ".../defaultMPF".

Update Fig 5., Fig 7 (see attached updates)

Comment Fig 5:
"In the figure above, each arrow represents the transfer of a user message, which could be either pushed or pulled."
replace with:
"In the figure above, each arrow represents the transfer of one or more user messages, which could be either pushed or pulled."

3.1 (L442) replace:
P-Mode.messagePipes --> P-Mode.messagePartitionFlows

4.2 (L484)
- rename  attribute @pipe --> @mpflow
- update "specified in a representation of OpCtx-MessagePipes" with "...of P-Mode.messagePartitionFlow".
- Examples: rename: "pipe="pipe://msh.example.com/pipe123"" as mpflow="mpf://msh.example.com/mpf123"> (also in 4.3)


5.2.1:
rename: eb:Messaging/eb:UserMessage/@pipe: --> .../@mpflow

5.2.2.1:
rename: "eb:Messaging/eb:SignalMessage/eb:PullRequest/@eb:pipe" --> ".../@mpflow"



============= other:


L269:
- modify line on "ebms" actor as: "... must be able to understand the eb:Messaging 
header (qualified with the ebMS namespace)."

L276:
- remove "an MSH MUST be able to exchange..." as that depends on conformance profiles:
some weak profile may not require any signal exchange at all...
replace with: "There are two types of ebMS Messages:"

L277:
"not to carry data" --> "not to carry application data" (because errors may be
notified to COnsumer, therefore data intended to COnsumer)

L293:
"after all headers intended for the ebMS SOAP actor"
replace with:
"after all headers intended for the Receiving MSH"

L299:
"When more than one ebMS message unit is exchanged in the same MEP instance,..."
replace with:
"When more than one ebMS message is exchanged in the same MEP instance, all message units 
involved in this instance must be related."
[just after, move up and modify the sentence as:] 
"The referencing of a message unit by another is done using
 the eb:RefToMessageId element." 

L326:
"This MEP involves a single ebMS user message."
replace with:
"This MEP involves a single ebMS user message unit."

L330:
"To conform to this MEP, the user message MUST NOT relate to any other user message..."
replace with:
"To conform to this MEP, the user message unit MUST NOT relate to any other user message unit..."
L334:
"This MEP involves a single ebMS user message."
replace with:
"This MEP involves a single ebMS user message unit."

L337:
"To conform to this MEP the user message MUST.."
replace with:
"To conform to this MEP the user message unit MUST..."

L341:
"error code “EmptyPipe”..."
replace with:
"error short description "EmptyPipe"..."

L338:
" This MEP involves two ebMS user messages..."
replace with:
"This MEP involves two ebMS user messages units..."

L342:
"MUST NOT relate to any other user message..."
replace with:
"MUST NOT relate to any other user message unit..."

L345:
"...treated as such on receiving side."
replace with:
"...treated as such by a Receiving MSH."

L370:
"A and B on the one hand, C and D on the other hand..."
replace with:
""C and D on the one hand, E and F on the other hand..."


L439:
remove this part:
"...and their related attributes,"

L441:
remove:
"It also controls the use of the PullRequest signal."
L444:
remove:
"It may also define a particular message pipe for reporting errors." 
L476:
remove:
"in terms of transfer mode (Push or Pull) and also"


L839: 
Definition of @pipe is missing:
eb:Messaging/eb:UserMessage/@pipe:
"This OPTIONAL attribute contains a URI that identifies the message pipe to which the message is
assigned. The absence of this element indicates the use of the default pipe. When the message is pulled, 
the value of this attribute MUST indicate the pipe requested in the PullRequest message."

L233 (after the 1st paragraph under "Introduction" title)
"The ebMS V3 specification is divided into two parts described in two different documents. 
Part 1 or Core Features, is the present document. Part 2, containing advanced features, is a
separate document."

L234: just after, insert the last paragraph of 1.1, modified as such:
"Part 1 of this specification (Core Features) only supports a point-to-point MSH
topology, in which no intermediaries are present. Part 2 will
take into account topologies that contain intermediaries (e.g. hub, multi-hop), as well as those in which the
ultimate MSH acts as a SOAP intermediary."

in 7.6 (L1846)
"If a Pull-mode of transfer is established so that the Receiving MSH is getting its messages as responses to
PullRequest signals, such ebMS errors could be pulled in the same way. If a Push-mode is active from
sender to receiver, it could be decided that errors generated on sender side will be pushed like any
regular message. It could also be decided that they will be submitted to a separate message pipe in Pullmode,
so that the Receiving MSH has the option to get such sending-side errors only on demand."
Update as:
"If the Receiving MSH is getting its messages as responses to
PullRequest signals, such ebMS errors can be transmitted as responses to these signals. If user messages are pushed
sender to receiver, it could be decided that errors generated on sender side will be pushed like any
regular message."

6.10:
- Errors in Signed/Encrypted ebXML SOAP With attachments Message (examples)
Line 1941 (or 1590?) - the URI should be URI="cid:PO_Image@example.com";
Line 1968 (or 1610?) - the URI should be URI="cid:PO_Image@example.com";

11.3:
after L2191:
Add:
The remaining part of the message in these two examples of SMTP bindings does not change
and is respectively same as in the previous two examples on HTTP binding.