The encryptionAlgorithm parameter is still needed. It can't be depreceated.

The comments I made were meant to indicate that the securityPolicyUri could have been put in this field instead of encryptionAlgorithm. Not that the field is unneeded.

Hey Randy,

Based on what you're saying, the securityPolicyUri and the encrpytionAlgorithm can/should contain the same value?

Seems like a clarification in the spec is still needed though. We will discuss your feedback on the cmpwg call shortly, and will post a note back in here. Thanks.

If you are writing code that encrypts/decrypts then the encrpytionAlgorithm is the most useful value to have since there can be many security policies that use the same encrpytionAlgorithm.

It also means your encrypts/decrypts code does not need to be updated if new security policies are created if those policies reuse the same encrpytionAlgorithm.

However, fooling around with two different URIs in the API can be a hassle which is why I said the security policy URI probably should have been used instead.

CMPWG Sep-8-2011 discussed this again and we're still not clear. Unfortunately we did not see the last comment from Randy (09-08-11 09:17).

Randy's last comment (09-08-11 09:17) is the clearest yet, and it would indicate that the 2 parameters are quite different. However, one could still interpret these parameters are containing the same value.

The CMPWG (having NOT seen the comment: 09-08-11 09:17) felt that some clarification is needed in the spec still.

Add an explict statement that the encryptionAlgorithm is not the same as the securitypolicyuri.

Added the following clarification to Table 173:
"This string is not the same as the securityPolicyUri. It is the URI of the encryptionAlgorithm defined in the security policy."

Changed in document version OPC UA Part 4 - Services 1.02.07 Draft.doc

Reviewed in F2F

Made the text wording more explicit.