OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: HTML copy of list


I apologize to those who are not using Excel.  Attached is a HTML copy of the comment list.
 
Ralph Berwanger
 
Category: 1- Editorial, 2-Minor Technical, 3-Major Technical
Item   Reference    
No. Submitter Line Email Category Comment Status
1 David Burdett 14 21-Aug 1 Arrange authors in alphabetic order  
1a Phillipe DeSmedt 5 44 24-Aug 1 we need to make sure that the lists of authors and contributors, as well as the Acknowledgements section (6) are up-to-date -- there are many people who have valuably contributed to the specs, through e-mail, conference calls, and face-to-face meetings, that have been left off;  
2 David Burdett 12-16 21-Aug 1 Add angle brackets  
3 David Burdett 29 21-Aug 2 Add a footnote to the page after "addressed" that states "The current specification is a working draft. Some of the requirements are note yet supported". If we don't then some people might think that we are addressing everything in this version.  
3a Chris Ferris 98-104 22-Aug 1 This section should reflect the revised nature of the document.  The Messaging Service (ebXML-MS) specification will define the whole service, not just the structure of the messages.  I like Rik's idea of having 'parts' or 'sections' but another consideration would be to wait for the revised format and as a group, decide how a 'service' can be mapped.  
4 David Burdett 99 21-Aug 2 change "encapsulate ebXML" to "encapsulate (package) ebXML" as otherwise need to define what is meant by package on lines 136/7  
5 David Burdett 99-100 21-Aug 2 replace "ebXML message headers and payloads" by "ebXML payloads" as the message header is covered by this spec  
5a Phillipe DeSmedt 100-101 24-Aug 2 if we will indeed have a section where bindings are specified for mime-aware vs non-mime-aware transports, as we have been discussing, we'll need to update the Introduction (1), where it is currently stated that 'no assumption or dependency is made relative to transport protocol [...]  
6 Marty Sachs 100-101 20-Aug   delete 'ebXML message headers' since the headers are part of the structure specified in this document  
7 Ian Jones 102 17-Aug 1 remove the sentence starting "The main goal…" it is repeated.  
8 Marty Sachs 103 20-Aug   Agnostic' means speptical about the existence of God.  The religious meaning is the onlyh definition in Webster's Third International Dictionary.  I know that 'agnostic' is starting to be used as 'neutral' or something similar.  Please see that the glossary contains a definition of 'agnostic' appropriate to its use here.  
8a Chris Ferris 105-112 22-Aug 1 see item 3a  
9 Gordon van Huizen 104 21-Aug 2 Add something like the following, since the spec will be have scope beyond the original envelope and header specifications: "This specification also discusses messaging service behavior that the recommended message structure is intended to support.". We need to make it clear that there are normative semantics behind the message structure, and that this document discussed them.
 
10 Ian Jones 106 17-Aug 1 reverse the order of the first 2 sentences  
11 Ian Jones 109 17-Aug X This may be incorrect when document is reformatted  
12 David Burdett 111 21-Aug 3 Remove Service Interface or at least make it optional as Service Interface may be in a separate spec  
13 Ian Jones 122 17-Aug 1 Entire section will need revision if document is reformatted  
14 Gordon van Huizen 124-127 21-Aug X The list here needs to be expanded to include the itemsin the note on lines 111-112.  
15 David Burdett 132-133 21-Aug 1 Fix indentation  
16 David Burdett 140 21-Aug 1 text missing. Replace by copying text from lines 360-370  
17 Ian Jones 141 17-Aug 1 remove lines 140 and 141  
17a Dale Moberg line 143 18-Aug 2 The MIME and HTTP/SMTP conventions always assume that the header field-name is case-insensitive for matching operations. Values in a field-body (the stuff after the colon) can be case-sensitive (see RFC 822, 3.4.7) . Mime content-type values are case-insensitive; (RFC 2045, section 5.1) and parameter names are case insensitive. The term "attribute" is an XML term and not a MIME term for a syntactical unit. The way the language reads now it suggests that any value in the header is to be matched in a case-insensitive way. Is that what is wanted? I don't think so, especially for Message-ID and Content-Id values, for example.  
18 David Burdett 144-145  148-149 21-Aug 2 suggests that XML can be case-insensitive which it can't. Also L147, suggests that this applies to the whole spec when it only applies to packaging. Suggest moving these two comments to the start of section 2 after l 149  
19 David Burdett 149 21-Aug 2 Add another bullet point to explain use of italics, e.g. Message Manifest is in italics on Line 284  
19a Chris Ferris 122 22-Aug 2 Do we want to rename this section?  I would think that a related and relevant ebXML specification would be the one to be developed by the newly formed Trading Partner PT.  
20 Henry Lowe 154 21-Aug 2 as there is no other ebXML enveloping than MIME, change the "for example MIME ..." to "i.e., MIME ...".  
21 David Burdett 154 21-Aug 1 Change "for example" to "specifically" as we only allow MIME  
22 David Burdett 157 21-Aug 1 Container MUST -> Container that MUST"  
22a Chris Ferris 140 22-Aug 1 This needs to be a little less terse.  Something like: "Message Headers-a specification of the structure and composition of the information necessary to an ebXML Messaging Service to sucessfully process an ebXML compliant message.  
22b Chris Ferris 141-142 22-Aug 1 Do we still need this?  
22c Chris Ferris 144 22-Aug 2 XML tags are case sensitive.  The statement here derives from the packaging sprcification which discusses MIME headers and attributes which is expressly case sensitive.  I think that this needs some serious clarification before the document is released.  
23 Henry Lowe 180 21-Aug 1 put a reference on it such as Figure 2-1.  
23a Chris Ferris 152 22-Aug X This seems to be an unintended carry-over from the merge and should be removed.  
23b Chris Ferris 152 22-Aug 2 Do we want to define the term and concept of an ebXML message?  I would think that we would.  I think that we should have a consistent mechanism for identifying all ebXML Glossary defined terms and that ebXML message should be one of those terms.  
24 Gordon van Huizen 181-190 21-Aug 3 Some degree of mapping to transport envelopes must be addressed in the spec, at least in the form of a recommendation, for interoperability.  
25 Marty Sachs 184-185 20-Aug   I don't understand what the 'standard transport level envelopes are.'  If this refers to the standard headers defined by HTTP, FTP, SMTP, etc., have all transport envelopes places to put the identity of a specific ebXML handler?  
25a Chris Ferris 154 22-Aug 1 Remove the phrase 'for example'.  We have concluded that it is MIME multipart/related… Suggest phrasing:  A transport independent message envelope which is a MIME multipart/rrelated container which encapsulates the two principal parts of an ebXML message.  
26 Marty Sachs 187 20-Aug   Please explain 'such structures' and when the transport envelope is required.  Ifthe transport envelope is really the HTTP, SMTP, FTP, etc. header, then it is always required. This sentence seems to imply that the transport envelope is in fact something else.  What is it?  
26a Chris Ferris 157 22-Aug 1 Change to 'a single Payload Container…' for clarity.  
27 Marty Sachs 188-189 20-Aug   A transport envelope is not needed for FTP.'  FTP must have some kind of headers so again, there is an implication that the transport envelope is something else.  Is 'transport envelope' supposed to be 'Message envelope'?  But if so, why is it not needed for FTP?  
28 David Burdett 190 21-Aug 3 We need to specify exactly how to specify the data communication (aka transport) envelopes for specific protocols  
29 David Burdett 192-193 21-Aug 1 Change "Message Envelope" to "ebXML Message Envelope" to make consistent with diagram on page 7  
30 David Burdett 194 21-Aug 1 Change "headers" -> "headers that conform to [RFC 2045]" to mandate conformance to the standard  
31 Ian Jones 194-195 17-Aug 1 reverse line 194 and 195 to match the following text  
32 David Burdett 198-199 21-Aug 1 Change first sentence to "ContentType SHALL be set to 'multipart/related' on all ebXML Message Envelopes."  
33 Ian Jones 198 17-Aug 1 replace 'X' with Appendix D  
34 Dick Brooks 198 14-Aug 1 replace 'multi-part' with 'multipart'  
35 Henry Lowe 200-202 21-Aug 2 199 says there are four attirbutes, but only two are listed, i.e., type and boundary (items 1 and 4  2 and 3 are missing).  
36 David Burdett 200-202 21-Aug 2 Only two attributes are defined. Not sure if this is a typo or an omission  
36a Dale Moberg line 203 and elsewhere 18-Aug 1 A Content Id value is to have the same syntax as a Message Id (RFC 2045,section 7) , so in the example, the string should begin with '<' and end with '>'. (The BNF++ is " msg-id =  "<" addr-spec ">") The explanation of the cid: URI  presumes that the content-id has this syntax, because it strips off the "<" and ">" to avoid conflicts with XML lexical rules. So throughout all the example PDUs, the values should look like legal Content-Ids, like <fds78904321quafouipq@ebxmlhost.realm>
 
37 Dick Brooks 200 14-Aug 1 replace 'four' with 'two'  
38 David Burdett 202+ 21-Aug 1 Add an example of a Content-Type attribute  
39 Dick Brooks 202 14-Aug 1 replace '4' with '2'  
40 Henry Lowe 205-206 21-Aug 1 If there is only one valid value, the text "is an example usage of the" should be changed to "line must be included for".  
41 David Burdett 207 21-Aug 1 Limit example to just the "type= ..."  
42 Marty Sachs 210-211 20-Aug   This specification should sprcify a boundary string that cannot occur in the content areas of a body part.  If there is not sucah a unique string, then this specification should have some discussion (informative?) of how to select an appropriate string for a given message.  
42a Chris Ferris 182-186 22-Aug 3 I think that we need to resolve this issue before we release the document for review.  It is too much of a substantial change to leave out.  I think that Dick owns this, correct?  
43 David Burdett 213-214 21-Aug 1 Limit example to just "boundary= ..."  
44 Dick Brooks 213 14-Aug 1 remove 'version=0.1' from the example  
45 David Burdett 215 21-Aug 1 Move section 2.3.2 on Content-Length to before section 2.3.1 to make consistent with the list on lines 194/5  
46a Chris Ferris 189-190 22-Aug 1 Change: 'Implementers of software to process ebXML messages MUST…' to 'Implementers of an ebXML Messaging Service MUST…'  I also think that the close of this sentence could be made more clear.  
46 Henry Lowe 221 21-Aug 1  application/vnd.eb+xml  should be changed to "application/vnd.eb+xml", i.e., remove the spaces after and before the ".  
47 Dick Brooks 221 21-Aug 1 insert a ':' before 'boundary'  
48 Dick Brooks 221 21-Aug 1 remove the spaces before and after 'application/vnd.eb+xml'  
48a Chris Ferris 192 22-Aug 1 If Message Envelope is a glossary defined term, it should be capitalized and italicized, no?  Also, message should be ebXML Messages and similarly italicized.  
49 Henry Lowe 225-226 22-Aug 2 Can there be more than one header?  If no, the text "There MUST be one ebXML header ..." should be chnaged to read "There MUST be one and only one ebXML header ...".  
50 David Burdett 224-228 22-Aug 2 Following on from General Comment 2 above, change last sentence to read "The ebXMl Heder Envelope container consists of an ebXML Header Envelope and an ebXML Header Document"  
51 Dick Brooks Sect 2.4 22-Aug 1 add the following to sectrion 2.4:  'The header body part MUST occur as the first (a.k.a. root) body part in an ebXML message.  
52 David Burdett 227 22-Aug 1 Change to "The ebXML Header Envelope conforms to [RFC2045] amd consists of three MIME headers:"  
52a Chris Ferris 199 22-Aug 1 I assume that the appendices will be cross referenced with their references.  Please review to ensure that any references are updated accordingly before publishing.  
52b Chris Ferris 200 22-Aug 1 References four (4) attributes, yet only two (1 and 4) are listed. Please fix.  
52c Chris Ferris 201-202 22-Aug 2 Arethese attributes mandatory?  Should we use MUST or SHALL to make this clear?  I would think that both attributes MUST be present.  Type to clearly and unambiguously idnetify the message as an ebXML Message and the other (boundary) to demark the boundaries of the MIME multipart/related body parts.  
53 David Burdett 238-240 22-Aug 1 elete second sentence of this para as it is covered by change to L228 above  
54 Henry Lowe 242-245 22-Aug 2 Is this value the same as the value in section 2.3.2?  It sounds like it is.  If it is, so state.  
55 Dick Brooks 243-244 22-Aug 3 In section 2.4.2. Replaced lines which read, 'The Content-Length header is a decimal value used to identify the total number of OTCTST contained in the constituent message body parts, includeing body part boundaries. Emple:' with 'The Content-Length header is a decimal value used to identify the total number of OCTETS contained in the ebXML header document (excluding body part boundaries). Example:'  
55a Chris Ferris 216 22-Aug 1 Is content-Length a mandatory header?  If so, this should be made explicit.  If not, then the header should be expressly identified as advisory.  I would think that it would be useful to have this always present.  
56 David Burdett 248 22-Aug 2 It wasn't clear to me what was being referred to by the "encoded" attribute. It needs to be made specific  
57 David Burdett 250 22-Aug 2 I think "message structures" is ambiguous. Suggest changing sentence to "version - a value indicating the version of the ebXML Transport, Routing and Packaging Messaging Specification that the structure of the message conforms to"  
58 David Burdett 252-254 22-Aug 2 Guidance or rules need to be specified on when the version (or versionless) alternatives should beused  
59 Henry Lowe 254 22-Aug 1 while the version of this document is 0.1, the final released document will be 1.0.  Change ""0.1"" to ""1.0"".  
60 Dick Brooks 254 22-Aug 1 replace "0.1' with '1.0'  
61 Henry Lowe 257 22-Aug 2 Is ISO 8895-1 identical to UTF-8?  If so, perhaps this should be noted.  
62 Dick Brooks 256 22-Aug 2 replace 'iso-8859-1' with 'UTF-8'  
63 Dick Brooks 259 22-Aug 1 remove the spaces between 'charset' and '=' and 'UTF-8'  
64 David Burdett 260-270 22-Aug 3 Optional Support for Signed Header. This whole section strikes me as very woolly and therefore likely to be interpreted differently by implementers. I suggest that we remove this and also the reference to digital signing on L233, pending development of the security spec.  
65 Henry Lowe 260-270 22-Aug 3 Do we want to say anything about multi-hop transmission of messages?  For example "NOTE: In the case of multi-hop transmission (e.g.,bridging), it will be necessary to de-crypt or re-sign header documents at intermediate forwarding nodes."  
66 David Burdett 272 22-Aug 1 Change "envelope" -> "Container"  
67 Ian Jones 283 22-Aug 1 replace 'X' with Appendix B  
68 Marty Sachs 283 22-Aug   Replace 'transport-specific' by 'message-service-specific'  Please examine the document for any remaining instance of 'transport' which really refer to the messaging service.  
69 David Burdett 285-291 22-Aug 3 It is not clear, how it is decided what entries go in the Manifest. I suggest that we replace the second sentence to the end of the paragraph with ... "The ebXML Header Document contains a Message Manifest that identifies the parts of the ebXML Header Document that are present as well as the payload information that is present. See section xxx Message Manifest, for rules on what should exist. If the Message Manifest indicates that a Payload Container is present, then it will consist of an ebXML Payload Envelope and a content portion.  
70 David Burdett 286 22-Aug 1  "is/are" -> "are"  
71 Ian Jones 288 22-Aug 1 change 'Payload Container wil not be present' to 'Payload Container SHALL not be present'  
72 David Burdett 292 21-Aug 1 Change to "The ebXML Payload Envelope conforms to [RFC2045] and consists of three MIME headers:  
73 David Burdett 297 21-Aug 1 Change both "payloads" to "containers".  
74 David Burdett 301 21-Aug 1 Delete "MIME header  identifies this instance of an ebXML"  
75 Henry Lowe 301-302 22-Aug 1 some words are missing, but it's not clear what  please fix.  
76 Marty Sachs 300 22-Aug   I believe that the words, 'identifies the instance of an ebXML' should be deleted.  
77 David Burdett 301-304 21-Aug 1 Remove second sentence as covered by change to L290  
78 Dick Brooks 300-301 22-Aug 1 replace "The Content-ID MIME header identifies this instance of an ebXML is used to uniquely identify an instance of an ebXML message payload body part." with  "The  Content-ID MIME header is used to uniqely identify an instance of an ebXML message payload body part."  
79 Henry Lowe 305 22-Aug 2 in the example, is "ebxmlpayload" required?  If not, how do you know that this part contains a payload?  There is no attribute saying this is a payload.  
80 Dick Brooks 311 22-Aug 1 replace 'header' with ''payload'  
81 Ian Jones 314 22-Aug 2 entire section only discusses digital signature not encryption, it is a direct copy of section 2.4.4 at line 259  
82 Dick Brooks 313 22-Aug 1 replace 'application/vnd.eb+xml' with 'application/xml'  
83 David Burdett 312-321 21-Aug 1 See comments on Optional Support for Signed Header above.  
84 Dick Brooks Section 2.5.4 22-Aug 3 need to specify that encryption is also allowed.  
85 Dick Brooks Section 2.5.4 22-Aug 1 should specify that implementers SHOULD indicate the character set used within the payload when the content-type permits the inclusion of the 'charset' parameter.  
85a Philippe DeSmedt Section 2.5.4 22-Aug   Optional Support for Signed and Encrypted Payloads: This section appears to have been copied verbatim from section 2.4.4 (Optional Support for Signed Headers), and makes no mention of encryption. Encryption is not done on the header, but it is suggested as a possibility for the payload. As such, we'll need to add a sentence or paragraph to section 2.5.4 that actually specifies how encryption could de done (in addition to signing), i.e., have the body of the section correspond to its title;  
86 David Burdett 326 22-Aug 1 Change "ebXML Payload envelope" to ebXML Payload Container"  
87 Ian Jones 336 22-Aug 1 replace 'X' with 'Appendix B'  
88 Henry Lowe 337-358 22-Aug 2 Is the Message digest some sort of check sum such as a CRC?  If so, where does it go in the message?  
89 David Burdett 334 22-Aug 3  Message Digest. I think that we should make this stricter to improve interoperability. How about ... >>>Parties may create a "Message Digest" over a "Domain of Computation" to ensure the integrity of data exchanged using messages that conform to this specification. The Domain of Computation begins with the first "-" octet of the first boundary following the ebXML Message Envelope. The Domain of Computation ends with the last "-" of the final boundary of an ebXML message.  All octets between and including these begin and end points are Domain of Calculation. A Message Digest is calculated by applying a [SHA1] or [MD5] hash over the domain of computation and storing the result in xxx.<<< What isn't clear to me is how the digest should be recorded in an interoperable way. It can't go in the  
90 Ian Jones 344 22-Aug 2 should the definition of '-' be the full ASCII.  I have not checked the spec, I know this is very picky but we must be exacly to ensure interoperability  
91 Marty Sachs 344 22-Aug   I believe some words are missing at the end of this line.  I cannot find anything in this document indicating where the message digest goes.  
92 Ian Jones 351 22-Aug 1 change 'points' to 'octets'.  
93 Dick Brooks 351-352 22-Aug 1 in example, replace lines with "Content-Type: multipart/related; type="application/vnd.eb+xml"; boundary="8760"  
94 Henry Lowe 359 22-Aug 1 Section headers, such "3 Message Header" should match the boxes in figure 2-1 in section 2.1.  For example, this section should be "3 ebXML Header Document".  Make it much easier to read the document.  
95 David Burdett 359 22-Aug 1 Change "Message Header" -> "ebXML Header Document" to conform to the diagram on page 7  
96 David Burdett 360 22-Aug 1 Change "ebXML Header" -> "ebXML Header Document"  
97 David Burdett 361 22-Aug 1 Change "each header" -> "each principal header"  
98 David Burdett 364 4-Jan 1 Remove line  
99 David Burdett 370 22-Aug 1 to he -> "to the"  
100 David Burdett 376-377 22-Aug 2 Delete last sentence as the reason for this statement (routing headers?) is not explained. If we include it we need to specify the circumstances or reasons why information might be added  
101 Henry Lowe 376-377 22-Aug 1 The first sentence isn't entirely clear.  
101a Philippe DeSmedt 372-373 22-Aug   I'm a bit unclear as to the meaning of the NOTE in section 3 (lines 372-373): re. possibly missing header elements, it is stated: '[...] Every effort will be made to preclude this possibility.' As we are 'only' at version 0.1 of this document, there's a strong likelihood that things will change throughout the document (hopefully not by much). Why do we add a NOTE only to this section? Are we more concerned with this piece of the spec changing than other pieces? If so, why?  
102 Dick Brooks 370 22-Aug 1 replace 'he' with 'the'  
103 Marty Sachs 373 22-Aug   The word 'MAY' on this line is snot being used in the RFC2119 sense.  Removethe capitalizaiton.  
104 Marty Sachs 374 22-Aug   Please provide 'To' and 'From' subelements for TPAId.  Each trading partner should be able to select its own value of TPAId in order to use it as a local rapid locator.  
105 Marty Sachs 374 22-Aug   Please add text explaining the meaning of the context attribute in TPAId  
106 Marty Sachs 376 22-Aug   ConversationId: Please add text explaining the meaning of the context attribute on ConversationId.  SEE EMAIL  
107 Marty Sachs 378 22-Aug   Please state that the valaue of the ServiceInterface tage is stated in the TPA.  
108 Marty Sachs 381 22-Aug   Plese state that the action name is defined in the TPA.  
109 David Burdett 386 22-Aug 1 Change "transport-specific" -> "messaging service-specific"  
110 Ian Jones 387 22-Aug 1 section referred to has been removed - remove entire sentence statring, "This is described in more…"  
111 David Burdett 387 22-Aug 1 Reference to Section 4 is incorrect. Section 4 is now Security Considerations.  
112 David Burdett 389-390 22-Aug 2  We don't define what we mean by an application-generate message. Suggest changing definition to "Normal - the ebXML Payload Container contains data that has been provided to the ebXML Messaging Service by the software that called it. For example a business document such as a Purchase Order"  
113 David Burdett 391 22-Aug 1 a -> "an"  
114 Gordon van Huizen 387-388 22-Aug   In San Jose we discussed rolling Acknowledgment and Error message types (which are both messaging-service specific) into a generic "System" message type, as the primary intent of these types is to indicate whether the payload should be processed by the application or by the messaging service. Employing the generic System type also has other benefits:  (1) It allows for additional messaging-service specific messages beyond acknowledgment and error (such as start of frame, eartbeat, etc.); (2) There is no need for application programmers to be aware ofsystem-level messages and their types or subtypes. Enumerating them may prove confusing to application developers. I also have a concern about the use of the term "messaging-service specific". Does this mean that the essages are specific to (a) a particular messaging service implementation or (b) ebXML messaging services in general? If (a), they shouldn't be enumerated in the spec at all but my hair-trigger interoperability exception gets thrown. Either way, the term could be more clear.  
115 David Burdett 394 22-Aug 3 Change definition to "Manifest - lists and identifies the content of the ebXML Header Document and the ebXML Payload Container" - for rationale see reference to line 407+ below.  
116 Ian Jones 395 22-Aug 2 More than routing information is held in the header suggest changing description to something like 'Header-information for processing the entire payload such as routing,…'  
117 David Burdett 395 22-Aug 1 Header isn't just routing information. Suggest changing to conform to definition on L368-9.  
118 David Burdett 410 22-Aug 1 Change "Payload document(s)" -> "ebXML Header Document principal elements and ebXML Payload Container contents"  
119 David Burdett 411 22-Aug 1 Change "document" -> "data or information"  
120 David Burdett 412+ 22-Aug 3 Add section on guidelines for use ...  >>>Document Reference elements MUST created for each principal header element that is not a Manifest or a Header element. It is RECOMMENDED that Document Reference elements are created for each top-level MIME part contained within the ebXML Payload Container. It is an implementation decision of the application or process that is using the ebXML Messaging Service to specify which parte of the ebXML Payload Container are referenced by the Message Manifest".<<<  The rational for this is that knowledge of the existence of, for example, digital signatures, routing headers, etc in the ebXML Header Document is something that the ebXML Messaging Service could usefully discover from the Manifest. Specifying guidelines on what should be referenced in the ebXML Payload Containers should help provide some consistency of use.  
121 David Burdett 416+ 22-Aug 3 Following on from a discussion on email ... i) Change "DocumentLabel" to "DocumentDescription" ii) Add new element "DocumentPurpose" that has a definition of ... >>>"A code that enables the purpose of the referenced document to be determined without retreiving it. Some values for Document Purpose are reserved by the ebXML Messaging Service. These begin with "ebXMLHeader:" and are followed by the name of the principal header element that is present."  
122 David Burdett 437 22-Aug 3 TPAInfo - just a place holder that I think changes are required here, that will arise out of work in the TP group that we haven't yet done.  
123 David Burdett 454+ 22-Aug 3 Need to update definition of PartyId to reflect conclusion (?) of the discussion on the list on PartyId - suggest we add a comment that this is under review.  
124 Henry Lowe 454-472 22-Aug 2 Two comments on these lines: 1. PartyId is not defined completely and, more importantly, the parameter "context" is not defined except in what can be derived from the example. It would seem from the example, that the address 12345 is a valid address for an underlying transport which recognizes and uses DUNS numbers to message delivery.  If this is the case, then the "context" parameter would seem to reflect the mapping onto the underlying transport and a message to be sent over a CORBA transport, you would have, for example <To> <PartyId context="corbalocURL">555xyz.com/Prod/TradingService</PartyId> </To>  
124a Willaim Kammerer 454 22-Aug   The example shows a 5 digit value while it is qualified as a DUNS value and should be 9 digits, suggest that it be changed.  
124b Willaim Kammerer 454 22-Aug   We might need two attributes in the ,PartyhId> element, one top specify the promulgator or the code list (e.g., ISO 9735 , ISO 6523, ASC X12) and a second to give the specific naming authority.  
125 Marty Sachs 458-460 22-Aug   More discussion of the conterxt attribute in needed.  At a minimum, the following sentence should be added following the sentence ending on line 459:   The context attribute identifies the set of identifiers from which the value of PartyID is derived.  It may either identify a standard set of identifiers such as DUNS numbers or may be a keyword which identifies non-standard identifiers agreed to by the partners who are exchanging ebXML messages.  
126 Ian Jones 473 22-Aug 2 Is TPAInfo mandatory?  
127 Ian Jones 492 22-Aug 2 Where did 'context' come from in the example, it is not described anywhere?  
128 Ian Jones 507 22-Aug 2 need proposal to address 'Not Applicable' , 'None' or validation thru DTD  
129 David Burdett 494 22-Aug 1 Delete "uniquely". Message Data doesn't uniquely identify a message, Message Id does.  
130 Ian Jones 475 22-Aug ? definition needs to be corrected  
131 Marty Sachs 497 22-Aug   MessageId:  Please add a discussion of the attribute called for in the DTD and add the attribute to the example.  
132 Marty Sachs 502 22-Aug   RefToMessageId:  Please add a discussion of the attribute called for in the DTD and add the attribute to the example. UUID is a default value of the attribute, not the message ID.  
133 David Burdett 507 22-Aug 1 Change 'Not Applicable'" to ' "NotApplicable" (case-sensitive) '  
134 Ian Jones 505 22-Aug 2 Why is RefToMessageId mandatory?  No obvious rational, is NotApplicable' the correct setting? Is 'None' closer?  
135 Marty Sachs 508-510 22-Aug   Please use different message ids in these example forMessageId and RefToMessageID  
136 Ian Jones 517 22-Aug 2 Why is 'ReliableMessagingInfo' mandatory? Is 'Unspecified' the correct work?  
137 David Burdett 520 22-Aug 3 See recent email suggesting new value of "Delivery Semantics" of "CommunicationProtocol"  
138 Marty Sachs 516 22-Aug   Please delete the word "subordinate".  An attribute is part of the tag.  
139 Marty Sachs 517 22-Aug   Please remove the capitalization from "MAY".  It is not being used here in the RFC2119 sense.  Please give an example of this tag.  
140 Gordon van Huizen 522 22-Aug 3 <AsbestosSuitOn> A number of references in other ebXML documents indicate that the purpose of reliable messaging is for guaranteed delivery ("OnceAndOnlyOnce" semantics, which is even called out specifically in some cases). It's fair to say that this is how ebXML reliable messaging is being marketed, and a reasonable expectation to many. Why, then, do we pull back here to "AtMostOnce"? Since we fully anticipate that ebXML implementations can ride atop reliable messaging infrastructures such as MQSeries and JMS implementations, why are we reluctant to provide a value of OnceAndOnlyOnce within the enumeration for the DeliverySemantics attribute? Presumably the ability to support guaranteed delivery is negotiated at the TPA level. If a given provider doesn't support guaranteed delivery, fine. But let's at least provide a value in the message header for it.  If we are dead serious about NOT supporting OnceAndOnlyOnce in ebXML, we need to ensure that other ebXML documents make it clear that it is not supported so that expectations are appropriately calibrated. My opinion, though, is that we should support OnceAndOnlyOnce for providers that are willing to offer it.  A further issue is that AtMostOnce should not imply reliability, although in our specs it does. The literal role of AtMostOnce is limited to dup elimination. The processing and performance impact for what we currently specify above and beyond dup elimination is significant. If the intention is to provide additional semantics beyond AtMostOnce ("I don't guarantee that a message will arrive safely, but I will make my best effort to be reliable by providing persistence for all reliable messages at both sides of the link and I can tell you whether a message did or did not make it to the receiving message service persistence store"), there should at least be a way to specify whether or not a given message requires this level of reliability. Simply indicating "AtMostOnce" or "Unspecified" does not offer this distinction.  If we continue to NOT support the notion of guaranteed messages (OnceAndOnlyOnce), my recommendation would be to completely decouple "persistent" messages from "at most once" messages--a decoupling for which there is some precedence. If others feel that we should not decouple these semantics for some reason, we need to find an alternative to calling our reliable semantics "AtMostOnce". </AsbestosSuitOn>  
141 David Burdett 521 22-Aug 3 This section should be removed pending completion of the TRP Security spec.  
142 David Burdett 527 22-Aug 1 If this section is kept then "Realm Security" needs to be explained. It doesn't mean anything to me.  
143 Marty Sachs 524 22-Aug   Please provide a normative reference to SSL.  
144 David Burdett 532 22-Aug 1 References - Need to expand references to include other documents (e.g. [RFC2045].  
145 David Burdett 533 22-Aug 1 (and elsewhere). Need to make the referencing style consistent.  
146 Marty Sachs 528 22-Aug   Please change the title to "Normative Referneces".  Any informative references should go in a separate section.  
147 Marty Sachs 533 22-Aug   Please provide a normative reference to Realm Security.  
148 Marty Sachs 537 22-Aug   Please add the title of RFC 2111,  add a reference to XML 1.0,  add a reference to the MIME RFC, add references to any other standards referred to in the text  
149 David Burdett General 22-Aug 1 We should use "communication protocol" rather than "transport" or "transport protocol" when we are referring to the likes of HTTP or SMTP.  Lines where this applies are: 101, 102, 121, 153, 154, 181, 182, 183, 185,187, 188 (twice), 190 (twice), 526, 1322, 1332, 1343 (transport level requirement)  
150 David Burdett General 21-Aug 1 Envelope vs Container. These are used ambiguously. For example, the diagram on page 7 suggests that the ebXML (header or payload) container and the envelope are the same. However the examples on lines 275-282 (header) and lines 328-335, indicate that the "header" is the MIME header for the mime part. Suggest we add the following definitions after the diagrams on page 7...  * An ebXML Header (or Payload) Envelope are the MIME headers that are associated with a MIME part * An ebXML Header (or Payload) document is the content of the MIME part and is:     - an XML document for the ebXML Header, and     - an XML or some other document for the ebXML Payload * An ebXML Header (or Payload) container, is the combination of the ebXML Header (or Payload) envelop and the document it contains  
151 Henry Lowe Routing 22-Aug 3 This is not unrelated to the issue of routing.  This document says nothing about how routing is handled or reflected in the message header.  If we are using source routing (i.e., the message originator or perhaps the TPA defines the route the message will take to the destination).  Presumably a full set of source routing information will need to be contained in the header or perhaps in subheaders containing the route when the route comprises more than a single hop.  This set of routing information would have to contain the necessary "context" for each transport in the case of different transports being used for different hops, e.g., hop-1 uses HTTP, hop-2 uses CORBA, hop-3 uses MQSeries, and hop-4 uses SMTP (OK, perhaps this is a bit complicated, but the  header information structure should be able to support this  heaven knows what the real world may turn up).  
152 Marty Sachs General 22-Aug   Some of the dicussions about interrelations between Reliable Messaging and transport protocols point up the need to state the assumptions about the transport function in some manner.  One possibility is some kind of definition of a conceptual interface between the Messaging Service and the transport function.  It's fine to say that the messaging service is agnostic to the transport protocol but in real life, the Messaging Service run-time must interact with the transport run-time. Design of the messaging service protocol must be with the understanding of what goes on in the most likely transports.  Since it is highly likely that an implementation will include both the messaging service and the transport function, it may be  sufficient to express the interactions as a series of informative notes (or an informative appendix) rather than as a formal interface definition. The important point is that the assumptions have to be stated to ensure that the messaging service and transport function will work together correctly.  
153 David Burdett 781+ 22-Aug 1 Suggest removing the detail of the XML documents to make the examples much shorter.  
154 David Burdett General 22-Aug 1 Add titles to all figures.  
155 David Burdett General 22-Aug 1 Use capitals consistently, specifically:   i) "ebXML header document" -> "ebXML Header Document"   ii) "ebXML header envelope" -> "ebXML Header Envelope"  
156 Marty Sachs 544+ 22-Aug   Are they up to date? (acknowldegments)  
157 Dick Brooks General 22-Aug 2 version' is in the Content-type header of the ebXML header and in the ebXMLHeader root element of the ebXML header document.  I should be in only one place.  
158 Dick Brooks General 22-Aug 3 we need to provide a complete list of possible values for the 'content' attribute within the PartyId element.  
159 Dick Brooks General 22-Aug 3 The MessageData element should also include a 'DeliveryDeadline' element which indicates the last instance in time a message can be delivered to an intended recipient and a 'ResponseDeadline' element to tell the receiver how long they have to send an acknowledgment.  I believe it would also be valuable to indicate how an acknowledgment should be sent on the same session that was used to send the ebXML message.  If the AcknowledgeTo element is not present then whatever was specified in the TPA determines how acknowledgments are delivered.  
160 Shumpei Nakagaki 801-803, 1064-1067 22-Aug   The Appendix B shows the ebXML Message envelope message example only.  The spec is for the envelope and header. Line 801 thru 803 and line 1064 thru 1067 should be replaced with:                                                                                                                          <MessageType>Normal</MessageType><Manifest><DocumentReference><DocumentLabel>Payroll</DocumentLabel><Intent>RecordCommission</Intent></DocumentReference></Manifest><Header><From><PartyId context="DUNS">12345</PartyId></From><To><PartyId context="DUNS">67890</PartyId></To><TPAInfo><TPAId Context="tpadb">12345678</TPAId><ConversationId context="tpadb">987654321</ConversationId><ServiceInterface>RecordCommission</ServiceInterface><Action>Newrecord</Action></TPAInfo><MessageData><MessageId>123456789</MessageId><TimeStamp>20000725T122905.000Z</TimeStamp><RefToMessageId>987654321</RefToMessageId></MessageData><ReliableMessageInfo><DeliverySemantics>"Unspecified"</DeliverySemantics></ReliableMessageInfo></Header>  
161 Marty Sachs 781+ 22-Aug   Both of the example XML files in Appendix B need to be updated to conform to the new header definitions, both <ebXMLMessageHeader> and <Header>.  The DTD and Schema appear to be OK.  


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC