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] BDE requirements

Thanks, Kenneth, for the feedback!

At 2015-02-23 18:07 -0500, kenneth@alfa1lab.com wrote:
Yes, I agree with everything you wrote above. My question was if "PayloadInstanceEncryptIndicator" could be replaced with a "PayloadInstanceEncryptionMethod". The PayloadInstanceEncryptionMethod would be not-present if no encryption was used, and in case encryption was used would hold the algorithm used for encryption.

Forgive me for not expressing myself, but I understood your suggestion. My point was that I wasn't sure the particular encryption used was important to the envelope as it seemed a bit private to me. But if you think it is important, then I have no problem with the envelope including an indication of the encryption method.

But by conflating the two concepts into one data item, do we then need to standardize some value for "unspecified encryption type" for those users who do not wish to reveal the kind of encryption in use? I guess that remains an issue with me. Would we specify the "unspecified" value, or would trading partners?

Would you agree to having both information items you cite in your question? We would have both PayloadInstanceEncryptionIndicator to indicate that the payload is encrypted, and then, if desired, the user can populate PayloadInstanceEncryptionMethod separately.

Then we aren't conflating two concepts into one item and somewhat "forcing" the issue. The item is easily added to the data model, and it doesn't take anything away from what CEN/BII Architecture reviewed last week.

I'm not sure I understand or see the use case where both the ProfileID and ServiceID would be present, but I'm not religiously opposed to having both of them in the spec either. If you believe that the necessity is there then no objection from me.

Ah, but I was only giving you my interpretation of why I thought CEN/BII had the two requirements MSGE-16 and MSGE-15 ... they seem to think that MSGE-15 is insufficient and MSGE-16 is needed:

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.

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.

Personally, I can't see it ... but it has come up in their requirements and I would worry that we are taking something away from what they've already assessed as suitable.

Is there any scenario where the business envelope software would need to know the CustomizationID? Will anyone ever need to know the CustomizationID except for understanding how to read the business document? For service routing etc. we already have the ProfileID and ServiceID.

Well, perhaps the recipient needs to know the CustomizationID to know which encryption method is used between trading partners in a community when the encryption method is not specified.

But that is just speculation.

I understand my position of "copy the metadata into the envelope so that the recipient can see the metadata without seeing the document" does not indicate any kind of boundary. And I didn't think the metadata would go all the way to the Invoice ID and the Tax Point Date and those other metadata-kind-of-thingies that we have under the document element. But I did think that that kind of business context metadata common to every document (in UBL's case) would be useful, if not to the envelope software then to the recipient. And the recipient will have different envelope software than an intermediary would have.

Those fields of metadata are distinguished in that they are common to every document in the suite ... so I think they have a different status than other children of the document element. And I think they can be exposed in the envelope without revealing anything at all about the contents of other fields.

So are we introducing a requirement for a third party to get involved in the creation of the envelope (in certain use cases at least)?

Requirement? No. I'm just thinking that vendors can offer agent services to users so that users don't have to implement it themselves. The documents can be sent using their own trusted transmission to their agent to then forward on the public networks.

The editing task includes changing all the hyperlinks from the components
to the requirements.

Anything I can do to help you just let me know!

Thanks, but I see that the XML is straightforward, so I think I can use some regular expressions.

BTW, I like the way that you suggest in the spreadsheet the positional importance of the primary payload. Simple. Well done. That prevents the community having to address what I brought up in the conference call when two payloads both indicate that they are primary: "It is up to the user community to define the interpretation of more than one payload indicating that it is primary." Now they don't have to do that.

So as an intermediate step I've updated the model by adding the encryption method and removing the primary indicator:


Of course anything can still change if you don't agree with my comments above.

. . . . . . . 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.

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