Subject: [mile] Comments on rfc6046-bis-05

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 11 Jan 2012 18:20:46 -0500

Kathleen, et al,

After reviewing the document it is not clear to me if all the HTTP status codes are correct in Table 1.  

Considering the HTTP status codes used:

http://datatracker.ietf.org/doc/rfc2616/?include_text=1

200 OK - indicates that "the request has succeded."
202 Accepted - indicates that "the request has been accepted for processing, but the processing has not been completed."

The callbacks defined in table 1 provide a mechanism to asyncronously respond during various data flows. The 202 status code required for the callbacks indicate that the information provided in the request have been accepted, but not processed. It might make sense to use a 200 status code instead to indicate that the message has been received and processed as there is no futher mechanism defined for the receiver to acknowledge processing.  This is especially true for RequestAuthorization messages which should be immediately processable.

This also raises a question regarding rfc6045-bis-05. How would a RID system reject a Result or Report that has been posted? Reasons for rejection might be due to content contained in the message that would prevent the organization from accepting the message for legal or policy reasons. For example if the message contained information of a need-to-know or propriatary nature for which the receiving organization is not authorized. What would be the mechanism for communicating this rejection back to the submitter?

Sincerely,
David Waltermire

---

From: Brian Trammell <[email-masked]>
Date: Thu, 12 Jan 2012 09:58:36 -0600

Hi, David, all,

Thank you for the comments; comments thereon inline.

> The callbacks defined in table 1 provide a mechanism to asyncronously respond during various data flows. The 202 status code required for the callbacks indicate that the information provided in the…

Correct; this is an error in the table. The intention is that callbacks be answered with a 200. I'll correct this in the -06 rev of the document.

> This also raises a question regarding rfc6045-bis-05. How would a RID system reject a Result or Report that has been posted? Reasons for rejection might be due to content contained in the message t…

I'll leave this question to Kathleen to answer authoritatively; however AFAIK RID has no method for rejecting a report or result, because each such message is essentially declarative ("I saw this") -- aside from the authorizations and requests RID is fire-and-forget, and rejection is irrelevant as far as the reporter is concerned. Adding a mechanism to RID at this point to handle ack/nak would change this model.

Thanks again, and best regards,

Brian (as 6046-bis author)

---

From: <[email-masked]>
Date: Thu, 12 Jan 2012 14:11:22 -0500

Hello Brian,

If you take a look at section 7.3 of RID, you'll see that a possible response to a Report is a RequestAuthorization message.  The RequestAuthorization message name is misleading, hence David & Paul's request to rename it to Acknowledgement.  The RequestAuthorization responds with a 'yes', 'no', or 'pending' as the RequestStatus and a 'Justification' as to why the Report is rejected.

A Result is really just a slight variant of a Report message, but if there were problems with the format, you would need to provide that response.  Having it as a variant of the Report solves this use case.

Thanks,
Kathleen (as RFC6045-bis author)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Trammell
Sent: Thursday, January 12, 2012 10:59 AM
To: Waltermire, David A.
Cc: [email-masked]
Subject: Re: [mile] Comments on rfc6046-bis-05

Hi, David, all,

Brian (as 6046-bis author)
_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: <[email-masked]>
Date: Sat, 14 Jan 2012 11:10:29 -0500

Hi All,

The Result and Report are remaining as is in RFC6045-bis.  However, I will make it more clear that a status message (RequestAuthorization moving to 'Acknowledgement') can be a valid response to any message type in case of errors or the inability to process a message.  Nested within the TraceRequest example, it does say that if there is a problem with the Result message, the response is an Acknowledgement (using the new name) to provide the reason or 'Justification'.  I think the listings Paul suggested will help clear up this confusion.  I also went through all of the text to make sure this is very consistently described.  This is not a change, but making the text more clear.

Thank you,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, January 12, 2012 2:11 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mile] Comments on rfc6046-bis-05

Hello Brian,

Thanks,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Trammell
Sent: Thursday, January 12, 2012 10:59 AM
To: Waltermire, David A.
Cc: [email-masked]
Subject: Re: [mile] Comments on rfc6046-bis-05

Hi, David, all,