OASIS ebXML Messaging Services TC

Following-up on the 
level of requirement for the ebbpsig:NonRepudiationInformation 
element:
 
- 5.2.3.3: As Pete 
suggested, the core specification could be made more open to future 
profiling by stating SHOULD in place of MUST, for the presence of 
ebbpsig:NonRepudiationInformation - also lessening 
dependency on ebbp schema.
- the Gateway 
conformance profile will then narrow this further (MUST) by requiring it. (NOTE: 
the gateway profile is already relied upon to resolve options much 
more critical for interoperability, e.g. in reliability 
area).
 
This way, developers 
have a clear guidance as long as the "Gateway One"  conformance profile is 
the interoperability baseline, while the specification remains open for future 
evolution of practices (meaning for new conformance 
profiles).
 
Jacques & 
Hamid
 
 

Sorry to miss discussions because of
travel and meetings.





The mid: and cid: schemes for URIs are not associated
with completely well defined retrieval techniques in terms of what server to
contact, what port to use, what communications protocol to use, etc. So they
have been observed to be more like URNs than URLs in these respects.



I take it that Pete was wondering how cid:
information can be combined with some other information to find the right
message. I think that the ebMS SOAP header in the receipt message should have a
RefToMessageId field. It is presumed that an implementation handles archiving
and retrieval of the messages it has sent in some fashion, although the
specification does not mention it. Hence the RefToMessageId value, combined
with the implementation specific ways of locating that message, and the cid:
URIs yield a way to find a message and an identifier for the message part. ds:Reference
information then characterizes the plaintext and the hash method sufficiently
to support a further check that the message that the MSH implementation had
sent is the “same as” the message the receipt is asserting to have been
received. 



I will take a look more this weekend when
I have a bit more time to study the thread on this. Logically identifying the
message by information is what the NRR process needs. The implementation needs
sufficient information to track down the message but if NRR process is to be
supported, certain presumptions are made on record keeping and archiving. The
implementation needs to retain the messages it has sent in order to check that
the message that someone claims to have received is in fact the message that it
had sent. Something logically based on Message-Id would then be sufficient for the
retrieval task posed by the NRR checking process.