Doug asked on 09/12/2002 04:05:49 PM: > When it comes to inline ATTACHMENTs, the CUA only needs to uniquely > identify the contents of the ATTACHMENT value in the old-values in > order to delete them. When the CS compares the attachment data it is > compared in its binary form. The ATTACHMENT value supplied by the > CUA MUST BE valid encoded information. > > We should change 'to delete them' to 'to delete or modify them' > Last sentence is going to be deleted. > > Would that solve the issue?
Not quite. The text still only refers to 'inline ATTACHments' (casing adjusted to be accurate). It needs to also address external to store and multipart instances too. Removing 'inline' may achieve that (but I have not fully tried all possible cases to confirm this).
The only action that I see as being possibly confusing is mulitple concurrent modifications unless you simply expect the CS to delete _any_ old ATTACHment and then add the new one(s) in their place (since there is no way to match the ATTACHments in the 'old data' w/their corresponding mates in the 'new data').
With MODIFY, yes you can, you specify the initial part of what makes each ATTACH unique:
CMD:MODIFY BEGIN:VEVENT #OLD Attach values ATTACH;VALUE=BINARY:lsfjjds121 ATTACH;VALUE=BINARY:lsfjjds122 END:VEVENT BEGIN:VEVENT #NEW ATTACH;VALUE=BINARY:lsfjjds123........<all of data>... ATTACH;VALUE=BINARY:lsfjjds124........<all of data>... END:VEVENT
This is also true of any property that can be multiinstanced in a single entity so explicitly codifying this for all implementors is probably a good idea.
The only limitation is if ALL of those multiinstance properties had EXACTLY the same value and parameters (which is doubtful).
CMD:MODIFY BEGIN:VEVENT #OLD Attach values PROP;param1=a:value1 PROP;param2=a:value1 END:VEVENT BEGIN:VEVENT #NEW PROP:param1=b:value1 PROP:param2=b:value1 END:VEVENT
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature