SV: SV: [ebxml-dev] New ebMS B2B appliance "s2sclient" available from NI

["Torsten Kirschner" <torsten.kirschner@sandbox.no>]

Regarding Vishal's original question, i.e. whether A&B can use the same
MessageIds as as A&C, I'd say no.

The ebMS v.2.0 spec says "The REQUIRED element MessageId is a globally
unique identifier for each message conforming to MessageId [RFC2822]."

As long as 'globally' means the same to all of us, the required degree of
uniqueness is well defined.

Whenever two messages have the same MessageId, they are supposed to be the
exact same message.
Two different combinations of partners cannot exchange the exact same
message.

From an implementation point of view, this makes duplicate elimination as
part of reliable messaging much easier. In order to check whether an MSH has
seen a message before, it just needs to check the MessageId, not the
MessageId pluss several other elements.

Interestingly enough, the reference to RFC2822 leads to this production
"msg-id          =       [CFWS] "<" id-left "@" id-right ">" [CFWS]".
RFC2822 goes on about this for quite some lines. "[...]a good method is to
put the
   domain name (or a domain literal IP address) of the host on which the
   message identifier was created on the right hand side of the "@", and
   put a combination of the current absolute date and time along with
   some other currently unique (perhaps sequential) identifier available
   on the system (for example, a process id number) on the left hand
   side."

I think Hermes1 uses a similar scheme to generate its MessageIds.

Assuming that UUIDs (as in ISO/IEC 11578:1996) already are "globally unique
identifiers", satisfying syntactical requirements in the ebMS spec seems to
be superflous.
Assuming further that one uses them as "id-left", then having  "@id-right"
in MessageId, e.g. "@u60.sandbox.no" in
"05817520-6B71-4609-BD2B-DE97F61A4712@u60.sandbox.no", is redundant. 

Still, one can use a single method to generate both MessageIds and MIME
Content-Ids (for the attachements).
I have yet to come accross a MSH implementation which enforces the RC2822
syntax for ebMS MessageIds, but Content-Ids better be syntactically correct.
Content-Ids, according to RFC2045, must be globally unique as well,
admittedly for a reason practically not relevant to ebMS.

To sum it up, I think using UUID "@" [ FQDN | IP ] is a good way to generate
syntactically and semantically correct MessageIds and Content-Ids for ebMS
version 2.0.

It has become easier to just use UUIDs (as in ISO/IEC 11578:1996) than to
try to figure out a different, sufficiently unique scheme.
Java 1.5 or 6:
try {
	
System.out.println(UUID.randomUUID().toString()+"@"+java.net.InetAddress
		.getLocalHost().getCanonicalHostName());
} catch (UnknownHostException e) {
	System.out.println(UUID.randomUUID().toString()+"@localhost");
}

Having said that, I realize that David Webber's example illustrates that
that often turns out to be only a small problem. That's not my point.
By semantically correct, I mean that the MessageId needs to be globally
unique and that that is all it should be.
This avoids the temptation to put more information into the MessageId than
what the standard supports: some domain- og application-specific key or
other meta data.
In my view, this breaks the idea of standards-based exchanges, if only
because this would require other MSHs to promote that value to the
application.
I'd recommend using the Manifest for that instead.
Or, on a grander scale, if one often comes across the need to convey more
meta data than what the ebMS header can accomodate, I suggest to give that
feedback to the ebMS version 3 TC and ask for a mechanism for it.

Best regards,
Torsten
P.s. Some time ago, I witnessed some consultants "using ebXML"... In
reality, they wrote a 'FTP over something that merely appears to be ebMS'
thing, using the MessageId as a placeholder for the filename.
Obviously, the customer could have saved serious time and money and just
used FTP. 


-----Opprinnelig melding-----
Fra: Stephen Green [mailto:stephengreenubl@gmail.com] 
Sendt: 21. april 2007 20:00
Til: ebxml-dev@lists.ebxml.org
Emne: Re: SV: [ebxml-dev] New ebMS B2B appliance "s2sclient" available from
NIH/OD

In UBL the terminology was changed between UBL 1.0, which called it a
'GUID', and 'UUID' inUBL 2. In the UBL TC we decided for UBL's purposes
(very similar requirements to ebXML's) that GUID refered to proprietary
implementations of UUID whereas UUID could either refer to standards, such
as that in ISO/IEC 11578:1996, or more generally to any ID which is
'universally unique' and 'universal' has different meaning in different
contexts. 'UUID' generally implies avoiding any possible lack of uniqueness
in a particular usage scenario. So a UUID means whatever you * need * it to
mean (standard or otherwise) but GUID is something defined by certain
applications such as certain databases. So the matter is: Does ebXML need
the ID to be agreed across implementations or can it allow the uniqueness to
depend on the use case? If it is intended that all implemenations use the
same standard of UUID then that would have had to be stated in the ebXML
spec and a normative reference given to the UUID standard intended. But the
more pragmatic approach seems to have been taken which I'd paraphrase as "an
ID like a UUID which might be either
1) * any * 'GUID' which a particular prpprietary product might generate or
2) the equivalent of such an ID such as might be defined by a standard or by
any apropriate equivalent means.
So ebXML's use of the term GUID implies anything similar to the various
types of 'GUID' which databases, platforms or the like can generate or
anthing like that which has the same sort of uniqueness as a UUID like that
defined in ISO/IEC 11578:1996 or similar standards. All these mean it is
likely to be unique in the maimum possible scope (so not just unique to a
particular collaboration). But there need not, it seems, be the case that
all parties in the collaboration(s) use the exact same method of creating it
since one could use a Microsoft platform generating its GUID and another
could use Oracle generating its own version of a 'GUID' and both would be
valid. Likewise David RRW's home-grown version of a GUID should equally be
valid *if * it provides roughly the equivalent level of uniqueness. Anything
more specific than that would have been, I suppose, unworkable or too
expensive * but * this pragmatism rules out certainty about what any party
can expect another party to use as a GUID. I guess, as a result of this, it
can't realistically be assumed that the GUID is going to be reliably unique
so not too much weight should be put on that. Also it might be that a
message sent a second time would have the same GUID as the first sending of
the message. Besides, could better than this be realistically expected in a
vendor-neutral protocol standard like ebXML?
Do the testbeds cover this to help interoperability?

All the best

Stephen Green

On 21/04/07, Farrukh S. Najmi <farrukh@wellfleetsoftware.com> wrote:
>
> I very much agree to the use of UUID as well. The ebXML Registry specs 
> use UUIDs extensively for object identification.
>
> Torsten Kirschner wrote:
> > I very much agree, use UUIDs , cf. http://en.wikipedia.org/wiki/UUID .
> >
> > Firstly, they satisfy the requirements in the specification by 
> > definition.
> >
> > Secondly, they avoid semantically overloading the element. If one 
> > needs to convey meta data, there are other elements in the header to 
> > do that.
> >
> > --------------------------------------------------------------------
> > ----
> > *Fra:* Markus Gudmundsson [mailto:markus@unimaze.com]
> > *Sendt:* 19. april 2007 13:25
> > *Til:* Vishal Sinha
> > *Kopi:* ebxml-dev@lists.ebxml.org; ubl-dev@lists.oasis-open.org
> > *Emne:* Re: [ebxml-dev] New ebMS B2B appliance "s2sclient" available 
> > from NIH/OD
> >
> > The ebMS specification refers to RFC 2822 which basically says that 
> > message identifiers should be unique. It also suggests appending the 
> > domain name of the host generating the message identifier to it, as 
> > well as using a date string.
> >
> > It is very common today to use GUIDs, but a GUID is a computer 
> > generated number, which uses host information. GUIDs can be easily 
> > created in most programming languages such as C# or Java and the 
> > host name need not be appended to it. An example of such an 
> > identifier in the common hexadecimal form is
05817520-6B71-4609-BD2B-DE97F61A4712.
> >
> > Best regards,
> >   Markus
> >
> > ----
> > Markus Gudmundsson
> > Unimaze Software
> >
> > Programming tools for UBL and electronic business - Check out 
> > www.unimaze.com <http://www.unimaze.com>
> >
> >
> > On 4/19/07, *Vishal Sinha* <sinhavis@gmail.com 
> > <mailto:sinhavis@gmail.com>> wrote:
> >
> >
> >     Hello All,
> >
> >     I have a question on message ID in ebXML.
> >
> >     The ebXML spec says that message ID is a globally unique identifer
> >     for ebXML messages.
> >     Does it means that between two trading partners it is unique or
> >     is it unique across all trading partners ?
> >
> >     For example if there are 3 trading partner 'A', 'B', 'C'
> >     Lets say, A and B are exchanging messages and Aand C are also
> >     exchanging messages then can A & B can use the same message ID as
> >     A & C.
> >
> >     If someone clarifies on it, it will good help.
> >
> >     regards,
> >     Vishal Sinha
> >
> >
> >     On 4/19/07, *David RR Webber (XML)* <david@drrw.info
> >     <mailto:david@drrw.info>> wrote:
> >
> >         The latest release of the S2Sclient provides enhanced
> >         performance and configuration / environment support.
> >
> >         The S2Sclient has windows desktop drag-and-drop messaging
> >         folder support and CPA configuration of partners including SSL
> >         and dsig setup and instructions.
> >
> >         For more details and download links see:
> >
> >         
> > http://ebxmlforum.blogspot.com/2007/04/nihod-releases-upgraded-s2scl
> > ient-for.html
> >
> >         Enjoy, DW
> >
> >         "The way to be is to do" - Confucius (551-472 B.C.)
> >
> >
> >
> >
> >     --
> >     Regards,
> >     Vishal Sinha.
> >
> >
>
>
> --
> Regards,
> Farrukh
>
> Web: http://www.wellfleetsoftware.com
>
>
>