KMIP-interop-tech

Please find the attached latest Thales Interop report. Do let me know if the results are unexpected. There were minor unexpected results with some servers which is yet to be reviewed. Our Interop server is still up and available for testing. Regards, Saran Attachment: KMIPInteropResults-Jul2012-MASTER_v1.0_Thales_v2.xls Description: KMIPInteropResults-Jul2012-MASTER_v1.0_Thales_v2.xls

All, Please find attached the current IBM status from the latest KMIP interop. I don't have a workable way to go through our server-side logs to see which clients were successfully able to run which use case, so I have left that sheet empty. I have worked with the individual participants to try to resolve any issues they ran into when running their clients against our server, but if there are any unreported issues still outstanding please let me know. Regards, Mathias Attachment: KMIPInteropResults-Jul2012-IBM-v1.xls Description: MS-Excel spreadsheet

We have collated the results from the July testing using the following approach: 1) if any vendor indicates an issue, that issue is noted as accepted unless a majority of other vendors disagree with the result 2) where insufficient results were gathered no results are reported Overall we have more functionality demonstrated as interoperable across the vendors participating and that's great to see. Thanks to everyone for the efforts invested in testing. Given that we did not complete enough independent test runs with our C# client SDK we have removed it from the results for this round. There are a number of non-conformance issues noted against the Cryptsoft Java server which were not resolved during the test period (most of those are directly part of attribute index handling issues). When an update is available we will announce that to the list so re-testing can be performed. The non-compliant NetApp result (now split into four test cases) related to Object Group and templates and will be part of further discussions related to templates - however servers which treat an Object Group registered in a template structure as applying to the template itself are non-conforming as Object Group is explicitly noted in 2.2.6 and this is the consensus interpretation between vendors and reflected in the majority of implementations. We may not yet have consensus on what GET on a template returns - but we do have a clear majority on how Object Group is handled. The Quintessence server had a number of updates during the testing and the testing reports are mixed so a consensus view from the test reports has been used. As always, any errors in merging the results should be noted quickly. I would like to get this report out to the wider TC group next week along with another summary report updating the last one from the face to face. Thanks, Tim. Attachment: KMIPInteropResults-Jul2012-MASTER_v1.1-combined.xls Description: MS-Excel spreadsheet

> related to templates - however servers which treat an Object Group > registered in a template structure as applying to the template itself > are non-conforming as Object Group is explicitly noted in 2.2.6 and this > is the consensus interpretation between vendors and reflected in the Agreed. > majority of implementations. We may not yet have consensus on what GET > on a template returns - but we do have a clear majority on how Object > Group is handled. I'd like us to talk about what LOCATE means for a template too. Does it make sense for LOCATE on a template specifying an attribute that is not an attribute of the template itself, but one that is applied to objects CREATE'd using the template, to return the template UIDs that contain this attribute? I think the specification is unclear on this. Strictly, perhaps, the answer should be no, but maybe templates are a special case where we should say, yes. It could be very useful for clients to perform LOCATE operations on templates to find, for example, all templates that contain a specific object group attribute, or cryptographic algorithm attribute, etc. John

On 16/08/2012 8:53 PM, John Leiseboer wrote: Strictly, perhaps, the answer should be no, but maybe templates are a special case where we should say, yes. Actually I think the specification is very clear on this - LOCATE is related to attributes of the managed object - so I don't see where there is an avenue to argue that the answer is anything other than no. If you can see wriggle room in the text in LOCATE it would be good to outline that logic - but that would have to be about LOCATE itself and not in the various sections of the specification referring to templates. What GET on a template returns is underspecified - I still think it is clear - in that it should return the template structure exactly as it was provided in the REGISTER request and that other interpretations are stretching interpretation - however some of the text hints at possible other interpretations. We clearly need to document this area (templates) better and to include some additional test cases aimed at outlining what is expected to reduce the interoperability challenges in the short term. Tim.

I have interpreted the answer to be yes. I couldn't find any text in the Locate section of the spec where we differentiate between attributes that apply to the managed object and attributes that apply to managed objects created using the managed object (template). Having Locate on template objects apply to only the attributes that apply to the template itself seems to be of limited value. Regards, Mathias From: Tim Hudson <tjh@cryptsoft.com> To: "kmip-interop-tech@lists.oasis-open.org" <kmip-interop-tech@lists.oasis-open.org> Cc: "Karadigudda, Mahadev" <Mahadev.Karadigudda@netapp.com> Date: 16.08.2012 13:06 Subject: Re: [kmip-interop-tech] Draft combined summary report Sent by: <kmip-interop-tech@lists.oasis-open.org> On 16/08/2012 8:53 PM, John Leiseboer wrote: Strictly, perhaps, the answer should be no, but maybe templates are a special case where we should say, yes. Actually I think the specification is very clear on this - LOCATE is related to attributes of the managed object - so I don't see where there is an avenue to argue that the answer is anything other than no. If you can see wriggle room in the text in LOCATE it would be good to outline that logic - but that would have to be about LOCATE itself and not in the various sections of the specification referring to templates. What GET on a template returns is underspecified - I still think it is clear - in that it should return the template structure exactly as it was provided in the REGISTER request and that other interpretations are stretching interpretation - however some of the text hints at possible other interpretations. We clearly need to document this area (templates) better and to include some additional test cases aimed at outlining what is expected to reduce the interoperability challenges in the short term. Tim.

I have also interpreted the answer to be yes, that Locate of any attribute of the template will find the template regardless of whether or not the attribute applies to the template object itself, or to objects created by the template. Although there is this in section 2.2.6, None of the client-settable attributes specified in a Template except the Name attribute apply to the template object itself, but instead apply to any object created using the Template, there is nothing written about Locate that differentiates. It may be useful to search for templates by any attribute, and so language could be added to the Locate operation 4.9 to make the answer explicitly yes . For Get on a template, I understand it to return attributes of the template that are applied to objects created by the template. This may be what was passed in on the Register, but I don't think it should be explicitly tied by definition to the Register operation. Regards, Jim Flood On 8/16/2012 6:53 AM, Mathias Bjoerkqvist1 wrote: I have interpreted the answer to be yes. I couldn't find any text in the Locate section of the spec where we differentiate between attributes that apply to the managed object and attributes that apply to managed objects created using the managed object (template). Having Locate on template objects apply to only the attributes that apply to the template itself seems to be of limited value. Regards, Mathias From: Tim Hudson <tjh@cryptsoft.com> To: kmip-interop-tech@lists.oasis-open.org <kmip-interop-tech@lists.oasis-open.org> Cc: Karadigudda, Mahadev <Mahadev.Karadigudda@netapp.com> Date: 16.08.2012 13:06 Subject: Re: [kmip-interop-tech] Draft combined summary report Sent by: <kmip-interop-tech@lists.oasis-open.org> On 16/08/2012 8:53 PM, John Leiseboer wrote: Strictly, perhaps, the answer should be no, but maybe templates are a special case where we should say, yes. Actually I think the specification is very clear on this - LOCATE is related to attributes of the managed object - so I don't see where there is an avenue to argue that the answer is anything other than no. If you can see wriggle room in the text in LOCATE it would be good to outline that logic - but that would have to be about LOCATE itself and not in the various sections of the specification referring to templates. What GET on a template returns is underspecified - I still think it is clear - in that it should return the template structure exactly as it was provided in the REGISTER request and that other interpretations are stretching interpretation - however some of the text hints at possible other interpretations. We clearly need to document this area (templates) better and to include some additional test cases aimed at outlining what is expected to reduce the interoperability challenges in the short term. Tim.

I too couldn’t find anything in the Locate section of the specification that differentiates between attributes in Templates.   This is really all that the spec says: “4.9 Locate This operation requests that the server search for one or more Managed Objects depending on the attributes specified in the request.”   There are no words elaborating on which attributes should be used for Templates.   johnl   From: kmip-interop-tech@lists.oasis-open.org [mailto:kmip-interop-tech@lists.oasis-open.org] On Behalf Of Jim Flood Sent: Friday, 17 August 2012 12:12 AM To: kmip-interop-tech@lists.oasis-open.org Subject: Re: [kmip-interop-tech] Draft combined summary report   I have also interpreted the answer to be yes, that Locate of any attribute of the template will find the template regardless of whether or not the attribute applies to the template object itself, or to objects created by the template. Although there is this in section 2.2.6, "None of the client-settable attributes specified in a Template except the Name attribute apply to the template object itself, but instead apply to any object created using the Template," there is nothing written about Locate that differentiates. It may be useful to search for templates by any attribute, and so language could be added to the Locate operation 4.9 to make the answer explicitly "yes". For Get on a template, I understand it to return attributes of the template that are applied to objects created by the template. This may be what was passed in on the Register, but I don't think it should be explicitly tied by definition to the Register operation. Regards, Jim Flood On 8/16/2012 6:53 AM, Mathias Bjoerkqvist1 wrote: I have interpreted the answer to be yes. I couldn't find any text in the Locate section of the spec where we differentiate between attributes that apply to the managed object and attributes that apply to managed objects created using the managed object (template). Having Locate on template objects apply to only the attributes that apply to the template itself seems to be of limited value. Regards, Mathias From: Tim Hudson <tjh@cryptsoft.com> To: "kmip-interop-tech@lists.oasis-open.org" <kmip-interop-tech@lists.oasis-open.org> Cc: "Karadigudda, Mahadev" <Mahadev.Karadigudda@netapp.com> Date: 16.08.2012 13:06 Subject: Re: [kmip-interop-tech] Draft combined summary report Sent by: <kmip-interop-tech@lists.oasis-open.org>   On 16/08/2012 8:53 PM, John Leiseboer wrote: Strictly, perhaps, the answer should be no, but maybe templates are a special case where we should say, yes. Actually I think the specification is very clear on this - LOCATE is related to attributes of the managed object - so I don't see where there is an avenue to argue that the answer is anything other than no. If you can see wriggle room in the text in LOCATE it would be good to outline that logic - but that would have to be about LOCATE itself and not in the various sections of the specification referring to templates. What GET on a template returns is underspecified - I still think it is clear - in that it should return the template structure exactly as it was provided in the REGISTER request and that other interpretations are stretching interpretation - however some of the text hints at possible other interpretations. We clearly need to document this area (templates) better and to include some additional test cases aimed at outlining what is expected to reduce the interoperability challenges in the short term. Tim.  

After today's call - we agreed to update the template related item as ambiguous rather than non-compliant while we work out the discussions related to templates and attributes. The update is attached. Tim. Attachment: KMIPInteropResults-Jul2012-MASTER_v1.2.xls Description: MS-Excel spreadsheet

The interop call will be on this week 30 minutes prior to the main call. Agenda 1) review and discuss combined results. 2) templates Thanks, Tim.

Given that we have no more material on the templates topic and no objections to the results spreadsheet update sent last week we won't have a interop call this week. I'll be sending out result summaries to the main list before the main call. Thanks, Tim.

The interop call is on this week 30 minutes prior to the main TC call. Note: Bob sent out a new number for the main TC call and we will be using that new number too. If you don't have it then email me. Agenda: Templates Thanks, Tim.

Given the large set of work items from the face to face meetings last week there is no interop call this week. Thanks, Tim.

Given the large set of work items from the face to face meetings last week there is no interop call (again) this week. If everyone could indicate either to me or to the kmip-interop-tech list if next week (Oct-4th) is good timing for initial discussions about planning for the RSA2013 interop demonstration - if so then we can start that process. I anticipate the same approach as previously with agreements of what we will be trying to demonstrate, pre-testing in December followed by a more formal two week pre-event interop test in mid-Jan where we confirm we are in good shape for the event. I expect we will have a mix of KMIP 1.0, KMIP 1.1 and KMIP pre-1.2 capabilities being demonstrated with a mix of supported features between vendors. Jane/Dee if you can encourage those vendors who have signed up for the interop to join the interop tech mailing list that would help getting everyone on the same page. Thanks, Tim.

If any other vendor is interesting in performing testing for any or all of the following operations - Validate, DeriveKey, Notify, Put - please drop me a note. Thanks, Tim.

Attached are minutes (thanks Tony) for the call. Any corrections either to myself or to the list. The next call will be 30 minutes prior to next weeks KMIP TC call on the same dial-in number as the main call. Contact myself or Bob Griffin for the dial-in details if you do not have them. If each vendor could start confirming that they will be able to work within the rough schedule prior to next weeks call that would be ideal. Thanks, Tim. Attachment: InteropTech-Minutes-04-Oct-2012.pdf Description: Adobe PDF document

The interop call will be 30 minutes prior to this weeks KMIP TC call on the same dial-in number as the main call. Contact myself or Bob Griffin for the dial-in details if you do not have them. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2012&month=10&day=11&hour=19&min=30&sec=0&p1=47&p2=224&p3=179&p4=268 Agenda: - confirmation of rough schedule status (as per minutes) - moving test cases to profiles - testing for Notify and Put Thanks, Tim.

Attached are minutes (thanks Tony) for the call. Any corrections either to myself or to the list. The next call will be 30 minutes prior to next weeks KMIP TC call on the same dial-in number as the main call. Contact myself or Bob Griffin for the dial-in details if you do not have them. Each vendor needs to confirm that they will be able to work within the rough schedule prior to next weeks call so we can lock in the planning. Thanks, Tim. Attachment: InteropTech-Minutes-12-Oct-2012.pdf Description: Adobe PDF document

The interop call will be 30 minutes prior to this weeks KMIP TC call on the same dial-in number as the main call. Contact myself or Bob Griffin for the dial-in details if you do not have them. Agenda: - re-confirmation of rough schedule status (as per minutes) - moving test cases to profiles Thanks, Tim.

Attached are minutes (thanks Tony) for the call. Any corrections either to myself or to the list. The next call will be 30 minutes prior to next weeks KMIP TC call on the same dial-in number as the main call. Contact myself or Bob Griffin for the dial-in details if you do not have them. Each vendor needs to confirm that they will be able to work within the rough schedule prior to next weeks call so we can lock in the planning. Thanks, Tim. Attachment: InteropTech-Minutes-18-Oct-2012.pdf Description: Adobe PDF document

The interop call will be 30 minutes prior to this weeks KMIP TC call on the same dial-in number as the main call. Contact myself or Bob Griffin for the dial-in details if you do not have them. Agenda: - Confirmation of RSA Conference 2013 Interop participants - Agree interop schedule dates - Informal interop testing start/finish - Formal Interop testing start/finish - Publication of results - Conference timetable - Moving test cases to profiles - Notify & Put - Other items Thanks, Tim.

[[ Minutes from last week attached - I overlooked sending them out last week ]] The interop call will be 30 minutes prior to this weeks KMIP TC call on the same dial-in number as the main call. Contact myself or Bob Griffin for the dial-in details if you do not have them. Note: the main call time has adjusted for those of us outside of the USA - so check you are calling at the correct time. Agenda: - Confirm technical contact details for the seven RSA Conference 2013 Interop participants Cryptsoft, IBM, Quintessence Labs, SafeNet, Thales, Townsend, Vormetric - Confirm key interop schedule dates - Informal interop testing start/finish in early December 2012 - Formal Interop testing start/finish 14-25th Jan 2013 - Publication of results 29 Jan 2013 - Booth Logistics Update from Jane Harnad - Moving test cases to profiles update from Bob Lockhart / Tim Hudson - Other items Thanks, Tim. Attachment: InteropTech-Minutes-25-Oct-2012.pdf Description: Adobe PDF document

I've got a conflict with the interop call this week (I will be in transit between two meetings and I've figured out the logistics won't work) so the interop call won't be on as usual. It will resume again as normal not next week (the main call is not on for the thanksgiving week). The main call will be on as usual this week (Bob has already sent out the details and if you haven't got those please contact him). I hope to be in a quiet spot to be able to dial in for the main call. Any issues on changes of status should be emailed to this list or to the regular attendees so we can continue progressing towards the defined list of what will be tested. Thanks, Tim. Attachment: InteropTech-Minutes-25-Oct-2012.pdf Description: Adobe PDF document

The interop call will be 30 minutes prior to this weeks KMIP TC call on the same dial-in number as the main call. Contact myself or Bob Griffin for the dial-in details if you do not already have them. A couple of folks have indicated they are on vacation at the moment and might not be able to make this weeks call but should be able to participate from next week. Reminder: Jane has sent out more details on booth layout and the order of sign up of vendors and has commenced confirming the position selection. Please read that information carefully. Agenda: - Booth Logistics Update from Jane Harnad - Note key interop schedule dates - Informal interop testing start/finish 5-19 December 2012 - Formal Interop testing start/finish 14-25th Jan 2013 - Publication of results 29 Jan 2013 The objective is to confirm the list of vendors who will have servers available and credentials issued to other vendors for 5th December (mid next week) for informal testing in preparation for the formal interop in January. As per previous interop events, participation in the interop testing is required and conducted openly so please confirm readiness with your respective teams. Unlike previous interop events there will be a much wider range of capabilities demonstrated and a number of new server vendor participants which makes for additional challenges during testing. Thanks, Tim.

Attached. Any issues with the minute should be emailed either to myself or the interop list as a whole. Thanks, Tim. Attachment: InteropTech-Minutes-29-Nov-2012.pdf Description: Adobe PDF document

The interop call will be 30 minutes prior to this weeks KMIP TC call on the same dial-in number as the main call. Contact myself or Bob Griffin for the dial-in details if you do not already have them. Agenda: - Booth Logistics Update from Jane Harnad - Informal interop status update from each vendor - Note key interop schedule dates: - Informal interop testing start/finish 5-19 December 2012 - Formal Interop testing start/finish 14-25th Jan 2013 - Publication of results 29 Jan 2013 Thanks, Tim.

The interop call will be 30 minutes prior to this weeks KMIP TC call on the same dial-in number as the main call. Contact myself or Bob Griffin for the dial-in details if you do not already have them. Agenda: - Booth Logistics Update from Jane Harnad - Informal interop status update from each vendor - Note key interop schedule dates: - Informal interop testing start/finish 5-19 December 2012 - Formal Interop testing start/finish 14-25th Jan 2013 - Publication of results 29 Jan 2013 Thanks, Tim. Attachment: InteropTech-Minutes-6-Dec-2012.pdf Description: Adobe PDF document

Attached. Thanks to Tony. As always corrections should be sent to myself or the list. Thanks, Tim. Attachment: InteropTech-Minutes-13-Dec-2012.pdf Description: Adobe PDF document

Just a quick reminder - we are following the main TC call schedule which means no call this week, next week or the following week. The next call is before the 10 Jan (USA) weekly KMIP TC call. The informal interop testing continues with email exchanges to resolve issues. Thanks, Tim.

The interop call will be 30 minutes prior to this weeks KMIP TC call on the same dial-in number as the main call. Contact myself or Bob Griffin for the dial-in details if you do not already have them. Agenda: - Booth logistics updates from Jane Harnad - Confirmation of status from informal interop - Discussion on any unexpected test results - Profiles status update - Note key interop schedule dates: - Formal Interop testing start/finish 14-25th Jan 2013 (i.e. on Monday) - Publication of results 29 Jan 2013 As there have be some queries from vendors about the process for the formal interop I've outlined the steps noted from what we have used previously to make the requirements clearer to new participants. Interoperability testing shall be performed by each KMIP client implementation interacting with each server implementation, testing only the capabilities reported as being supported by the relevant server implementation participant. The following steps shall be performed: 1. KMIP client runs all relevant test cases against a given server 2. KMIP client records all requests and responses 3. KMIP server records all requests and responses 4. KMIP client and server participants compare results 5. KMIP client and server work to resolve any discrepancies 6. Where the results are agreed, KMIP client and server participants are to provide their completed reports for compilation 7. Where the results are not agreed, the issue is to be referred to the interop participants for resolution. Thanks, Tim.

Thanks to Tony updated minutes from the call today. Thanks, Tim. Attachment: InteropTech-Minutes-10-Jan-2013.pdf Description: Adobe PDF document

Attached is a summary of the process and a spreadsheet for recording results based on feedback from previous sessions and the ongoing discussions. This allows for each vendor to claim what is expected to work and for vendor-to-vendor testing results to be gathered in a form which is more easily reviewed. As we have a combination of testing that can be done it allows for recording claimed profile support for both KMIP 1.0 and KMIP 1.1 and test case support for both KMIP 1.0 and KMIP 1.1 and also includes the test cases from the two documents Bob Lockhart circulated which are the first step towards including test cases more closely matching profiles. There will be vendor testing which encompasses functionality beyond what is noted here given that we have a broader mix of capabilities but those won't be reported in any consolidated results and will be left to each of the vendors involved to note separately. I believe this reflects the consensus of the group and our discussions to date but if anyone feels differently please let me know so we can work through it. We have a busy two weeks ahead for this testing. Tony has volunteered to record the details and to handle the logistics of sending out vendor-to-vendor recording spreadsheets and collating the feedback which should also help speed up the process from previous years. Please read the process document and then fill in the capability register (all tabs) for each product involved in the interop testing including your contact details (if you are the responsible person for that product) and get this back to Tony via tony.cox@cryptsoft.com by COB tomorrow PST. The Cryptsoft C and Java servers have now been updated for the formal interop and are available for testing. Thanks, Tim. Attachment: KMIP Formal Interop Process-Jan 2013-Final.pdf Description: Adobe PDF document Attachment: Capability Register V1.2-Claimed.xlsx Description: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

The interop call is on again this week 30 minutes before the main call and we have a larger than usual number of items to cover off on. 1) Update from Jane Harnad on the latest OASIS information pack 2) Request for a change in interop handling a) one vendor has another server product they would like to make available in addition to the current product under test b) one vendor has a significantly updated server product they would like to make available for interop replacing the product that was originally proposed for the interop and used in informal testing 3) Feedback on interop process so far 4) Issues raised already: a) error in 11.2 step 2 as reported by Michael Stevens (see end of email) b) the operations list in the spreadsheets isn't complete c) the algorithms and key sizes are not in the spreadsheets d) other interop issues? 5) Status updates from each vendor on testing to date 6) Other items We have three ways to handle item 2 in the agenda: 1) remain with the current agreed approach and only those products that were available at the start of formal interop are permitted and must be used on the interop network at the RSA show [with only minor updates for reported issues during the formal interop] 2) agree unanimously to allow a new product and a significantly updated release into formal interop 3) take a special majority vote to allow a new product and a significantly updated release into formal interop If the group decision is to allow a variation of the rules we are operating under then I suggest that we stick with the current time frame and allow updates for the server test target spreadsheets until Monday morning at 9am GMT+10 (Australia/Queensland). We should also keep in mind that Bob Lockhart had additional profiles with tests which he held off distributing. Those could also be incorporated if we are restarting interop. I've discussed with a number of vendors this evening and the consensus so far appears to be that we should take a special majority vote (which we will interpret as 5 out of the 7 vendors must agree) to change from the originally agreed plan at the commencement of interop. This will mean updated claims spreadsheets and re-testing for all those vendors who have already tested where the client or server claims are different given if we do update we will fix the missing items in the spreadsheets. Please all have a clear view on which approach your organisation wants to take to resolving the issues raised. Thanks, Tim. ---8<--- Issue for a KMIP 1.0 test for 11.2 Step 2 (this is not an issue in the KMIP 1.1 test document) Document has: Tag: BATCH_ORDER_OPTION (0x420010), Type: BOOLEAN (0x06), Data: 0x0000000000000001 Tag: BATCH_ERROR_CONTINUATION_OPTION (0x42000e), Type: ENUMERATION (0x05), Data: 0x00000001 (CONTINUE) Tag: BATCH_COUNT (0x42000d), Type: INTEGER (0x02), Data: 0x00000002 It should be: Tag: BATCH_ORDER_OPTION (0x420010), Type: BOOLEAN (0x06), Data: 0x0000000000000001 Tag: BATCH_ERROR_CONTINUATION_OPTION (0x42000e), Type: ENUMERATION (0x05), Data: 0x00000001 (CONTINUE) Tag: BATCH_COUNT (0x42000d), Type: INTEGER (0x02), Data: 0x00000002 Please check your test programs and update to ensure they have the order of the fields in conformance with the specification.

Thanks to John too for pointing out my correction needs correcting as I cut'n'pasted the same incorrect fragment twice. Tim. ---8<--- Issue for a KMIP 1.0 test for 11.2 Step 2 (this is not an issue in the KMIP 1.1 test document) Document has: Tag: BATCH_ORDER_OPTION (0x420010), Type: BOOLEAN (0x06), Data: 0x0000000000000001 Tag: BATCH_ERROR_CONTINUATION_OPTION (0x42000e), Type: ENUMERATION (0x05), Data: 0x00000001 (CONTINUE) Tag: BATCH_COUNT (0x42000d), Type: INTEGER (0x02), Data: 0x00000002 It should be: Tag: BATCH_ERROR_CONTINUATION_OPTION (0x42000e), Type: ENUMERATION (0x05), Data: 0x00000001 (CONTINUE) Tag: BATCH_ORDER_OPTION (0x420010), Type: BOOLEAN (0x06), Data: 0x0000000000000001 Tag: BATCH_COUNT (0x42000d), Type: INTEGER (0x02), Data: 0x00000002 Please check your test programs and update to ensure they have the order of the fields in conformance with the specification.

Minutes from the call today. Please review and let me know if there is anything inaccurate in what has been captured given the discussions on the call today. Please specifically note the text in red in the minutes. Thanks, Tim. Attachment: Interop call 17Jan20103-Minutes-x.pdf Description: Adobe PDF document