Subject: [mile] Question on RFC 6546 Table 1

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

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

---

From: "Davidson II, Mark S" <[email-masked]>
Date: Wed, 6 Jun 2012 18:15:37 +0000

John,

I think you're correct in that the X indicates that callback is not allowed. The RFC has the following to say about Query and callback:

RID systems MUST be prepared for a query to be met with a 202

   Accepted, an empty Response body, a connection termination, and a

   callback.

As a result, the Query message must be able to have a callback. Since all query messages have a blank value in the callback column, the blank value must mean allowed.

Given that, the bottom two rows seem to be a bit confusing since they are the same except for the Callback column.

-Mark

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,

Regards,
John

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

---

From: Brian Trammell <[email-masked]>
Date: Tue, 12 Jun 2012 10:18:13 +0200

Hi John, Mark, all,

Writing (again) as the author of RFC 6546.

In Table 1, an X in the Callback column means that the exchange itself IS a callback, in response to an earlier request which returned 202 in response.

A result code of 202 in the Result column indicates the result is deferred, and a callback will 
follow.

As for the two bottom rows of the table, this indicates that Reports may be sent either asynchronously, or as callbacks; the way for a receiving RID system to differentiate among these is by the presence of the RID-Callback-Token entity header field.

Perhaps replacing the table with a list of the permissible interactions would clarify things:

Request -> Acknowledgement (200)
Request -> (202) / Acknowledgement (callback) -> (200)

... and so on?

I'm not sure how to handle such as an editorial erratum, though. A side question: is the text in paragraphs 6-9 of Section 3 clear on how callbacks work, aside from the table?

Best regards,

Brian

On Jun 6, 2012, at 8:15 PM, Davidson II, Mark S wrote:

> John,
>  
> I think you’re correct in that the X indicates that callback is not allowed. The RFC has the following to say about Query and callback:
> From: [email-masked] [mailto:[email-masked]] On Behalf [email-masked]
> 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.
>  
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: "Davidson II, Mark S" <[email-masked]>
Date: Tue, 12 Jun 2012 12:20:56 +0000

Brian,

Thank you for your response.

I think for me, a more flow-chart type diagram would be useful. Of course these are hard to represent in an RFC.

I do think that Section 3, paragraphs 6-9 are easy to understand.

The specification has been pretty easy to get so far. Regarding GET/HEAD, it makes total sense that a RID Peer should never use those methods and that non-PEERS shouldn't even have a request served. However, during development of such a system, the option of specifying messages is useful for debugging.

Thank you.
-Mark

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Tuesday, June 12, 2012 4:18 AM
To: <[email-masked]>
Cc: [email-masked]; Davidson II, Mark S
Subject: Re: [mile] Question on RFC 6546 Table 1

Hi John, Mark, all,

... and so on?

Best regards,

Brian

---

From: <[email-masked]>
Date: Wed, 20 Jun 2012 16:51:53 -0400

Hi Brian,

Thanks for your reply.  This helps.  

Aside from the table itself, the text in paragraphs 6-9 of Section 3 is clear enough on how callbacks work.  At minimum, I think the following sentence from your recent reply should find its way into the RFC text.  

"In Table 1, an X in the Callback column means that the exchange itself IS a callback, in response to an earlier request which returned 202 in response."

However, if we are going to make any change then we might as well say a bit more, essentially summarizing some of the other clarifying comments on this thread.  

I'd suggest something like:

"In Table 1, an X in the Callback column means that the exchange itself IS a callback.  In these cases the HTTP request contains a RID message that is intended to conclude an earlier RID exchange which initially returned 202.   Note that RID Acknowledgment and RID Result messages can only ever appear in an HTTP request when the message is being generated as a Callback.  However, a RID Report message that appears in an HTTP request may represent either a unsolicited Report, or a delayed Callback.  It is important to note that any RID message that is sent as a Callback must be answered with a 200, and so cannot itself generate yet another Callback."

With these (or similar) clarifying remarks, I think the presentation of the message exchanges as shown in table 1 is fine.  IMHO, there is no need to switch the presentation style to show the complete list of permissible interactions.   

Finally, the existing discussion of the construction and handling of the callback token is fine.

Hope this helps.

Thanks,
John

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Tuesday, June 12, 2012 4:18 AM
To: <[email-masked]>
Cc: Field, John; Davidson II, Mark S
Subject: Re: [mile] Question on RFC 6546 Table 1

Hi John, Mark, all,

... and so on?

Best regards,

Brian