Jan 25 2001 - TR&P Conference Call Minutes

[christopher ferris <chris.ferris@east.sun.com>]

Thanks to Ralph for taking notes!

Attending:

Rik Drummund
Dale Moberg
Ian jones 
Martha Warfelt
Phillipe De Smedt
Doug Bunting
David Burdett
Ralph Berwanger
Henry Lowe
Rich Salz
Chris Ferris
Prasad Yendluri

possibly others, there were many beeps during the call.

Minutes:

1.  It was agreed to accept the list of editorial changes with some
minor exceptions.  <CF> agreed to proved a marked up copy of the changes
to (see below) <RB> and that <RB> would incorporate the changes.  
Updated copies of the document would be provided to <IJ>, <MW>, 
<DB>, <CF> and <RD> [what fun you will have remembing who all 
these intitials belong to]

2.  The was discussion regarding the routingHeader value.  It was agreed
to change RoutingHeader to TraceHeader per the recommendation of <RD>.
Chris to provide formal proposal for change text before next meeting.
The element names agreed were:
	<TraceRoute>
		<Trace></Trace>
	</TraceRoute>

3. It was agreed that source routing (where sender determines
path that a message is to take ) is out of scope for the 1.0
version of the MS spec.

4. It was suggested by Doug and David that there be a non-normative
appendix added to the document that captured "Possible Future Directions"
or "RFE's". There was consensus that this was a good idea. Source
routing would be considered for inclusion in this non-normative appendix.

5.  The ever present reliable messaging discussion continues...  It was
agreed to  remove the delivery receipt from the RM section of the spec.
It was agreed that a delivery receipt MAY be provided to the TO party.
It may or may not be signed.  We will need to identify the proper place
in the spec to make these additions.


Ralph Berwanger
Ambassador to Standards
bTrade.com

Chris Ferris

> 
> This version includes Shimamura-san's comments
> that I inadvertently omitted when collating the
> list.
> 
> Cheers,
> 
> Chris
> 
> All,
> 
> I've collated all of the editorial comments against v0.92
> submitted to date. Please review this carefully and
> identify any that:
>         - you don't agree to
>         - you feel are more correctly classified as
>         minor or major technical
> 
> During Thursday's call, we'll have 15 minutes of
> discussion on these, identify those that are NOT
> to be incorporated due to the above and then vote
> on them as a "block" change for the next revision
> of the MS spec (v0.93).
> 
> If you cannot make the call, but still want to
> contribute to the discussion, please send to the list
> those items that you feel should be excluded from the
> "block" edit with a brief rationale.
> 
> Thanks!
> 
> Chris
> 
> Rik Drummond
> http://lists.ebxml.org/archives/ebxml-transport/200101/msg00200.html
> 
> line 1416: routingheader should be header
> 
> Rich Salz
> http://lists.ebxml.org/archives/ebxml-transport/200101/msg00182.html
> 
> Delete lines 2-7, since it's a duplicate of 91-93 (and internally
> contradictory unless "separate document" on line 6 becomes "separately").
> As a consequence of this, remove line 8 and renumber accordingly.

The change that was agreed was to remove the word 'main' from
line 3 and to replace  'as separate' with 'as a separate' on line 6.

> 
> Line 20, replace "placed into the body of" with "sent over a"
> 
> Line 34, strike "complete".
> Line 34, should "requirements" be "semantics"?
> 
> Line 39, replace "contains" with "contains a non-normative"
> 
> Lines 40-41, need the word "normative" or "non-normative" somewhere.
> 
> Lines 46-48.  Use typographic onomotopoeia, putting "Italics" in italics,
> etc.
> 
> Lines 52-74.  Should be reformatted to more clearly indicate that they
> are an excerpt from RFC2119.
> 
> Lines 82-92. How do these compare with the documents mentioned in lines
> 110-116?
> 
> Line 84. Change "of the" to "on these"?
> 
> Lines 115-116. Change "that includes: ..." to "; the other two are ..."
> and strike the last five words.
> 
> Lines 121-123. Reword to indicate this is one possible architecture, not
> a required architecture.  Consider separating the "applications" and
> "interface" boxes, as is done with the transport box -- that would help
> emphasize what this particular document is defining.
> 
> Line 130ff.  Change "of:" to "of two parts:". Consider capitalizing the
> first words of lines 130 and 131 and putting "and" at the end of 131
> and 134.

Section 7.1 changes deferred as minor technical. Chris and Rich
to collaborate on substitution text since both have cited
issues with this section (Chris's were minor technical and not
included in this list).

> 
> Line 135. replace "an optional, single" with "at most one".
> 
> Lines 136-137. Isn't it the actual payload of the "ebXML application"?
> 
> Figure at line 138. What is the difference between "ebXML Header Container"
> and "ebXML Header Envelope".  Should the latter be in a yellow box
> analogous to the "ebXML HEader Document (XML)"?  And the same question
> for "Payload" except I assume the color would be baby blue. And, now that
> I look at it further, the should the "ebXML Message Envelope" also be
> in a box?
> 
> Line 141. Remove comma after "standard."  Or remove "standard," altogether.
> 
> Line 144 is confusing.  Pragmatically, MIME can carry anything. Is the
> intent better expressed by "contents of the payload are up to the user
> of the ebXML service"?
> 
> Lines 145-146 are confusing. It implies Appendix C only talks about the
> Message envelope, when it's already been made clear it addresses ALL
> the transport issues.  Consider deleting them.
> 
> Lines 147-149. RFC2045 discusses the quoting rules and these lines here
> are a little misleading (cf lines 170 and 177 where quotes are mandatory).
> Consider deleting them and renumbering accordingly.
> 
> Line 158. The trailing semicolon is in error since there are no parameters.
> 
> Line 159. Replace "contains" with "MUST contain"

deferred as minor technical

> 
> Line 170 appears to use "-" not "=", but it could just be my printer.
not an edit. doc is correct
> 
> Line 177. The colon should be removed.  As at least one other person has
> pointed out, the "8760" should be replaced with someone neutral, like
> "hashxxxxxxx@ebxml.org"
> 
> Line 180. Shouldn't the "SHOULD" be a "MUST"?

deferred as minor technical

> 
> Line 186. The trailing semicolon is in error.
> 
> Chris Ferris:
> http://lists.ebxml.org/archives/ebxml-transport/200101/msg00175.html
> 
> 1) line ?? - editorial - change Gordon Van Huizen's company affiliation
> from
> 'Process' to 'Progress'
> 
> 2) line 2 - editorial - change 'The specification' to 'This
> specification'
> 
> 3) line 6 - editorial - suggest we change:
> It will be included in a later version of this specification or as an
> additional specification.
> 
> to:
> 
> It SHALL either be incorporated into a future version of this
> specification or referenced
> as an external specification as deemed most suitable by the ebXML
> Transport, Routing and
> Packaging project team.
> 
> 6) line 47 - editorial - suggest that character font treatment be given
> to
> each term's font (e.g. 'Bold Italics' be made Bold and Italicized) so
> that the
> reader is familiar with what will follow in the specification.
> 
> 7) line 86 - editorial - insert a reference [EBXMLTASEC] even though the
> document has not yet
> been published
> 
> 8) line 84, 89 and others - editorial - suggest that all references be
> made ALLCAPS for consistency.
> e.g. BRA97, EBXMLTP, EBXMLMSREQ. I believe that there are also others
> throughout the spec.
> Either that, or remove the 'ebXML' part of the reference and leave it
> [TP] and [MSREQ].
> It just looks funny.
> 
> 9) line 97 - editorial - suggest we change:
> 
> The design objectives of this specification are to define a Message
> Service (MS) to support XML
> based electronic business between small, medium and large enterprises.
> 
> to:
> 
> The design objectives of this specification are to define a  wire format
> and
> protocol for a Message Service (MS) to support XML based electronic
> business
> between small, medium and large enterprises. While the specification has
> been
> primarily designed to support XML-based electronic business, the authors
> of the specification
> have made every effort to ensure that non-XML business information is
> fully supported.
> 
> 10) line 102 - editorial - suggest we change:
> clarity and accuracy of this specification.
> 
> to:
> 
> clarity, accuracy and efficacy of this specification.
> 
> 16) line 213 - editorial - suggest that all version numbers be made Word
> Fields
> with a value corresponding to the version of the document so that they
> don't
> need to be manually changed with each revision of the spec.
> 
> 17) line 248 - editorial - change 'none' to 'neither'
> 
> 18) line 261 - editorial - related to item 14 suggest we change:
> 
> If an ebXML Payload Container is present, it MUST conform to MIME
> [RFC2045]
> and MUST consist of:
>         a MIME header portion - the ebXML Payload Envelope, and
>         a content portion - the payload itself that may be of any valid MIME
> type.
> 
> to:
> 
> If an ebXML Payload Container is present, it MUST conform to MIME
> [RFC2045]
> and MUST consist of a single payload MIME object that may be of any
> valid MIME
> type including any of the MIME multipart/* types.
> 
> 19) line 269 - editorial - suggest change:
> 
> Payloads MAY be a simple-plain-text-object or complex nested multipart
> objects.
> This is the implementer?s decision.
> 
> to:
> 
> Payloads MAY be a simple-plain-text-object or complex nested multipart
> objects.
> The specification of the structure and composition of payload objects is
> the
> prerogative of the organization that defines the business process or
> information exchange that uses the ebXML Message Service.
> 
> 20) line 278 - editorial - suggest the following be changed:
> 
> The MIME Content-Type for an ebXML payload is determined by the
> implementer and is used to identify the type of data contained in
> the content portion of the ebXML Payload Container. The MIME
> Content-Type
> MUST conform to [RFC2045]. For example:
> 
> to:
> 
> The MIME Content-Type for an ebXML Payload Container is used to specify
> the media type and subtype of data in the body of the ebXML Payload
> Container.
> The value of this MIME parameter is determined by the organization that
> defines the business process or information exchange. The value selected
> SHOULD be chosen from the list of registered MIME media types found at:
>         ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/
> 
> The MIME Content-Type MUST conform to [RFC2045]. For example:
> 
> 21) line 296 - editorial - [MIME] is not listed in the list of normative
> references.
> Instead, it is listed under [RFC2045]. Suggest we change this and any
> other references
> of [MIME] to [RFC2045] or vice-versa.
> 
> 22) line 286 - editorial - extra linefeed in example
> 
> Content-ID: ebxmlpayload-123@ebxmlhost.realm --|
> ebXML MIME      |
> 
> should be:
> 
> Content-ID: ebxmlpayload-123@ebxmlhost.realm --|  ebXML MIME      |
> 
> 23) line 285 - editorial - suggest that we use 'example.com' for all
> domainnames
> listed in our examples. ebxmlhost.realm might be misconstrued as
> meaningful
> or as a valid domainname. example.com is (as I understand) reserved for
> this
> manner of use, kind of like the '555' exchange is reserved for use in TV
> shows
> so that people don't get the urge to dial a number they hear on TV.
> 
> 25) line 330 - editorial - remove <DB> note
> 
> 28) line 333 - editorial - suggest we change:
> 
> If both <DB>the encoding declaration and the MIME charset?</DB> are
> present, the XML prolog for the ebXML Header Document SHALL contain
> the encoding declaration that SHALL be equivalent to the charset
> attribute of the MIME Content-Type of the ebXML Message Header
> Container (see section ebXML Header Container).
> 
> to:
> 
> If both the encoding declaration and the MIME charset parameter are
> present, the XML prolog for the ebXML Header Document SHALL contain
> an encoding declaration that SHALL be equivalent to the charset
> attribute
> of the MIME Content-Type of the ebXML Message Header Container (see
> section
> ebXML Header Container).
> 
> 27) line 346 - editorial - suggest that the example include the MIME
> Content-Type header
> with the charset parameter equivalent for the example (UTF-8).
> 
> Content-Type: application/vnd.eb+xml; version="0.92"; charset="UTF-8";
> <?xml version="1.0" encoding="UTF-8"?>

modified so that the spec includes examples of both with
and without charset/encoding.

> 
> This could be added as an alternative example for the explanation in the
> section.
> 
> 28) line 351 - editorial - remove <DB> note
> 
> 29) line 358 - editorial - remove <DB> note
> 
> 30) line 389 - editorial - suggest we change:
> 
> ApplicationHeaders - an element that can be used by a process or service
> to include additional information that needs to be associated with the
> data in the ebXML Payload but is not contained within it
> 
> to:
> 
> ApplicationHeaders - an element that can be used by a process or service
> to include additional information that needs to be associated with the
> data in the ebXML Payload that the MSH MUST make available to the
> application processing the ebXML Payload Container
> 
> 31) line 394 - editorial - suggest we change:
> 
> an element that contains a list of the errors that have been found in a
> message
> 
> to:
> 
> an element that contains a list of the errors that are being reported
> against a
> previous message
> 
> 32) line 396 - editorial - suggest we change:
> 
> Acknowledgment - an element that is used by a MSH to indicate that a
> message has been received
> 
> to:
> 
> Acknowledgment - an element that is used by a receiving MSH to
> acknowledge to the sending MSH
> that a previous message has been received
> 
> 35) line 508 - editorial - suggested change:
> 
> The designer of the protocol or application that is using ebXML
> Messaging decides
> what payload data is referenced by the Manifest and the values to be
> used for
> xlink:role.
> 
> to:
> 
> The designer of the business proces or information exchange that is
> using ebXML Messaging
> decides what payload data is referenced by the Manifest and the values
> to be used
> for xlink:role.
> 
> 37) line 570 - editorial - suggest we change:
> 
> CPAId element
> The REQUIRED CPAId element is a string that identifies the Collaboration
> Protocol Agreement (CPA) that governs the processing of the message.  It
> MUST be an identifier that is unique within the combination of the From
> and To Parties.
> 
> CPAId element
> The REQUIRED CPAId element is a string that identifies the Collaboration
> Protocol Agreement (CPA) that governs the processing of the message.  It
> MUST be an identifier that is unique within the domain of the names
> chosen
> by the Parties.
> 
> 38) line 576 - editorial - remove <DB> note
> 
> 39) line 590 - editorial - remove <DB> note
> 
> 40) line 598 - editorial - remove <DB> note. However, we do need to
> double check against the BP specification to ensure
> that this is indeed the term that should be used in this context.
> 
> 42) line 627 - editorial - remove <DB> note. This issue should be taken
> up based on Andrew's comments regarding the various uses of
> xsd:timeInstant
> in the schema.
> 
> 44) line 645 - editorial - change 'is' to 'MAY be'
> 
> 46) line 671 - editorial - remove example and defer until end of section
> 
> 50) line 802 - editorial - suggest that the example not make use of
> default
> values. I propose substitution of the example with the following:
> 
> <Header id="N01">
>   <From>?</From>
>   <To type="userType">...</To>
>   <CPAId>http://www.ebxml.org/cpa/123456</CPAId>
>   <ConversationId>987654321</ConversationId>
>   <Service type="myservicetypes">QuoteToCollect</Service>
>   <Action>NewPurchaseOrder</Action>
>   <MessageData>
>     <MessageId>UUID-2</MessageId>
>     <Timestamp>20000725T121905.000Z</Timestamp>
>     <RefToMessageId>UUID-1</RefToMessageId>
>   </MessageData>
>   <QualityOfServiceInfo
>         deliverySemantics="OnceAndOnlyOnce"
>         deliveryReceiptRequested="Signed"/>
> </Header>
> 
> 51) line 824 - editorial - suggest we change:
> 
> The RoutingHeader element contains information about a single
> transmission
> of a message between two Parties. If a message traverses multiple hops
> by
> passing through some type of intermediate system between the From Party
> and the To Party, then each transmission over each hop results in the
> addition of a new Routing Header element.
> 
> to:
> 
> The RoutingHeader element contains information about a single
> transmission
> of a message between two MSH nodes. If a message traverses multiple hops
> by
> passing through one or more intermediate MSH nodes as it travels between
> the From
> Party MSH and the To Party MSH, then each transmission over each
> successive "hop" results
> in the addition of a new Routing Header element.
> 
> 52) line 858 - editorial - change 'optional' to 'OPTIONAL'.

instead of optional should use MAY occur or MAY be present.
HOWEVER, it was agreed that we should defer this item to Vancouver
where we will take up Doug's suggestion that the document be
scrubbed for all occurances of RFC2119 terms to ensure that 
the correct terms have been used in all cases.

> 
> 53) line 873 and 880 - editorial - relocate the attribute definitions
> so that they are immediately following their introduction on line 804.
> 
> reliableMessagingMethod attribute
> intermediateAckRequested attribute
> 
> 54) line 912 - editorial - remove the second part of the single hop
> example. It is overly redundant and possibly confusing.
> 
> 55) line 981 - editorial - remove this line as it adds no value and
> might possibly be confusing.
> 
> 56) line 991 - editorial - change 'recommended' to 'RECOMMENDED'
> 
> 58) line 1030 - editorial - need example of StatusData element
> 
> 60) line 2172 - editorial - the version of the schema in v,0.92 is NOT
> accurate. It is the version 0.91 schema. It should be removed and a
> reference to an external link should be put in its place. I propose
> that the URL be:
> 
>         http://www.ebxml.org/project_teams/transport/ebxmlHeader,v<version>.xsd
> 
> Shimamura Masayoshi
> http://lists.ebxml.org/archives/ebxml-transport/200101/msg00176.html
> - line 639 [editorial] : change 'four attributes' to 'five attributes'
> 
> - line 650 [editorial] : change 'MUST used' to 'MUST be used'
> 
> - line 655 [editorial] : I think "not specified" is unclear description.
>   I'd like to suggest changing to "not used".
> 
> - line 664, 665 [editorial] : It seems to me that the two sentences
>   662-664 and 665-666 should be one sentence. I'd like to suggest
>   deleting newline between line 664 and 665.
> 
> - line 771 [editorial] : change 'from Party MSH' to  'From Party MSH'
> 
> - line 779 [editorial] : insert one space character after period
> 
> - Some lines [editorial] :  Since SequenceNumber element was moved to
>   the Header element from the Routing Header element,
>     - line 834 : delete this line
>     - line 857-870 : delete this description
>     - line 2339 : delete this line
>     - line 2364 : move this line after line 2321
begin:vcard 
n:Ferris;Christopher 
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XML Technology Development
adr:;;One Network Drive;Burlington;Ma;01824-0903;USA
version:2.1
email;internet:chris.ferris@east.Sun.COM
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard