[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: comments on v0.2 MS spec
let martha, ian and ralph do it when martha is back from vacation. best
regards, rik
-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Tuesday, September 12, 2000 10:26 PM
To: Chris Ferris - Sun East Coast IR Development; ebXML Transport
(E-mail)
Subject: RE: comments on v0.2 MS spec
Chris
I don't want to add these changes at this point - basically I don't have the
bandwidth. I suggest we include these in the next revision. Looking through,
I don't think there is anything critical.
David
-----Original Message-----
From: Chris Ferris - Sun East Coast IR Development
[mailto:chris.ferris@east.sun.com]
Sent: Tuesday, September 12, 2000 11:15 AM
To: ebXML Transport (E-mail)
Subject: comments on v0.2 MS spec
Here are some comments/edits for the v0.2 MS spec
as we enter the final stage. Most are editorial in
nature.
Cheers,
Chris
Line Category Comment
---- -------- -------------------------
103 1 change "... that describes how to
securely and reliably exchange ..."
to "... that enables the secure
and reliable exchange of ..."
111, general
1/2 we seem to use 'enveloping' and
'packaging' interchangeably. I think
that we should use a consistent
term: 'packaging'. That is afterall
the heading on section 3.
118 1 I think that we should omit the
version of the Overview & Req'ts doc
in the text and leave that to the
reference section
121 2 do we want to add 'and emerging'?
122 2 replace the term "package" with
"exchange"
155/6 1 is this really a convention? I would
have thought that a convention described
treatment of the style of the document.
this seems to reflect a feature of
the specification
160 2/3 technically, the ebXML message is
carried by a transport within the
(optional) protocol specific 'envelope'.
Thus, technically, the (optional)
protocol specific envelope is
NOT part of the ebXML Message.
Suggest that line 160 be removed
164 1 replace 'optional' with 'zero or one'
so as not to conflict or be confused
with OPTIONAL as described in RFC2119
165 1 remove 'if payload is present'. This
is redundant.
166 1 the document might benefit from a
BNF description of an ebXML message.
ebxml-message = ebxml-message-envelope
ebxml-message-envelope =
168 1 replace 'Envelope' with 'Container'
so as to be consistent with line 163
173 1 replace with:
Normative communication protocol
bindings are defined in Appendix E
175 1/2 I think that this is where we should
point out that MIME headers are case
insensitive. e.g.
Content-Type is equivalent to
content-type.
199 1 add period after '... of a body part'
capitalize 'see'.
205/6 2 remove reference to version-less
envelope
208/9 2 strike. If none are defined, we should
simply omit this concept.
231 1/2 add 'Envelope' as the Header container
is the first body part WITHIN the
Envelope, not the first in the
ebXML Message.
239 1 replace 'enhanced' with 'modified'
240 2 XML DSig may permit modifications
to the Header document without violating
the signature. Not sure if we
want to point this out. Possibly, we
should omit this paragraph (239/242)
in lieu of delivery of the Security
spec draft.
244 1 change 'header identifies' to:
'header uniquely identifies'
245 2 do we want to reference RFC 2392 here?
284 1 capitalize MUST NOT
287 2 do we want to reference RFC 2392 and
2557 here?
297 2 do we want to permit use of the
Content-Location header as described
in RFC 2557. If so, then the text
should reflect that the Content-Location
header MAY be present, etc.
311 1 is Content-Type value determined by
the implementer? I would think that
a more correct statement would be that
it is determined by the application
which creates the message.
336 1 replace 'comprised of' with 'MUST have'
338/9 2 we need to get closure on a namespace
scheme for ebXML. I have sent email
to ebxml-architecture for guidance.
343 1 replace 'communication' with 'Message
Service'
345 1 add 'attribute' after MessageType
350 1 replace 'contains' with "MUST have"
356 1 strike this sentence. It is redundant
of the previous sentence (with the
suggested edit for line 350).
366 1 capitalize REQUIRED
369 2 do we want to reference RFC 2557
to describe how CID may be used as
a URI within the Manifest element?
374 2 there are three possible elements
not two. Two are REQUIRED, one has a
cardinality of zero or one.
374 1 capitalize REQUIRED
376 1 replace 'an optional' with 'zero or one'
377 2 is it a code? I would think that this
might be misconstrued. It could be
the value of the root element of
an XML document, it could be a code
from some context. It is also not
clear to me that the "purpose" is
necessarily conveyed. I might send
a PurchaseOrder with the "purpose" of
initiating a purchase agreement. I
might also send it to revise a previous
agreement. In either case, it is still
a PurchaseOrder. The purpose or intent
is intended to be conveyed with the
ServiceInterface and/or Action elements
of the Header.
379 1 replace 2111 with 2392 which obsoletes
2111
379 2 do we want to reference RFC 2557:
MIME Encapsulation of Aggregate
Documents, such as HTML (MHTML). This
would help in the understanding as
to how this should be treated by
a parser.
386 1 need an example which better
reflects the recommended
<authority><local> scheme for
generating a globally unique id.
Note that I could find no reference
to this in RFC 2392 as suggested
in some of our discussions. Perhaps
I have the RFC # incorrect?
390 1 capitalize REQUIRED
360,364,369,391,401,417,464
1 change 'ebXMLMessageHeader' to
'ebXMLHeader'
392 1 capitalize REQUIRED
450 1 an example MessageId would be useful
454 1 replace 'an optional' with 'a'
510 1 add the following to list of
contributors:
Philippe DeSmedt - Viquity
Gordon van Huizen - Progress
Jim Hughes - Fujitsu
Nicholas Kassem - Sun
Nikola Stojanovic - ebXML Architecture Liason
Marc Breissinger - webMethods
Joe Lapp - webMethods
appologies if I've omitted anyone else who feels that
they have contributed. Please feel free to let me, Rik
or David know who you are and we will add your name to
the list of contributors.
--
Christopher Ferris
_/_/_/_/ _/ _/ _/ _/ Enterprise Architect - EMA
_/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063
_/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM
_/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313
_/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA 01803-0903
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC