VerifyRecoveryLockResponse -
- in this response, we do not get a key as VerifyRecoveryLock like its seen in VerifyFirmwarePasswordResponse where we get a key as VerifyFirmwarePassword.
- So should we rely only on the commanduuid to map to type of response and handle result accordingly for this type?
<dict>
<key>CommandUUID</key>
<string>08b5bfb1-b547-43b4-b453-340a0dadeb7d</string>
<key>PasswordVerified</key>
<true/>
<key>Status</key>
<string>Acknowledged</string>
<key>UDID</key>
<string>B29422F1-756E-5370-966E-3A6E9E969096</string>
</dict>
.
SetRecoveryLockResponse -
- in this response also we do not get a key to identify acknowledgement as 'SetRecoveryLockResponse' ( but we can identify with the CommandUUID) .
- we do not have any field as 'PasswordChanged' to confirm if its already changed like we have for SetFirmwarePasswordResponse.
<dict>
<key>CommandUUID</key>
<string>d19f5ac9-31be-4cd9-9e20-0b034108855a</string>
<key>Status</key>
<string>Acknowledged</string>
<key>UDID</key>
<string>B29422F1-756E-5370-966E-3A6E9E969096</string>
</dict>
even though we could compare commanduuid, it would have been better if we also get the