Re: ebxml Messaging Services spec v 0.2

[Nikola Stojanovic <nhomest1@twcny.rr.com>]

<Issue 1>

<Nikola>
<General>
<1>Have we agreed on naming convention (start with UpperCase) for our
names?</1>
</General>
</Nikola>

<David>
 I "think" the convention we are following is that we always start with an
upper case, unless the element/attribute begins with "ebXML".
</David>

<Chris>
Unless the TA team comes up with a recommendation as to style, we'll have to
go with upper-camel-case since that's what we started with (despite my
preference for lower-camel-case;-)
</Chris>

I agree with Chris -> TA team should come up with a naming convention (it is
one of the outstanding items on our "issues" list). As I mentioned before, I
also prefer to start with a lower case. Anyway, we should try to eliminate
exceptions, like start with ebXML if we use UpperCase style.

</Issue 1>


<Issue 2>

<Nikola>
<Line 194>
We should refer somewhere in this spec to "New Murata spec -
http://www.imc.org/draft-murata-xml <http://www.imc.org/draft-murata-xml> ".
</Line 194>
</Nikola>

 <David>
This is an IETF Internet Draft and therefore not a "standard" I'm not sure
we should use it - can we discuss?.
</David>

<Chris>
IETF is scheduled to vote on this soon as I understand. I think that the
choice of vnd.eb+xml needs to be explained in terms of the murata draft with
a note that it is nearing approval. This can be added in next revision.
</Chris>

Again, agree with Chris. If nothing else, we have to explain how we decided
to use this approach.

</Issue 2>


<Issue 3>

<Nikola>
<Line 376>
Take it out.
</Line 376>
</Nikola>

<David>
 Not sure. I thought we'd agreed to leave it in. Personally I'm neutral.
Therefore not changed now but we can change it later.
</David>

I've missed some recent con calls, but Message Header Spec ver 0.63
(http://lists.ebxml.org/archives/ebxml-transport/200007/pdf00003.pdf) and
the first MS Spec ver0-1
(http://lists.ebxml.org/archives/ebxml-transport/200008/doc00003.doc) didn't
have it.

</Issue 3>


<Issue 4>

<Nikola>
<Line 449>
Are we not requiring global uniqueness of MessageID? Have we agreed on
RFC2392? What about UUID/GUID scheme (see: School Interoperability Framework
(http://www.sifinfo.org/spec/SpecFinalWeb.pdf) and BizTalk Framework
(http://msdn.microsoft.com/xml/articles/biztalk/biztalkfwv2draft.asp)).
> </Line 449>
</Nikola>

<David>
We discussed on the last conf call and agreed the current semantics - no
change.
</David>

First, I assume we don't question "global" uniqueness of MessageID. If that
is true, can we just change:
<old>
MessageId - a unique identifier
</old>
to
<new>
MessageId - a globally unique identifier
</new>

Second, I feel that the issue of IDs of "Things" (including MessageIDs) is
very important and should be addressed at the TA level. I've included
references to SIF and BizTalk because they prescribe similar, but
nevertheless different guidelines. Here are just few facts from those specs
that might illustrate some of the relevant aspects.

<SIF>
p: 24 see section OBJECT IDENTIFIERS
"In order to eliminate the possibility of duplicated reference identifiers
and to provide a consistent way of generating these identifiers, SIF
requires the use of a globally unique identifier (GUID) whenever a RefId is
used."
</SIF>

<BizTalk>
The <identity> tag is a URI reference that uniquely identifies the BizTalk
Document for purposes of logging, tracking, error handling, or other
Document processing and correlation requirements. The <identity> tag must be
universally unique. This could be accomplished, for instance, with
Universally Unique Identifiers (UUIDs), as illustrated in the example above,
or with cryptographic hash algorithms such as MD5 applied to the Business
Document(s). The choice of <identity> tag form and the process of generating
<identity> tag is implementation specific.
</BizTalk>

Just by reading RFC 2392 I would assume that mid schema is URL (not URI) and
that it is intended to target mail, news readers.

I hope that we in TA team will be able to produce some guidelines similar to
the ones I just mentioned (this is another outstanding item in our "issues"
list).

</Issue 4>

Regards,
Nikola