From johnp.field@emc.com Tue Jun 5 09:24:32 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E7221F86AF for ; Tue, 5 Jun 2012 09:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhGdlP7cyVRi for ; Tue, 5 Jun 2012 09:24:29 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEC821F86A1 for ; Tue, 5 Jun 2012 09:24:21 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q55GOE3w004076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 Jun 2012 12:24:19 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Tue, 5 Jun 2012 12:23:55 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q55GNsY7004051 for ; Tue, 5 Jun 2012 12:23:55 -0400 Received: from mx14a.corp.emc.com ([169.254.1.157]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Tue, 5 Jun 2012 12:23:54 -0400 From: To: Date: Tue, 5 Jun 2012 12:23:51 -0400 Thread-Topic: Question on RFC 6546 Table 1 Thread-Index: Ac1DN5gFpfNeAjbxSBOXMnL0xEu/8A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B7873C71FEFD6E41B5468506E231FB6E32E199AAMX14Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] Question on RFC 6546 Table 1 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 16:24:32 -0000 --_000_B7873C71FEFD6E41B5468506E231FB6E32E199AAMX14Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 understa= nding of the intent of the column labeled "Callback" and the presence of th= e 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 Acknowledg= ement. Is this correct? Similarly, row 13 of Table 1 shows a Result message, with an expect respons= e of 200 status and no response body. Based on the "X" in the Callback co= lumn, I would interpret that to mean that no Callback is supported or shoul= d be expected by the RID system that initiated this message outbound. Th= e use case in row 13 would appear to be needed to support an asynchronous r= eply to row 4. That is, an earlier InvestigationRequest message that was m= et 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 asynchronou= s 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 Supporte= d", or something similar, and the values in that column be changed to indic= ate "Yes" or "No" as appropriate. In addition, some more explicit discussion of the nature of the message exc= hange pattern should be included. Perhaps include an example flow as I've= described here. At minimum, I would suggest that the text should explic= itly state that the messages shown in rows 12, 13, and 16 are defined in co= nnection 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: johnp.field@emc.com // http://www.emc.com --_000_B7873C71FEFD6E41B5468506E231FB6E32E199AAMX14Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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 conf= irm my understanding of the intent of the column labeled “Callback= 221; and the presence of the corresponding X’s in that column.  
 
My understanding is that the X is used to indicate that the callback o= ption is NOT supported for the indicated RID Request message, and the sende= r of such as message should not expect to provoke any callback, and the rec= eiver is forbidden from producing one.   So, for example, the Acknowledgment in row 12 could potent= ially be the “Ack” Reponse that is delivered as a follow-on fro= m an earlier 202 response, such as shown in rows 4 or 8.   As suc= h, 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 re= sponse of 200 status and no response body.   Based on the “= X” in the Callback column, I would interpret that to mean that no Cal= lback 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.&nb= sp; That is, an earlier InvestigationRequest message that was met with an i= nitial 202 response.  
 
In general, it seems that each of the rows that contain an “X= 221; 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?  <= /div>
 
If my interpretation is correct, then I suggest the following clarific= ation:  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 messag= e exchange pattern should be included.   Perhaps include an examp= le 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, a= nd 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: johnp.field@emc.com
// http://= www.emc.com
 
 
 
 --_000_B7873C71FEFD6E41B5468506E231FB6E32E199AAMX14Acorpemccom_-- From johnp.field@emc.com Tue Jun 5 09:30:35 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487C421F85EA for ; Tue, 5 Jun 2012 09:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9OIIJjfNZdr for ; Tue, 5 Jun 2012 09:30:32 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 22CF521F8722 for ; Tue, 5 Jun 2012 09:30:28 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q55GULdV010383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 Jun 2012 12:30:25 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Tue, 5 Jun 2012 12:30:12 -0400 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q55GUACo028389 for ; Tue, 5 Jun 2012 12:30:11 -0400 Received: from mx14a.corp.emc.com ([169.254.1.157]) by mxhub36.corp.emc.com ([::1]) with mapi; Tue, 5 Jun 2012 12:30:10 -0400 From: To: Date: Tue, 5 Jun 2012 12:30:08 -0400 Thread-Topic: [mile] Question on RFC 6546 Table 1 Thread-Index: Ac1DN5gFpfNeAjbxSBOXMnL0xEu/8AAAFH7g Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_B7873C71FEFD6E41B5468506E231FB6E32E199AEMX14Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] FW: Question on RFC 6546 Table 1 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 16:30:35 -0000 --_004_B7873C71FEFD6E41B5468506E231FB6E32E199AEMX14Acorpemccom_ Content-Type: multipart/alternative; boundary="_000_B7873C71FEFD6E41B5468506E231FB6E32E199AEMX14Acorpemccom_" --_000_B7873C71FEFD6E41B5468506E231FB6E32E199AEMX14Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable P.S. If appropriate and/or necessary, I can file an errata for this. Any = guidance appreciated. Thanks, John From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of joh= np.field@emc.com Sent: Tuesday, June 05, 2012 12:24 PM To: mile@ietf.org 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 understa= nding of the intent of the column labeled "Callback" and the presence of th= e 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 Acknowledg= ement. Is this correct? Similarly, row 13 of Table 1 shows a Result message, with an expect respons= e of 200 status and no response body. Based on the "X" in the Callback co= lumn, I would interpret that to mean that no Callback is supported or shoul= d be expected by the RID system that initiated this message outbound. Th= e use case in row 13 would appear to be needed to support an asynchronous r= eply to row 4. That is, an earlier InvestigationRequest message that was m= et 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 asynchronou= s 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 Supporte= d", or something similar, and the values in that column be changed to indic= ate "Yes" or "No" as appropriate. In addition, some more explicit discussion of the nature of the message exc= hange pattern should be included. Perhaps include an example flow as I've= described here. At minimum, I would suggest that the text should explic= itly state that the messages shown in rows 12, 13, and 16 are defined in co= nnection 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: johnp.field@emc.com // http://www.emc.com --_000_B7873C71FEFD6E41B5468506E231FB6E32E199AEMX14Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

Thanks,

John

 

 

From: mile-bounc= es@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of johnp.field@= emc.com
Sent: Tuesday, June 05, 2012 12:24 PM
To: mile@= ietf.org
Subject: [mile] Question on RFC 6546 Table 1<= /span>

 

All,

 

I have read through RFC 6546 and, aft= er 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 understa= nding is that the X is used to indicate that the callback option is NOT sup= ported for the indicated RID Request message, and the sender of such as mes= sage should not expect to provoke any callback, and the receiver is forbidd= en from producing one.   So, for example, the Acknowledgment in r= ow 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.&= nbsp;  As such, there is no provision for yet another callback when se= nding 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 ̶= 0;X” in the Callback column, I would interpret that to mean that no C= allback is supported or should be expected by the RID system that initiated= this message outbound.    The use case in row 13 would appe= ar to be needed to support an asynchronous reply to row 4.  That is, a= n earlier InvestigationRequest message that was met with an initial 202 res= ponse.  

 

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 mes= sage that was received earlier? 

 

If my interp= retation is correct, then I suggest the following clarification:  the = column heading “Callback” should be updated to be “Callba= ck Supported”, or something similar, and the values in that column be= changed to indicate “Yes” or “No” as appropriate.&= nbsp; 

 

In addition, some more explicit discus= sion 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 st= ate that the messages shown in rows 12, 13, and 16 are defined in connectio= n with 4, 8, and 11, and as such, no additional callback is allowed.

 

<= div>

If my understanding is not correct, please advise.

 

<= div>

Regards,

Jo= hn

 

 

// John P. Field
// Security Architect
// EMC Office of the CTO /= / mailto: johnp.field@emc.com
// http://ww= w.emc.com

 

 

 

= --_000_B7873C71FEFD6E41B5468506E231FB6E32E199AEMX14Acorpemccom_-- --_004_B7873C71FEFD6E41B5468506E231FB6E32E199AEMX14Acorpemccom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Tue, 05 Jun 2012 16:25:19 GMT"; modification-date="Tue, 05 Jun 2012 16:25:19 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1pbGUgbWFp bGluZyBsaXN0DQptaWxlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21pbGUNCg== --_004_B7873C71FEFD6E41B5468506E231FB6E32E199AEMX14Acorpemccom_-- From johnp.field@emc.com Tue Jun 5 09:41:52 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736F521F8778 for ; Tue, 5 Jun 2012 09:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlbZHkfNT4Yn for ; Tue, 5 Jun 2012 09:41:51 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2093021F85D7 for ; Tue, 5 Jun 2012 09:41:50 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q55GfkHV022647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 Jun 2012 12:41:49 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Tue, 5 Jun 2012 12:41:36 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q55GfZN7021192 for ; Tue, 5 Jun 2012 12:41:35 -0400 Received: from mxhub39.corp.emc.com (128.222.70.106) by mxhub11.corp.emc.com (10.254.92.106) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 5 Jun 2012 12:41:35 -0400 Received: from mx14a.corp.emc.com ([169.254.1.157]) by mxhub39.corp.emc.com ([128.222.70.106]) with mapi; Tue, 5 Jun 2012 12:41:35 -0400 From: To: Date: Tue, 5 Jun 2012 12:41:33 -0400 Thread-Topic: HTTP status codes in RFC 6546 Thread-Index: Ac1DOhCs/tUm6Wh1TxWdFI7xP5v0TQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B7873C71FEFD6E41B5468506E231FB6E32E199B5MX14Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] HTTP status codes in RFC 6546 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 16:41:52 -0000 --_000_B7873C71FEFD6E41B5468506E231FB6E32E199B5MX14Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, At the bottom of Page 2 and continuing to the top of Page 3, paragraph 1, t= he RFC states that: "As RID messages MUST be sent using the POST method, the GET and HEAD metho= ds have no particular meaning on a RID system; a RID system SHOULD answer '= GET /' or 'HEAD /' with 204 No Content." Consistent with the HTTP RFC 2616 section 10.4.6, I would expect that the c= orrect HTTP status code for a GET, or HEAD request (or even a PUT or DELET= E) should be an HTTP 405 Method Not Allowed. This would seem to be more c= orrect, and also more helpful, since HTTP specifies that in this case the r= esponse headers would then include an Allow header that informs the client = of the HTTP methods that may be used (in this case POST). Is there some other constraint that motivated the choice of specifying a 20= 4 status code? Regards, John // John P. Field // Security Architect // EMC Office of the CTO // mailto: johnp.field@emc.com // http://www.emc.com --_000_B7873C71FEFD6E41B5468506E231FB6E32E199B5MX14Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
At the bottom of Page 2 and continuing to the top of Page 3, paragraph= 1, the RFC states that:
 
“As RID message= s MUST be sent using the POST method, the GET and HEAD methods have no part= icular meaning on a RID system; a RID system SHOULD answer 'GET /' or 'HEAD= /' with 204 No Content.”
 
Consistent with the HTTP RFC 2616 section 10.4.6, I would expect that = the correct HTTP status code for a GET,  or HEAD request (or even a PU= T or DELETE)  should be an HTTP 405 Method Not Allowed.  This wou= ld seem to be more correct, and also more helpful, since HTTP specifies that in this case the response headers would then incl= ude an Allow header that informs the client of the HTTP methods that may be= used (in this case POST).
 
Is there some other constraint that motivated the choice of specifying= a 204 status code?
 
Regards,
John
 
 
// John P. Field
// Security Architect =
// EMC Office of the CTO
// mailto: johnp.field@emc.com
// http://= www.emc.com
 
 
 
 --_000_B7873C71FEFD6E41B5468506E231FB6E32E199B5MX14Acorpemccom_-- From mdavidson@mitre.org Wed Jun 6 11:15:45 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF4321F8834 for ; Wed, 6 Jun 2012 11:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl-6kHQjIF2H for ; Wed, 6 Jun 2012 11:15:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6920521F8812 for ; Wed, 6 Jun 2012 11:15:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D037C21B0D52; Wed, 6 Jun 2012 14:15:38 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 828A021B0D28; Wed, 6 Jun 2012 14:15:38 -0400 (EDT) Received: from IMCMBX02.MITRE.ORG ([169.254.2.12]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.02.0283.003; Wed, 6 Jun 2012 14:15:38 -0400 From: "Davidson II, Mark S" To: "johnp.field@emc.com" , "mile@ietf.org" Thread-Topic: [mile] Question on RFC 6546 Table 1 Thread-Index: Ac1DN5gFpfNeAjbxSBOXMnL0xEu/8AA10kKg Date: Wed, 6 Jun 2012 18:15:37 +0000 Message-ID: <69F1FC52EB080B4983863BD1602520D80AD6FB47@IMCMBX02.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: multipart/alternative; boundary="_000_69F1FC52EB080B4983863BD1602520D80AD6FB47IMCMBX02MITREOR_" MIME-Version: 1.0 Subject: Re: [mile] Question on RFC 6546 Table 1 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 18:15:45 -0000 --_000_69F1FC52EB080B4983863BD1602520D80AD6FB47IMCMBX02MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 q= uery messages have a blank value in the callback column, the blank value mu= st mean allowed. Given that, the bottom two rows seem to be a bit confusing since they are t= he same except for the Callback column. -Mark From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of joh= np.field@emc.com Sent: Tuesday, June 05, 2012 12:24 PM To: mile@ietf.org 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 understa= nding of the intent of the column labeled "Callback" and the presence of th= e 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 Acknowledg= ement. Is this correct? Similarly, row 13 of Table 1 shows a Result message, with an expect respons= e of 200 status and no response body. Based on the "X" in the Callback co= lumn, I would interpret that to mean that no Callback is supported or shoul= d be expected by the RID system that initiated this message outbound. Th= e use case in row 13 would appear to be needed to support an asynchronous r= eply to row 4. That is, an earlier InvestigationRequest message that was m= et 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 asynchronou= s 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 Supporte= d", or something similar, and the values in that column be changed to indic= ate "Yes" or "No" as appropriate. In addition, some more explicit discussion of the nature of the message exc= hange pattern should be included. Perhaps include an example flow as I've= described here. At minimum, I would suggest that the text should explic= itly state that the messages shown in rows 12, 13, and 16 are defined in co= nnection 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: johnp.field@emc.com // http://www.emc.com --_000_69F1FC52EB080B4983863BD1602520D80AD6FB47IMCMBX02MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John,

 <= /p>

I think you’re corr= ect in that the X indicates that callback is not allowed. The RFC has the f= ollowing to say about Query and callback: 

RID systems MUST be prepared for a query t=
o be met with a 202
   Accepted, an empty Response b=
ody, a connection termination, and a
   callback.

 <=
/p>

As a result, the Query me=
ssage must be able to have a callback. Since all query messages have a blan=
k value in the callback column, the blank value must mean
 allowed.


 <=
/p>

Given that, the bottom tw=
o rows seem to be a bit confusing since they are the same except for the Ca=
llback column.


 <=
/p>

-Mark

 <=
/p>





From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org]
On Behalf Of johnp.field@emc.com

Sent: Tuesday, June 05, 2012 12:24 PM

To: mile@ietf.org

Subject: [mile] Question on RFC 6546 Table 1






 




All,







 <=
/o:p>






I have read =
through RFC 6546 and, after several passes, I find that I still need some h=
elp interpreting Table 1.   I would like to confirm my understand=
ing
 of the intent of the column labeled “Callback” and the presenc=
e of the corresponding X’s in that column.  







 <=
/o:p>






My understan=
ding is that the X is used to indicate that the callback option is NOT supp=
orted for the indicated RID Request message, and the sender
 of such as message should not expect to provoke any callback, and the rece=
iver is forbidden from producing one.   So, for example, the Ackn=
owledgment in row 12 could potentially be the “Ack” Reponse tha=
t 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 f=
or yet another callback when sending that Acknowledgement.  Is this co=
rrect? 







 <=
/o:p>






Similarly, r=
ow 13 of Table 1 shows a Result message, with an expect response of 200 sta=
tus and no response body.   Based on the “X” in the C=
allback
 column, I would interpret that to mean that no Callback is supported or sh=
ould be expected by the RID system that initiated this message outbound.&nb=
sp;   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.&nb=
sp;  






 <=
/o:p>






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 asynchronou=
s
 response to a message that was received earlier?  <=
/p>





 <=
/o:p>






If my interp=
retation is correct, then I suggest the following clarification:  the =
column heading “Callback” should be updated to be “Callba=
ck Supported”,
 or something similar, and the values in that column be changed to indicate=
 “Yes” or “No” as appropriate.  







 <=
/o:p>






In addition,=
 some more explicit discussion of the nature of the message exchange patter=
n should be included.   Perhaps include an example flow as
 I’ve described here.    At minimum, I would suggest t=
hat 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 addit=
ional callback is allowed.






 <=
/o:p>






If my unders=
tanding is not correct, please advise.






 <=
/o:p>






Regards,






John






 <=
/o:p>






 <=
/o:p>






// John P. Fie=
ld


// Security Architect


// EMC Office of the CTO


// mailto:
johnp.field@emc.com


// 
http://www.emc.com 






 <=
/o:p>






 <=
/o:p>






 <=
/o:p>
--_000_69F1FC52EB080B4983863BD1602520D80AD6FB47IMCMBX02MITREOR_-- From mdavidson@mitre.org Wed Jun 6 11:24:02 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B16D21F8866 for ; Wed, 6 Jun 2012 11:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuR+3b0dwHk6 for ; Wed, 6 Jun 2012 11:24:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 09CAA21F85B8 for ; Wed, 6 Jun 2012 11:24:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A381C21B0D45; Wed, 6 Jun 2012 14:24:00 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7739721B0D32; Wed, 6 Jun 2012 14:24:00 -0400 (EDT) Received: from IMCMBX02.MITRE.ORG ([169.254.2.12]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.02.0283.003; Wed, 6 Jun 2012 14:24:00 -0400 From: "Davidson II, Mark S" To: "johnp.field@emc.com" , "mile@ietf.org" Thread-Topic: HTTP status codes in RFC 6546 Thread-Index: Ac1DOhCs/tUm6Wh1TxWdFI7xP5v0TQA1mnbg Date: Wed, 6 Jun 2012 18:23:59 +0000 Message-ID: <69F1FC52EB080B4983863BD1602520D80AD6FB66@IMCMBX02.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: multipart/alternative; boundary="_000_69F1FC52EB080B4983863BD1602520D80AD6FB66IMCMBX02MITREOR_" MIME-Version: 1.0 Subject: Re: [mile] HTTP status codes in RFC 6546 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 18:24:02 -0000 --_000_69F1FC52EB080B4983863BD1602520D80AD6FB66IMCMBX02MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I did not write the RFC so I cannot speak to the motivation for those statu= s codes. I will say that I have the same question. Breaking RFC guidance may allow f= or more useful response codes / response messages. One limitation of the HT= TP 204 response is that there is no message body, just message headers. Wit= h an HTTP 405 response you are allowed to include a response body. -Mark From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of joh= np.field@emc.com Sent: Tuesday, June 05, 2012 12:42 PM To: mile@ietf.org Subject: [mile] HTTP status codes in RFC 6546 All, At the bottom of Page 2 and continuing to the top of Page 3, paragraph 1, t= he RFC states that: "As RID messages MUST be sent using the POST method, the GET and HEAD metho= ds have no particular meaning on a RID system; a RID system SHOULD answer '= GET /' or 'HEAD /' with 204 No Content." Consistent with the HTTP RFC 2616 section 10.4.6, I would expect that the c= orrect HTTP status code for a GET, or HEAD request (or even a PUT or DELET= E) should be an HTTP 405 Method Not Allowed. This would seem to be more c= orrect, and also more helpful, since HTTP specifies that in this case the r= esponse headers would then include an Allow header that informs the client = of the HTTP methods that may be used (in this case POST). Is there some other constraint that motivated the choice of specifying a 20= 4 status code? Regards, John // John P. Field // Security Architect // EMC Office of the CTO // mailto: johnp.field@emc.com // http://www.emc.com --_000_69F1FC52EB080B4983863BD1602520D80AD6FB66IMCMBX02MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I did not write the RFC s= o I cannot speak to the motivation for those status codes.

 <= /p>

I will say that I have th= e same question. Breaking RFC guidance may allow for more useful response c= odes / response messages. One limitation of the HTTP 204 response is that there is no message body, just message headers. With an H= TTP 405 response you are allowed to include a response body.

 <= /p>

-Mark

 <= /p>

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of johnp.field@emc.com
Sent: Tuesday, June 05, 2012 12:42 PM
To: mile@ietf.org
Subject: [mile] HTTP status codes in RFC 6546

 

All,

 <= /o:p>

At the botto= m of Page 2 and continuing to the top of Page 3, paragraph 1, the RFC state= s that:

 <= /o:p>

“As RID messages MUST be = sent using the POST method, the GET and HEAD methods have no particular mea= ning on a RID system; a RID system SHOULD answer 'GET /' or 'HEAD /' with 204 No Content.”<= /span>

 <= /o:p>

Consistent w= ith the HTTP RFC 2616 section 10.4.6, I would expect that the correct HTTP = status code for a GET,  or HEAD request (or even a PUT or DELETE)  should be an HTTP 405 Method Not Allowed.  This would s= eem to be more correct, and also more helpful, since HTTP specifies that in= this case the response headers would then include an Allow header that inf= orms the client of the HTTP methods that may be used (in this case POST).

 <= /o:p>

Is there som= e other constraint that motivated the choice of specifying a 204 status cod= e?

 <= /o:p>

Regards,

John

 <= /o:p>

 <= /o:p>

// John P. Fie= ld
// Security Architect
// EMC Office of the CTO
// mailto: johnp.field@emc.com
// http://www.emc.com

 <= /o:p>

 <= /o:p>

 <= /o:p>

--_000_69F1FC52EB080B4983863BD1602520D80AD6FB66IMCMBX02MITREOR_-- From kathleen.moriarty@emc.com Wed Jun 6 13:43:45 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7559911E80A1 for ; Wed, 6 Jun 2012 13:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpP9pJNkBPLm for ; Wed, 6 Jun 2012 13:43:43 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id EB80C11E8089 for ; Wed, 6 Jun 2012 13:43:42 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q56KhfhN012609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2012 16:43:41 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 6 Jun 2012 16:43:29 -0400 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q56KhOOq011375; Wed, 6 Jun 2012 16:43:29 -0400 Received: from mx15a.corp.emc.com ([169.254.1.101]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Wed, 6 Jun 2012 16:43:25 -0400 From: To: , , Date: Wed, 6 Jun 2012 16:40:36 -0400 Thread-Topic: HTTP status codes in RFC 6546 Thread-Index: Ac1DOhCs/tUm6Wh1TxWdFI7xP5v0TQA1mnbgAAUJgYA= Message-ID: References: , <69F1FC52EB080B4983863BD1602520D80AD6FB66@IMCMBX02.MITRE.ORG> In-Reply-To: <69F1FC52EB080B4983863BD1602520D80AD6FB66@IMCMBX02.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] HTTP status codes in RFC 6546 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 20:43:45 -0000 Thank you, John and Mark! I believe Brian is traveling, so if others have opinions and want to weigh = in on the two identified issues/questions, that may be helpful. If we work= through this and find there is an issue to correct (and there seems to be)= , as John suggested, he can file an errata report and Brian can include the= agreed upon solution in the errata report. The errata report would update= the RFC, hence maintaining compliance with the updated RFC. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Davidson I= I, Mark S [mdavidson@mitre.org] Sent: Wednesday, June 06, 2012 2:23 PM To: Field, John; mile@ietf.org Subject: Re: [mile] HTTP status codes in RFC 6546 I did not write the RFC so I cannot speak to the motivation for those statu= s codes. I will say that I have the same question. Breaking RFC guidance may allow f= or more useful response codes / response messages. One limitation of the HT= TP 204 response is that there is no message body, just message headers. Wit= h an HTTP 405 response you are allowed to include a response body. -Mark From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of joh= np.field@emc.com Sent: Tuesday, June 05, 2012 12:42 PM To: mile@ietf.org Subject: [mile] HTTP status codes in RFC 6546 All, At the bottom of Page 2 and continuing to the top of Page 3, paragraph 1, t= he RFC states that: =93As RID messages MUST be sent using the POST method, the GET and HEAD met= hods have no particular meaning on a RID system; a RID system SHOULD answer= 'GET /' or 'HEAD /' with 204 No Content.=94 Consistent with the HTTP RFC 2616 section 10.4.6, I would expect that the c= orrect HTTP status code for a GET, or HEAD request (or even a PUT or DELET= E) should be an HTTP 405 Method Not Allowed. This would seem to be more c= orrect, and also more helpful, since HTTP specifies that in this case the r= esponse headers would then include an Allow header that informs the client = of the HTTP methods that may be used (in this case POST). Is there some other constraint that motivated the choice of specifying a 20= 4 status code? Regards, John // John P. Field // Security Architect // EMC Office of the CTO // mailto: johnp.field@emc.com // http://www.emc.com From michael.hammer@yaanatech.com Thu Jun 7 06:35:27 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DE621F8888 for ; Thu, 7 Jun 2012 06:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-Xso2QznyU2 for ; Thu, 7 Jun 2012 06:35:26 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id CC3FE21F8882 for ; Thu, 7 Jun 2012 06:35:26 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 7 Jun 2012 06:35:26 -0700 From: Michael Hammer To: "kathleen.moriarty@emc.com" , "mdavidson@mitre.org" , "johnp.field@emc.com" , "mile@ietf.org" Thread-Topic: HTTP status codes in RFC 6546 Thread-Index: Ac1DOhCs/tUm6Wh1TxWdFI7xP5v0TQA1mnbgAAUJgYAAI2L1oA== Date: Thu, 7 Jun 2012 13:35:25 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB38B4149@EX2K10MB1.corp.yaanatech.com> References: , <69F1FC52EB080B4983863BD1602520D80AD6FB66@IMCMBX02.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CD4490.DD72A570" MIME-Version: 1.0 Subject: Re: [mile] HTTP status codes in RFC 6546 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 13:35:27 -0000 ------=_NextPart_000_0000_01CD4490.DD72A570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Correct me if I am wrong, but a 200 series code usually means success. 300 series a redirection, and 400, 500, 600 series means failure. So why a 204 response for what seems to be a failure? Mike -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of kathleen.moriarty@emc.com Sent: Wednesday, June 06, 2012 4:41 PM To: mdavidson@mitre.org; johnp.field@emc.com; mile@ietf.org Subject: Re: [mile] HTTP status codes in RFC 6546 Thank you, John and Mark! I believe Brian is traveling, so if others have opinions and want to weigh in on the two identified issues/questions, that may be helpful. If we work through this and find there is an issue to correct (and there seems to be), as John suggested, he can file an errata report and Brian can include the agreed upon solution in the errata report. The errata report would update the RFC, hence maintaining compliance with the updated RFC. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Davidson II, Mark S [mdavidson@mitre.org] Sent: Wednesday, June 06, 2012 2:23 PM To: Field, John; mile@ietf.org Subject: Re: [mile] HTTP status codes in RFC 6546 I did not write the RFC so I cannot speak to the motivation for those status codes. I will say that I have the same question. Breaking RFC guidance may allow for more useful response codes / response messages. One limitation of the HTTP 204 response is that there is no message body, just message headers. With an HTTP 405 response you are allowed to include a response body. -Mark From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of johnp.field@emc.com Sent: Tuesday, June 05, 2012 12:42 PM To: mile@ietf.org Subject: [mile] HTTP status codes in RFC 6546 All, At the bottom of Page 2 and continuing to the top of Page 3, paragraph 1, the RFC states that: "As RID messages MUST be sent using the POST method, the GET and HEAD methods have no particular meaning on a RID system; a RID system SHOULD answer 'GET /' or 'HEAD /' with 204 No Content." Consistent with the HTTP RFC 2616 section 10.4.6, I would expect that the correct HTTP status code for a GET, or HEAD request (or even a PUT or DELETE) should be an HTTP 405 Method Not Allowed. This would seem to be more correct, and also more helpful, since HTTP specifies that in this case the response headers would then include an Allow header that informs the client of the HTTP methods that may be used (in this case POST). Is there some other constraint that motivated the choice of specifying a 204 status code? Regards, John // John P. Field // Security Architect // EMC Office of the CTO // mailto: johnp.field@emc.com // http://www.emc.com _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_000_0000_01CD4490.DD72A570 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYw NzEzMzUyNFowIwYJKoZIhvcNAQkEMRYEFOk8ERaPUTzJOYa5QQ6WomwlD00HMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAudMucMI8pKub2zlsdukHMFK/1IyynSNkV2DObXGRqyXj 2LbE1EaCQpWE61MSGLwOGf4ExzFJ/p61/Hix4bX/hydM92CW5uZZ3wUGkbzuZz26FGUR3jh9T8BY OOqAedFvOG9dzHKAZJvNB74pcsZMUJm/NkcKgAFsUAYz3DE41rIAAAAAAAA= ------=_NextPart_000_0000_01CD4490.DD72A570-- From internet-drafts@ietf.org Fri Jun 8 04:41:27 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7B421F88A0; Fri, 8 Jun 2012 04:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8XHTHJEn-7o; Fri, 8 Jun 2012 04:41:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD60921F85DB; Fri, 8 Jun 2012 04:41:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120608114126.23825.48947.idtracker@ietfa.amsl.com> Date: Fri, 08 Jun 2012 04:41:26 -0700 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-template-05.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:41:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange= Working Group of the IETF. Title : Guidelines and Template for Defining Extensions to IODEF Author(s) : Brian Trammell Filename : draft-ietf-mile-template-05.txt Pages : 12 Date : 2012-06-08 This document provides guidelines for extensions to the Incident Object Description Exchange Format (IODEF) [RFC5070] for exchange of incident management data, and contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-template-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-template-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-template/ From iesg-secretary@ietf.org Mon Jun 11 15:04:46 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9505421F845E; Mon, 11 Jun 2012 15:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3Y2qzz3rKcL; Mon, 11 Jun 2012 15:04:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707F521F8466; Mon, 11 Jun 2012 15:04:45 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120611220445.26893.49485.idtracker@ietfa.amsl.com> Date: Mon, 11 Jun 2012 15:04:45 -0700 Cc: mile mailing list , mile chair , RFC Editor Subject: [mile] Protocol Action: 'Expert Review for IODEF Extensions in IANA XML Registry' to Proposed Standard (draft-ietf-mile-iodef-xmlreg-01.txt) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 22:04:46 -0000 The IESG has approved the following document: - 'Expert Review for IODEF Extensions in IANA XML Registry' (draft-ietf-mile-iodef-xmlreg-01.txt) as Proposed Standard This document is the product of the Managed Incident Lightweight Exchange Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-xmlreg/ Technical Summary 'Expert Review for IODEF Extensions in IANA XML Registry' (draft-ietf-mile-iodef-xmlreg) specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require Expert Review for extensions to the Incident Object Description Exchange Format (IODEF). IODEF is specified in RFC5070. Working Group Summary The document requires and expert review on IODEF extensions, very straightforward from the WG perspective. Document Quality Yes, there are several implementations of RFC5070 and extensions. This document does not specify anything that requires implementation, just requires an expert review on any new extensions. Personnel Kathleen Moriarty is the Document Shepherd. Sean Turner is the Responsible Area Director. IANA Note Please note that this document is assigning an *additional* expert. There's no expectation that this expert will be an XML expert. This will mean there are two designated experts: one for the XML schema and one for the IODEF. We'll need to somehow clearly identify this in the registry. From trammell@tik.ee.ethz.ch Tue Jun 12 00:08:06 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009FD21F8543 for ; Tue, 12 Jun 2012 00:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDOV3+BS8wy7 for ; Tue, 12 Jun 2012 00:08:05 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A7E0311E8073 for ; Tue, 12 Jun 2012 00:08:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EB343D930C; Tue, 12 Jun 2012 09:08:01 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9baySXYaKj-O; Tue, 12 Jun 2012 09:08:01 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9ACFED930B; Tue, 12 Jun 2012 09:08:01 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <00C069FD01E0324C9FFCADF539701DB38B4149@EX2K10MB1.corp.yaanatech.com> Date: Tue, 12 Jun 2012 09:08:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <57275580-BF08-429C-A644-43CDB6795300@tik.ee.ethz.ch> References: , <69F1FC52EB080B4983863BD1602520D80AD6FB66@IMCMBX02.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB38B4149@EX2K10MB1.corp.yaanatech.com> To: "" X-Mailer: Apple Mail (2.1278) Subject: Re: [mile] HTTP status codes in RFC 6546 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 07:08:06 -0000 Greetings, all, Replying as author of RFC 6546. The intent is that RID over HTTPS should be relatively quickly and = simply implementable atop existing HTTPS server infrastructure. As a RID = server cannot meaningfully generate content for a GET or a HEAD, 204 No = Content seemed (1) appropriate and (2) simple to implement. I chose 204 = during the appsdir review as my reading of 2616 at the time seemed to = indicate that 405 wasn't allowed for the root, but on rereading I'm not = sure where I got this idea. Selecting a return code for GET / or HEAD / is a bit of a corner case: = the exchange not one that is normally encountered in RID, as RID systems = exchanging messages with each other will never use these methods. = Non-RID System clients should never see an HTTP response to GET / or = HEAD /, as they would fail TLS negotiation first -- accidental or = curious clients should in no case have a valid certificate to connect to = a RID system (see paragraphs 13-18 in section 3 of RFC 6546, and section = 9.3 of RFC 6545). However, a more correct response would indeed be 405, so it probably = makes sense to file a technical erratum on the RFC. Best regards, Brian On Jun 7, 2012, at 3:35 PM, Michael Hammer wrote: > Correct me if I am wrong, but a 200 series code usually means success. > 300 series a redirection, and 400, 500, 600 series means failure. >=20 > So why a 204 response for what seems to be a failure? >=20 > Mike >=20 >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of > kathleen.moriarty@emc.com > Sent: Wednesday, June 06, 2012 4:41 PM > To: mdavidson@mitre.org; johnp.field@emc.com; mile@ietf.org > Subject: Re: [mile] HTTP status codes in RFC 6546 >=20 > Thank you, John and Mark! >=20 > I believe Brian is traveling, so if others have opinions and want to = weigh > in on the two identified issues/questions, that may be helpful. If we = work > through this and find there is an issue to correct (and there seems to = be), > as John suggested, he can file an errata report and Brian can include = the > agreed upon solution in the errata report. The errata report would = update > the RFC, hence maintaining compliance with the updated RFC. >=20 > Thank you, > Kathleen >=20 > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of = Davidson > II, Mark S [mdavidson@mitre.org] > Sent: Wednesday, June 06, 2012 2:23 PM > To: Field, John; mile@ietf.org > Subject: Re: [mile] HTTP status codes in RFC 6546 >=20 > I did not write the RFC so I cannot speak to the motivation for those = status > codes. >=20 > I will say that I have the same question. Breaking RFC guidance may = allow > for more useful response codes / response messages. One limitation of = the > HTTP 204 response is that there is no message body, just message = headers. > With an HTTP 405 response you are allowed to include a response body. >=20 > -Mark >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of > johnp.field@emc.com > Sent: Tuesday, June 05, 2012 12:42 PM > To: mile@ietf.org > Subject: [mile] HTTP status codes in RFC 6546 >=20 > All, >=20 > At the bottom of Page 2 and continuing to the top of Page 3, paragraph = 1, > the RFC states that: >=20 > "As RID messages MUST be sent using the POST method, the GET and HEAD > methods have no particular meaning on a RID system; a RID system = SHOULD > answer 'GET /' or 'HEAD /' with 204 No Content." >=20 > Consistent with the HTTP RFC 2616 section 10.4.6, I would expect that = the > correct HTTP status code for a GET, or HEAD request (or even a PUT or > DELETE) should be an HTTP 405 Method Not Allowed. This would seem to = be > more correct, and also more helpful, since HTTP specifies that in this = case > the response headers would then include an Allow header that informs = the > client of the HTTP methods that may be used (in this case POST). >=20 > Is there some other constraint that motivated the choice of specifying = a 204 > status code? >=20 > Regards, > John >=20 >=20 > // John P. Field > // Security Architect > // EMC Office of the CTO > // mailto: johnp.field@emc.com > // http://www.emc.com >=20 >=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Tue Jun 12 01:18:16 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B689D21F85B5 for ; Tue, 12 Jun 2012 01:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXl20KAhg2C3 for ; Tue, 12 Jun 2012 01:18:15 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFF521F85B1 for ; Tue, 12 Jun 2012 01:18:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 659C7D930B; Tue, 12 Jun 2012 10:18:14 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9d4a1aXei9in; Tue, 12 Jun 2012 10:18:14 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 23DB3D9308; Tue, 12 Jun 2012 10:18:14 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Brian Trammell In-Reply-To: <69F1FC52EB080B4983863BD1602520D80AD6FB47@IMCMBX02.MITRE.ORG> Date: Tue, 12 Jun 2012 10:18:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5A83E377-C80D-4009-825B-E86DD9A772B4@tik.ee.ethz.ch> References: <69F1FC52EB080B4983863BD1602520D80AD6FB47@IMCMBX02.MITRE.ORG> To: "" X-Mailer: Apple Mail (2.1278) Subject: Re: [mile] Question on RFC 6546 Table 1 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 08:18:17 -0000 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=20 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, > =20 > I think you=92re 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. > =20 > 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. > =20 > Given that, the bottom two rows seem to be a bit confusing since they = are the same except for the Callback column. > =20 > -Mark > =20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Ofjohnp.field@emc.com > Sent: Tuesday, June 05, 2012 12:24 PM > To: mile@ietf.org > Subject: [mile] Question on RFC 6546 Table 1 > =20 > All, > =20 > 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 =93Callback=94 and the = presence of the corresponding X=92s in that column. =20 > =20 > 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 =93Ack=94 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?=20 > =20 > Similarly, row 13 of Table 1 shows a Result message, with an expect = response of 200 status and no response body. Based on the =93X=94 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. =20= > =20 > In general, it seems that each of the rows that contain an =93X=94 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?=20 > =20 > If my interpretation is correct, then I suggest the following = clarification: the column heading =93Callback=94 should be updated to = be =93Callback Supported=94, or something similar, and the values in = that column be changed to indicate =93Yes=94 or =93No=94 as appropriate. = =20 > =20 > In addition, some more explicit discussion of the nature of the = message exchange pattern should be included. Perhaps include an = example flow as I=92ve 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. > =20 > If my understanding is not correct, please advise. > =20 > Regards, > John > =20 > =20 > // John P. Field=20 > // Security Architect=20 > // EMC Office of the CTO=20 > // mailto: johnp.field@emc.com=20 > // http://www.emc.com > =20 > =20 > =20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From mdavidson@mitre.org Tue Jun 12 05:21:01 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFE321F8503 for ; Tue, 12 Jun 2012 05:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjzK2+qJAKO1 for ; Tue, 12 Jun 2012 05:20:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAEE21F8501 for ; Tue, 12 Jun 2012 05:20:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AD36521B0EE6; Tue, 12 Jun 2012 08:20:56 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 947D721B0E4C; Tue, 12 Jun 2012 08:20:56 -0400 (EDT) Received: from IMCMBX02.MITRE.ORG ([169.254.2.84]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0283.003; Tue, 12 Jun 2012 08:20:56 -0400 From: "Davidson II, Mark S" To: Brian Trammell , "" Thread-Topic: [mile] Question on RFC 6546 Table 1 Thread-Index: Ac1DN5gFpfNeAjbxSBOXMnL0xEu/8AA10kKgASGjvIAAAEEzIA== Date: Tue, 12 Jun 2012 12:20:56 +0000 Message-ID: <69F1FC52EB080B4983863BD1602520D80BCB32F7@IMCMBX02.MITRE.ORG> References: <69F1FC52EB080B4983863BD1602520D80AD6FB47@IMCMBX02.MITRE.ORG> <5A83E377-C80D-4009-825B-E86DD9A772B4@tik.ee.ethz.ch> In-Reply-To: <5A83E377-C80D-4009-825B-E86DD9A772B4@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Question on RFC 6546 Table 1 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 12:21:01 -0000 Brian, Thank you for your response. I think for me, a more flow-chart type diagram would be useful. Of course t= hese 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, i= t 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 developmen= t of such a system, the option of specifying messages is useful for debuggi= ng. Thank you. -Mark -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 Sent: Tuesday, June 12, 2012 4:18 AM To: Cc: johnp.field@emc.com; Davidson II, Mark S Subject: Re: [mile] Question on RFC 6546 Table 1 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=20 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 s= ystem to differentiate among these is by the presence of the RID-Callback-T= oken entity header field. Perhaps replacing the table with a list of the permissible interactions wou= ld 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 que= stion: is the text in paragraphs 6-9 of Section 3 clear on how callbacks wo= rk, aside from the table? Best regards, Brian On Jun 6, 2012, at 8:15 PM, Davidson II, Mark S wrote: > John, > =20 > I think you're correct in that the X indicates that callback is not allow= ed. 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. > =20 > 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. > =20 > Given that, the bottom two rows seem to be a bit confusing since they are= the same except for the Callback column. > =20 > -Mark > =20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Ofjo= hnp.field@emc.com > Sent: Tuesday, June 05, 2012 12:24 PM > To: mile@ietf.org > Subject: [mile] Question on RFC 6546 Table 1 > =20 > All, > =20 > I have read through RFC 6546 and, after several passes, I find that I sti= ll need some help interpreting Table 1. I would like to confirm my unders= tanding of the intent of the column labeled "Callback" and the presence of = the corresponding X's in that column. =20 > =20 > My understanding is that the X is used to indicate that the callback opti= on is NOT supported for the indicated RID Request message, and the sender o= f such as message should not expect to provoke any callback, and the receiv= er is forbidden from producing one. So, for example, the Acknowledgment i= n row 12 could potentially be the "Ack" Reponse that is delivered as a foll= ow-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 Acknowle= dgement. Is this correct?=20 > =20 > Similarly, row 13 of Table 1 shows a Result message, with an expect respo= nse 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 sho= uld 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. =20 > =20 > In general, it seems that each of the rows that contain an "X" is there t= o cover the use case of a message that is itself being sent as an asynchron= ous response to a message that was received earlier?=20 > =20 > If my interpretation is correct, then I suggest the following clarificati= on: the column heading "Callback" should be updated to be "Callback Suppor= ted", or something similar, and the values in that column be changed to ind= icate "Yes" or "No" as appropriate. =20 > =20 > In addition, some more explicit discussion of the nature of the message e= xchange pattern should be included. Perhaps include an example flow as I'= ve described here. At minimum, I would suggest that the text should expl= icitly 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 allowe= d. > =20 > If my understanding is not correct, please advise. > =20 > Regards, > John > =20 > =20 > // John P. Field=20 > // Security Architect=20 > // EMC Office of the CTO=20 > // mailto: johnp.field@emc.com=20 > // http://www.emc.com > =20 > =20 > =20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From iesg-secretary@ietf.org Wed Jun 13 09:41:10 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1159811E808A; Wed, 13 Jun 2012 09:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVIQedQeGtyR; Wed, 13 Jun 2012 09:41:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F26811E8091; Wed, 13 Jun 2012 09:41:09 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120613164109.6907.42159.idtracker@ietfa.amsl.com> Date: Wed, 13 Jun 2012 09:41:09 -0700 Cc: mile mailing list , mile chair , RFC Editor Subject: [mile] Document Action: 'Guidelines and Template for Defining Extensions to IODEF' to Informational RFC (draft-ietf-mile-template-05.txt) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 16:41:10 -0000 The IESG has approved the following document: - 'Guidelines and Template for Defining Extensions to IODEF' (draft-ietf-mile-template-05.txt) as Informational RFC This document is the product of the Managed Incident Lightweight Exchange Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mile-template/ Technical Summary The 'Guidelines for Defining Extensions to IODEF' document provides guidelines for extensions to IODEF [RFC5070] for exchange of incident management data. The document contains a template for Internet-Drafts describing those extensions to provide a consistent approach for extensions in order to assist developers and implementers, while improving the quality of extension descriptions. Working Group Summary Consensus was strong. This draft went through WG last call twice as the first iteration it was combined with another draft. The second round received very few comments as the first had many voice support for the work. The template has been very helpful to those writing new drafts and should be helpful to implementers in the future having extensions in a common format and covering the specified areas. Document Quality This is a template to format extensions to IODEF and the template has been used 3 times now with success. The Apps area review in the first last call was very helpful already. I don't think additional special reviews are necessary. A review from the Apps area to ensure all concerns were addressed could be useful, I believe they have all been addressed. Personnel Document Shepherd: Kathleen Moriarty Responsible AD: Sean Turner From johnp.field@emc.com Wed Jun 20 13:52:23 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C4311E8093 for ; Wed, 20 Jun 2012 13:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9y38f-xgF80 for ; Wed, 20 Jun 2012 13:52:22 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 71E3811E8083 for ; Wed, 20 Jun 2012 13:52:21 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5KKqJ5w005721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2012 16:52:20 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 20 Jun 2012 16:51:57 -0400 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5KKpvpd004857; Wed, 20 Jun 2012 16:51:57 -0400 Received: from mx14a.corp.emc.com ([169.254.1.100]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Wed, 20 Jun 2012 16:51:57 -0400 From: To: , Date: Wed, 20 Jun 2012 16:51:53 -0400 Thread-Topic: [mile] Question on RFC 6546 Table 1 Thread-Index: Ac1Ic/A16g3FHpgJSGCDKOw7Kwp7sAGqDv3w Message-ID: References: <69F1FC52EB080B4983863BD1602520D80AD6FB47@IMCMBX02.MITRE.ORG> <5A83E377-C80D-4009-825B-E86DD9A772B4@tik.ee.ethz.ch> In-Reply-To: <5A83E377-C80D-4009-825B-E86DD9A772B4@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Question on RFC 6546 Table 1 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 20:52:23 -0000 Hi Brian, Thanks for your reply. This helps. =20 Aside from the table itself, the text in paragraphs 6-9 of Section 3 is cle= ar enough on how callbacks work. At minimum, I think the following sentenc= e from your recent reply should find its way into the RFC text. =20 "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 respons= e." 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 thi= s thread. =20 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 appea= r in an HTTP request when the message is being generated as a Callback. Ho= wever, a RID Report message that appears in an HTTP request may represent e= ither 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 20= 0, 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 inte= ractions. =20 Finally, the existing discussion of the construction and handling of the ca= llback token is fine. Hope this helps. Thanks, John -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 Sent: Tuesday, June 12, 2012 4:18 AM To: Cc: Field, John; Davidson II, Mark S Subject: Re: [mile] Question on RFC 6546 Table 1 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=20 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 s= ystem to differentiate among these is by the presence of the RID-Callback-T= oken entity header field. Perhaps replacing the table with a list of the permissible interactions wou= ld 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 que= stion: is the text in paragraphs 6-9 of Section 3 clear on how callbacks wo= rk, aside from the table? Best regards, Brian On Jun 6, 2012, at 8:15 PM, Davidson II, Mark S wrote: > John, > =20 > I think you're correct in that the X indicates that callback is not allow= ed. 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. > =20 > 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. > =20 > Given that, the bottom two rows seem to be a bit confusing since they are= the same except for the Callback column. > =20 > -Mark > =20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Ofjo= hnp.field@emc.com > Sent: Tuesday, June 05, 2012 12:24 PM > To: mile@ietf.org > Subject: [mile] Question on RFC 6546 Table 1 > =20 > All, > =20 > I have read through RFC 6546 and, after several passes, I find that I sti= ll need some help interpreting Table 1. I would like to confirm my unders= tanding of the intent of the column labeled "Callback" and the presence of = the corresponding X's in that column. =20 > =20 > My understanding is that the X is used to indicate that the callback opti= on is NOT supported for the indicated RID Request message, and the sender o= f such as message should not expect to provoke any callback, and the receiv= er is forbidden from producing one. So, for example, the Acknowledgment i= n row 12 could potentially be the "Ack" Reponse that is delivered as a foll= ow-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 Acknowle= dgement. Is this correct?=20 > =20 > Similarly, row 13 of Table 1 shows a Result message, with an expect respo= nse 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 sho= uld 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. =20 > =20 > In general, it seems that each of the rows that contain an "X" is there t= o cover the use case of a message that is itself being sent as an asynchron= ous response to a message that was received earlier?=20 > =20 > If my interpretation is correct, then I suggest the following clarificati= on: the column heading "Callback" should be updated to be "Callback Suppor= ted", or something similar, and the values in that column be changed to ind= icate "Yes" or "No" as appropriate. =20 > =20 > In addition, some more explicit discussion of the nature of the message e= xchange pattern should be included. Perhaps include an example flow as I'= ve described here. At minimum, I would suggest that the text should expl= icitly 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 allowe= d. > =20 > If my understanding is not correct, please advise. > =20 > Regards, > John > =20 > =20 > // John P. Field=20 > // Security Architect=20 > // EMC Office of the CTO=20 > // mailto: johnp.field@emc.com=20 > // http://www.emc.com > =20 > =20 > =20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From johnp.field@emc.com Mon Jun 25 07:41:21 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DD121F864D for ; Mon, 25 Jun 2012 07:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3eLG2zZ4oE5 for ; Mon, 25 Jun 2012 07:41:20 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEDB21F8617 for ; Mon, 25 Jun 2012 07:41:20 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5PEfEtX014719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jun 2012 10:41:18 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 25 Jun 2012 10:40:50 -0400 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5PEemw0031294; Mon, 25 Jun 2012 10:40:48 -0400 Received: from mxhub40.corp.emc.com (128.222.70.107) by mxhub15.corp.emc.com (128.222.70.236) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 25 Jun 2012 10:40:48 -0400 Received: from mx14a.corp.emc.com ([169.254.1.100]) by mxhub40.corp.emc.com ([128.222.70.107]) with mapi; Mon, 25 Jun 2012 10:40:48 -0400 From: To: , Date: Mon, 25 Jun 2012 10:40:44 -0400 Thread-Topic: [mile] HTTP status codes in RFC 6546 Thread-Index: Ac1IaiVJXsKQihBJTgqIWMXDuD55sgIUtSPA Message-ID: References: , <69F1FC52EB080B4983863BD1602520D80AD6FB66@IMCMBX02.MITRE.ORG> <00C069FD01E0324C9FFCADF539701DB38B4149@EX2K10MB1.corp.yaanatech.com> <57275580-BF08-429C-A644-43CDB6795300@tik.ee.ethz.ch> In-Reply-To: <57275580-BF08-429C-A644-43CDB6795300@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] HTTP status codes in RFC 6546 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 14:41:21 -0000 Brian, Thanks for your reply. I'll work with Kathleen to file the required errata= . Regards, John -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 Sent: Tuesday, June 12, 2012 3:08 AM To: Cc: Moriarty, Kathleen; mdavidson@mitre.org; Field, John; Michael Hammer Subject: Re: [mile] HTTP status codes in RFC 6546 Greetings, all, Replying as author of RFC 6546. The intent is that RID over HTTPS should be relatively quickly and simply i= mplementable atop existing HTTPS server infrastructure. As a RID server can= not meaningfully generate content for a GET or a HEAD, 204 No Content seeme= d (1) appropriate and (2) simple to implement. I chose 204 during the appsd= ir review as my reading of 2616 at the time seemed to indicate that 405 was= n't allowed for the root, but on rereading I'm not sure where I got this id= ea. Selecting a return code for GET / or HEAD / is a bit of a corner case: the = exchange not one that is normally encountered in RID, as RID systems exchan= ging messages with each other will never use these methods. Non-RID System = clients should never see an HTTP response to GET / or HEAD /, as they would= fail TLS negotiation first -- accidental or curious clients should in no c= ase have a valid certificate to connect to a RID system (see paragraphs 13-= 18 in section 3 of RFC 6546, and section 9.3 of RFC 6545). However, a more correct response would indeed be 405, so it probably makes = sense to file a technical erratum on the RFC. Best regards, Brian On Jun 7, 2012, at 3:35 PM, Michael Hammer wrote: > Correct me if I am wrong, but a 200 series code usually means success. > 300 series a redirection, and 400, 500, 600 series means failure. >=20 > So why a 204 response for what seems to be a failure? >=20 > Mike >=20 >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > kathleen.moriarty@emc.com > Sent: Wednesday, June 06, 2012 4:41 PM > To: mdavidson@mitre.org; johnp.field@emc.com; mile@ietf.org > Subject: Re: [mile] HTTP status codes in RFC 6546 >=20 > Thank you, John and Mark! >=20 > I believe Brian is traveling, so if others have opinions and want to weig= h > in on the two identified issues/questions, that may be helpful. If we wo= rk > through this and find there is an issue to correct (and there seems to be= ), > as John suggested, he can file an errata report and Brian can include the > agreed upon solution in the errata report. The errata report would updat= e > the RFC, hence maintaining compliance with the updated RFC. >=20 > Thank you, > Kathleen >=20 > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Davidson > II, Mark S [mdavidson@mitre.org] > Sent: Wednesday, June 06, 2012 2:23 PM > To: Field, John; mile@ietf.org > Subject: Re: [mile] HTTP status codes in RFC 6546 >=20 > I did not write the RFC so I cannot speak to the motivation for those sta= tus > codes. >=20 > I will say that I have the same question. Breaking RFC guidance may allow > for more useful response codes / response messages. One limitation of the > HTTP 204 response is that there is no message body, just message headers. > With an HTTP 405 response you are allowed to include a response body. >=20 > -Mark >=20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > johnp.field@emc.com > Sent: Tuesday, June 05, 2012 12:42 PM > To: mile@ietf.org > Subject: [mile] HTTP status codes in RFC 6546 >=20 > All, >=20 > At the bottom of Page 2 and continuing to the top of Page 3, paragraph 1, > the RFC states that: >=20 > "As RID messages MUST be sent using the POST method, the GET and HEAD > methods have no particular meaning on a RID system; a RID system SHOULD > answer 'GET /' or 'HEAD /' with 204 No Content." >=20 > Consistent with the HTTP RFC 2616 section 10.4.6, I would expect that the > correct HTTP status code for a GET, or HEAD request (or even a PUT or > DELETE) should be an HTTP 405 Method Not Allowed. This would seem to be > more correct, and also more helpful, since HTTP specifies that in this ca= se > the response headers would then include an Allow header that informs the > client of the HTTP methods that may be used (in this case POST). >=20 > Is there some other constraint that motivated the choice of specifying a = 204 > status code? >=20 > Regards, > John >=20 >=20 > // John P. Field > // Security Architect > // EMC Office of the CTO > // mailto: johnp.field@emc.com > // http://www.emc.com >=20 >=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Mon Jun 25 12:01:14 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5D421F85D5 for ; Mon, 25 Jun 2012 12:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.899, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaEWdw1g+BFq for ; Mon, 25 Jun 2012 12:01:14 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E6E6C21F85B5 for ; Mon, 25 Jun 2012 12:01:13 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5PJ17Ot025140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jun 2012 15:01:07 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Mon, 25 Jun 2012 15:01:02 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5PJ0wcY023951 for ; Mon, 25 Jun 2012 15:01:01 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Mon, 25 Jun 2012 15:01:01 -0400 From: To: Date: Mon, 25 Jun 2012 15:00:59 -0400 Thread-Topic: MILE Agenda Requests Thread-Index: Ac1TBNvA5DhlkSeFQFeCBuFv5Dx5QQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24039496A0MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] MILE Agenda Requests X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 19:01:15 -0000 --_000_F5063677821E3B4F81ACFB7905573F24039496A0MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Please send any requests to be on the Agenda for the MILE meeting in Vancou= ver to Brian and I (mile-chairs@tools.ietf.org). The IETF Vancouver meetings take place from July 29-August 3rd. = Here is a link to the important dates in case you are the author of a draft= or have plans to submit a new draft: http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF84 Best regards, Kathleen --_000_F5063677821E3B4F81ACFB7905573F24039496A0MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
Please send any requests to be on the Agenda for the MILE meeting in V= ancouver to Brian and I (mile-chairs@tools.ietf.org).  Th= e IETF Vancouver meetings take place from July 29-August 3rd.  Here is a link= to the important dates in case you are the author of a draft or have plans= to submit a new draft:
 
 
Best regards,
Kathleen
 
 
--_000_F5063677821E3B4F81ACFB7905573F24039496A0MX15Acorpemccom_-- From wwwrun@rfc-editor.org Tue Jun 26 14:37:12 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED1621F8496 for ; Tue, 26 Jun 2012 14:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.076 X-Spam-Level: X-Spam-Status: No, score=-102.076 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFcZQroB27i5 for ; Tue, 26 Jun 2012 14:37:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 48FD221F8483 for ; Tue, 26 Jun 2012 14:37:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DFF8572E004; Tue, 26 Jun 2012 14:36:04 -0700 (PDT) To: trammell@tik.ee.ethz.ch, stephen.farrell@cs.tcd.ie, turners@ieca.com, Kathleen.Moriarty@emc.com, trammell@tik.ee.ethz.ch From: RFC Errata System Message-Id: <20120626213604.DFF8572E004@rfc-editor.org> Date: Tue, 26 Jun 2012 14:36:04 -0700 (PDT) Cc: mile@ietf.org, rfc-editor@rfc-editor.org Subject: [mile] [Technical Errata Reported] RFC6546 (3267) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:37:12 -0000 The following errata report has been submitted for RFC6546, "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6546&eid=3267 -------------------------------------- Type: Technical Reported by: John Field Section: 3 Original Text ------------- In paragraph 4 of section 3, fourth sentence: "As RID messages MUST be sent using the POST method, the GET and HEAD methods have no particular meaning on a RID system; a RID system SHOULD answer 'GET /' or 'HEAD /' with 204 No Content." Corrected Text -------------- Consistent with RFC 2616 section 10.4.6, a RID system MUST answer any HTTP request to Request-URI of '/' which uses an HTTP method other than 'POST' by producing an HTTP response with a status code of 405 Method Not Allowed. The RID system HTTP response MUST also include an Allow header indicating that only the 'POST' method is supported. Notes ----- There has been a brief discussion of this errata on the MILE list, with the first message in the thread having been posted on June 5, 2012. The corrected text that I have suggested above has been written as narrowly as possible, and remains consistent with the original functionality described in 6546. Lacking support for 'GET' means that there is no way to verify if a RID endpoint is active, other than by doing a real request, i.e. a Report, or Query, etc. Thus, one might also consider supporting HEAD, e.g. for RID testing purposes, though that option has not been discussed yet. Note, however, that supporting HEAD potentially raises further issues since according to RFC 2616 the response headers to a HEAD request SHOULD be consistent with a GET, which is specifically not supported. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6546 (draft-ietf-mile-rfc6046-bis-09) -------------------------------------- Title : Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS Publication Date : April 2012 Author(s) : B. Trammell Category : PROPOSED STANDARD Source : Managed Incident Lightweight Exchange Area : Security Stream : IETF Verifying Party : IESG