[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: comments on v0.2 MS spec
David/All,
My intent was to have these comments considered for v0.3,
not the current draft which I think we all agree (so far)
is ready to be reviewed by a wider audience. I am sorry
if the preamble was misleading.
Cheers,
Chris
Rik Drummond wrote:
>
> 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
--
_/_/_/_/ _/ _/ _/ _/ Christopher Ferris - Enterprise Architect
_/ _/ _/ _/_/ _/ 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