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

 


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

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


Subject: RE: [bdxr] Business Document Envelope Committee Specification Draft 01 Working Draft 03 now available for internal review


Ken, others

I have read through the specification and I have some remarks:

Page 3 shows a Copyright statement from 2001 - 2015 .. but the spec was not created before 2015 .. so why that 2001 - 2015? .. and not 2015 only (for now .. when there is a spec update in 2016 it will be 2015 -2016)
In the footer it also only says 2015.

I have some remarks/questions 

chapter 2.

" It should be possible to identify the sender and receiver of the envelope."
	Should that be split in two requirements where the receiver is always mandatory but the sender is optional? (in line with MSGE-04)

" It should be possible to transport digitally signed and encrypted payload within an envelope."
	If we say the envelope specification is payload "agnostic" then why this special requirement? Is it up to the "creator" of the envelope to sign and encrypt the payload? Or should that payload already be delivered in encrypted/signed format? And are these two options (signing and encryption) always combined or can they be independent from each other (so signed and not encrypted, encrypted not signed, both encrypted and signed or nothing)

" An envelope must be able to carry sufficient information about its included payload allowing the recipient to decide the appropriate processing of the payload."
	This implies that payload meta data describing the actual payload should always be present .. but isn't the interpretation of the payload and the actual processing of the payload not based on the actual payload it self, and so not a element of the "envelope"?

" It should be possible for the receiver to verify the integrity of the payload after decryption."
	Again ... isn't this the responsibility of the payload creator to allow for this .. and not a function of the envelope. 

Chapter 2.1
" The following requirements have been identified for enabling routing of an envelope and its payload through one or more transport networks."
	Why the "payload" in this context .. once the payload is enclosed in the envelope then the envelope should be routed .. and not be based on the contents.

" MSGE-05 An envelope should contain information about identification schema used to issue the ID of the party that originated the envelope and the ID of the party to which the envelopes payload is destined."
	The envelope is destined for a receipiant .. not the payload (although that is inside the envelope .. and there for ends up at that recipient)

" MSGE-06 To be able to support use of multiple address registries (e.g. similar to PEPPOL SML) the
envelope should have the ability to identify where the sender and receiver are registered. An example
of use would be that one registry is used for commercial invoices while another may be used for customs
information. A receiver may have identical identifiers in the two registries while the service addresses
may be different."

	Is this a further specification of requirement MSGE-04 and MSGE-07? Or a separate requirement? They way I read it this is a further specification about how the sender/receiver are identified.

Should these requirements be in a "logical" order? Now we already say something about the recipient in MSGE-05 and MSGE-06 where the recipient itself is first defined in MSGE-07

Also 2.1 says something about "routing" but things like the date/time of the envelope, one or more payloads and payload identification are not routing related. So should we have a more "generic requirements" section?

Chapter 2.2
" MSGE-12 It should be possible to identify the type of each payload instance in the envelope in order to
enable a Service registry lookup to verify and identify the type of payload."
	Should this not be a requirement of the payload it self instead of the envelope?

" MSGE-13 An envelope may need to contain a reference to a relevant business case, documents or
other issues that are relevant when determining how to handle the envelope and its content. An example
would be an envelope containing a tender in which case a reference to the relevant call for tender is
necessary in order to determine when opening the envelope content is allowed."
	Should this information not be explicit on the envelope instead of being derived from the payload? So a "do not look at payload before ..." indentifier or something like that?

" MSGE-14 When an envelope carries multiple payloads it needs to be possible to give indication of what
is the primary payload instance in the envelope."
	If the envelope contains multiple payloads then I think it should be up to the actual payloads to identify that they relate to an other document, not on the actual envelope.

" MSGE-15 When a payload instance is used for a single business document, it should be possible to
state the Business Transaction it represents, the Syntax Message in which it is expressed, the set of
business rules (Customization) applicable and the Profile in which it is used."
	Should these all be split into separate requirements? And should al this information not also be available INSIDE the payload it self and therefor not be element on the envelope?
	We also run the risk that this might be perceived as "too UBL centric" .. or is the use of ProfileID/CustomizationID generic enough and also applicable for other syntaxes/standards?

" MSGE-16 When a payload instance is used for a single business document, it should be possible to
identify the service appropriate for processing of the business document. I some cases these may be
calculated based on information covered by MSG-15 (e.g. PEPPOL), but this it not necessarily always
the case."
	This looks like additional information that should be used to construct the uniquely identifier of the recipient of the envelope? And what if there are multiple payloads? Then you can not add these details?

MSGE-15 and MSGE-16 are specified as "Payload" related attributes .. but in reality they are used for routing (looking up the service where the envelope should be posted to) .. so should these be promoted to the envelope level instead on the payload where they are now?

"MSGE-18 It should be possible to include a hash total of each of the payload instances, calculated over
the unencrypted content of that payload, and to identify the algorithm that was used to calculate the
hash."
	How do you deal with "encrypted" contents? Do you mean that the hash should be calculated BEFORE the encryption takes place of the payload contents? Or is this a hash over the actual payload contents (so even encrypted contents). And why per payload? Or should there be a hash over the envelope contents as a whole? So the recipient can verify the envelope as a whole? (looks like we missing that requirement currently)

I'm asking these questions just to get good clarification about what each requirement means and how it should be interpreted.
The rest of the document was "technical" and I think we should first get these questions clarified before I go into the technical details in order to not repeat the same questions.

Kees

p.s. I also agree with the Signature at the end of the envelope and not in an extension. 


-----Oorspronkelijk bericht-----
Van: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] Namens G. Ken Holman
Verzonden: dinsdag 17 februari 2015 18:12
Aan: Business Document Exchange TC
CC: Martin Forsberg
Onderwerp: [bdxr] Business Document Envelope Committee Specification Draft 01 Working Draft 03 now available for internal review 

In anticipation of BDXR committee members agreeing to my disposition of the comments received from Martin:

   https://lists.oasis-open.org/archives/bdxr/201502/msg00008.html

... I have prepared Working Draft 03:

   https://www.oasis-open.org/committees/document.php?document_id=55124

I was able to incorporate the W3C digital signature 1.1 schemas.  The test files continue to work with the revised W3C schemas.  We can await feedback regarding the XAdES schemas from our public review (unless someone on the committee knows how we can check this).

I have repaired the copy/paste error of cardinality for the payload content.

I received approval from OASIS TC Administration on the namespaces, and so they are now documented.

I have removed the reference to the empty "xml/" directory of examples since we don't have any examples to include.  We can incorporate examples that are created in conformance with these draft schemas.  Remember there are a few simple examples for testing purposes found in the "val/" directory.

I still need help rewriting any prose that needs to be better worded.

"See" you at tomorrow's BDXR committee conference call.  Please post your questions or bring your questions to the meeting.

. . . . . . . Ken

--
Check our site for free XML, XSLT, XSL-FO and UBL developer resources | Free 5-hour lecture:  http://www.CraneSoftwrights.com/links/video.htm |
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/o/ |
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com |
Google+ profile:       http://plus.google.com/+GKenHolman-Crane/about |
Legal business disclaimers:     http://www.CraneSoftwrights.com/legal |


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



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