Subject: [mile] FW: Question on RFC 6546 Table 1

From: <[email-masked]>
Date: Tue, 5 Jun 2012 12:30:08 -0400

P.S.  If appropriate and/or necessary, I can file an errata for this.  Any guidance appreciated.

Thanks,
John

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, June 05, 2012 12:24 PM
To: [email-masked]
Subject: [mile] Question on RFC 6546 Table 1

All,

I have read through RFC 6546 and, after several passes, I find that I still need some help interpreting Table 1.   I would like to confirm my understanding of the intent of the column labeled "Callback" and the presence of the corresponding X's in that column.

My understanding is that the X is used to indicate that the callback option is NOT supported for the indicated RID Request message, and the sender of such as message should not expect to provoke any callback, and the receiver is forbidden from producing one.   So, for example, the Acknowledgment in row 12 could potentially be the "Ack" Reponse that is delivered as a follow-on from an earlier 202 response, such as shown in rows 4 or 8.   As such, there is no provision for yet another callback when sending that Acknowledgement.  Is this correct?

Similarly, row 13 of Table 1 shows a Result message, with an expect response of 200 status and no response body.   Based on the "X" in the Callback column, I would interpret that to mean that no Callback is supported or should be expected by the RID system that initiated this message outbound.    The use case in row 13 would appear to be needed to support an asynchronous reply to row 4.  That is, an earlier InvestigationRequest message that was met with an initial 202 response.

In general, it seems that each of the rows that contain an "X" is there to cover the use case of a message that is itself being sent as an asynchronous response to a message that was received earlier?

If my interpretation is correct, then I suggest the following clarification:  the column heading "Callback" should be updated to be "Callback Supported", or something similar, and the values in that column be changed to indicate "Yes" or "No" as appropriate.

In addition, some more explicit discussion of the nature of the message exchange pattern should be included.   Perhaps include an example flow as I've described here.    At minimum, I would suggest that the text should explicitly state that the messages shown in rows 12, 13, and 16 are defined in connection with 4, 8, and 11, and as such, no additional callback is allowed.

If my understanding is not correct, please advise.

Regards,
John

// John P. Field
// Security Architect
// EMC Office of the CTO
// mailto: [email-masked]
// http://www.emc.com