Subject: [mile] RFC6546 possible editorial errata

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 20 Nov 2012 18:31:50 -0500

Hi Brian & all,

There has been some confusion by a developer on when to use a HTTP 4xx response versus the use of an HTTP 200 response with an acknowledgement.  I think to get to the intent of RFC6545 and RFC6546 a proposed text fix could address this confusion and just get filed as an editorial errata:

Section 3, paragraph 12:
Change from:
If a RID system receives an improper RID message in an HTTP Request,
   it MUST return an appropriate 4xx Client Error result code to the
   requesting RID system. 

To:
If a RID system receives an improper HTTP Request,
   it MUST return an appropriate 4xx Client Error result code to the
   requesting RID system. 

Thoughts?  Do others on the list agree with the text change?  Brian, do you agree this change more clearly states the intent?

Thanks,
Kathleen

---

From: SM <[email-masked]>
Date: Wed, 21 Nov 2012 08:00:28 -0800

Hi Kathleen,
At 15:31 20-11-2012, Moriarty, Kathleen wrote:
>There has been some confusion by a developer on when to use a HTTP 
>4xx response versus the use of an HTTP 200 response with an 
>acknowledgement.  I think to get to the intent of RFC6545 and 
>RFC6546 a proposed text fix could address this confusion and just 
>get filed as an editorial errata:
>
>Section 3, paragraph 12:
>Change from:

The above suggested text changes the RFC 2119 requirement.  I 
wouldn't consider it as editorial as the intent is debatable if there 
wasn't any (prior) discussion to support it.

BTW, the requirement is similar to the one in the sentence that 
follows the one quoted above.

Regards,
-sm

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 21 Nov 2012 11:21:17 -0500

SM,

Thanks for the review!  Here is the text that SM is referring to:

"If a RID system receives an improper RID message in an HTTP Request,
   it MUST return an appropriate 4xx Client Error result code to the
   requesting RID system.  If a RID system cannot process a RID message
   received in an HTTP Request due to an error on its own side, it MUST
   return an appropriate 5xx Server Error result code to the requesting
   RID system."

I agree that the text is confusing as one developer interpreted it to apply to the RID messages and another interpreted it as applying to HTTP since the codes are specific to HTTP and not the application layer.  I believe the intent was that it applied to the HTTP error level as this document was focused on transport.  I see your point that this may be a technical change.  The following sentence has the same problem, do you agree with the assessment and what do others think?

Thanks,
Kathleen
________________________________________
From: SM [[email-masked]]
Sent: Wednesday, November 21, 2012 11:00 AM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: Re: [mile] RFC6546 possible editorial errata

Hi Kathleen,

Regards,
-sm

---

From: SM <[email-masked]>
Date: Wed, 21 Nov 2012 09:40:19 -0800

Hi Kathleen,
At 08:21 21-11-2012, Moriarty, Kathleen wrote:
>I agree that the text is confusing as one developer interpreted it 
>to apply to the RID messages and another interpreted it as applying 
>to HTTP since the codes are specific to HTTP and not the application 
>layer.  I believe the intent was that it applied to the HTTP error 
>level as this document was focused on transport.  I see your point 
>that this may be a technical change.  The following sentence has the 
>same problem, do you agree with the assessment and what do others think?

I read Brian Trammell's response to a review of the draft [1].  I 
vaguely recall a discussion about not redefining HTTP status codes 
(see RFC 3205).  I could explain the text which you quoted above as follows:

   If a RID system receives an improper RID message it MUST return an
   appropriate 4xx Client Error result code

The confusion might be from the following text in RFC 6546:

   "Note that HTTP provides no mechanism for signaling to a server that a
    response body is not a valid RID message.  If a RID system receives
    an improper RID message in an HTTP Response, or cannot process a RID
    message received in an HTTP Response due to an error on its own side,
    it MUST log the error and present it to the RID system administrator
    for handling; the error logging format is an implementation detail
    and is considered out of scope for this specification."

My explanation may be wrong as it depends on how I read the first 
sentence quoted above.  This is not the first time there was 
confusion about the HTTP codes [2].  I suggest removing the two RFC 
2119 requirements and adding a pointer to the relevant section of RFC 
2616.  In the short term an erratum could be filed with the argument 
you made about transport.  I suggest having an informal discussion 
with the Responsible AD first as he can provide better advice about this issue.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03942.html
2. http://www.ietf.org/mail-archive/web/mile/current/msg00716.html

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 21 Nov 2012 18:46:00 -0500

The document is focused on applying the HTTP transport to define an application-layer protocol for RID (at least according to the abstract), so to some extent it has its feet on both sides of the fence. ;-)

If the text is changed it might clarify what to do in the case of an invalid HTTP request at the transport layer.  In doing so, wouldn't we then be introducing the same ambiguity at the application layer for an invalid RID message?  In this case it would be undefined as to what to do if you have a valid HTTP request from a transport perspective with an invalid RID message from an application perspective.  It might make sense instead to change it to:

"If a RID system receives an improper HTTP Request or an improper RID message in a valid HTTP Request,  it MUST return an appropriate 4xx Client Error result code to the requesting RID system."

Something like this would cover both cases making it clear to both developers.

Happy Thanksgiving to those celebrating!

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Moriarty, Kathleen
Sent: Wednesday, November 21, 2012 11:21 AM
To: SM
Cc: [email-masked]
Subject: Re: [mile] RFC6546 possible editorial errata

SM,

Thanks,
Kathleen

Hi Kathleen,
At 15:31 20-11-2012, Moriarty, Kathleen wrote:
>There has been some confusion by a developer on when to use a HTTP 4xx 
>response versus the use of an HTTP 200 response with an 
>RFC6546 a proposed text fix could address this confusion and just get 
>filed as an editorial errata:
>
>Section 3, paragraph 12:
>Change from:

The above suggested text changes the RFC 2119 requirement.  I wouldn't consider it as editorial as the intent is debatable if there wasn't any (prior) discussion to support it.

BTW, the requirement is similar to the one in the sentence that follows the one quoted above.

Regards,
-sm

_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 21 Nov 2012 21:21:48 -0500

Hi Dave,

Thanks for taking a look at this as well!

At the application layer, you have the ability to figure out what is wrong with the RID/IODEF document and provide a response with details via the Acknowledgement message.  This would be in a 200 HTTP code according to the table and then the 'Justification' can be set appropriately (xml encryption error, xml schema error, etc.).  As a result, the language in the sentences provided is causing some confusion.  I should have provided that context in the initial message.  Does the additional context change your view?  I think it would be easier for developers (and meet the intended objective with the language change, but it may be technical and not editorial).  Does that change your view?  

Anyone other thoughts from the list?

Thanks,
Kathleen
________________________________________
From: Waltermire, David A. [[email-masked]]
Sent: Wednesday, November 21, 2012 6:46 PM
To: Moriarty, Kathleen; SM
Cc: [email-masked]
Subject: RE: [mile] RFC6546 possible editorial errata

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Moriarty, Kathleen
Sent: Wednesday, November 21, 2012 11:21 AM
To: SM
Cc: [email-masked]
Subject: Re: [mile] RFC6546 possible editorial errata

SM,

Thanks,
Kathleen

Hi Kathleen,

Regards,
-sm

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 27 Nov 2012 10:57:27 -0500

I think it makes sense to classify any change to the original wording in question as technical, since it changes the technical meaning of the text.

I am good with using the application layer Acknowledgement message to report a malformed RID request message.  This looks like it is aligned well with the text in rfc6545 section 6.2.

My only concern is introducing ambiguity from the other direction with the change.  Relative to the transport, is the use of the acknowledgement approach clear?  Have the developers you mentioned weighed in on the change from their perspectives?

Any other thoughts?

Thanks,
Dave

-----Original Message-----
From: Moriarty, Kathleen [mailto:[email-masked]] 
Sent: Wednesday, November 21, 2012 9:22 PM
To: Waltermire, David A.; SM
Cc: [email-masked]
Subject: RE: [mile] RFC6546 possible editorial errata

Hi Dave,

Thanks,
Kathleen

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Moriarty, Kathleen
Sent: Wednesday, November 21, 2012 11:21 AM
To: SM
Cc: [email-masked]
Subject: Re: [mile] RFC6546 possible editorial errata

SM,

Thanks,
Kathleen

Hi Kathleen,

Regards,
-sm

---

From: "Black, David" <[email-masked]>
Date: Tue, 27 Nov 2012 15:47:51 -0500

Hi Dave,

I like the approach of reporting errors at the layer at which they
occur, but I do agree that this would be a technical change.

For the RID Acknowledgement message, what should be in the
RequestStatus instance to indicate that the RID message that is
being acknowledged was malformed (and hence has been discarded)?
Would UnrecognizedFormat cover this case?

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Waltermire, David A.
> Sent: Tuesday, November 27, 2012 10:57 AM
> I think it makes sense to classify any change to the original wording in
> question as technical, since it changes the technical meaning of the text.
> 
> I am good with using the application layer Acknowledgement message to report a
> malformed RID request message.  This looks like it is aligned well with the
> text in rfc6545 section 6.2.
> 
> My only concern is introducing ambiguity from the other direction with the
> change.  Relative to the transport, is the use of the acknowledgement approach
> clear?  Have the developers you mentioned weighed in on the change from their
> perspectives?
> 
> Any other thoughts?
> 
> Thanks,
> Dave
> 
> At the application layer, you have the ability to figure out what is wrong
> with the RID/IODEF document and provide a response with details via the
> Acknowledgement message.  This would be in a 200 HTTP code according to the
> table and then the 'Justification' can be set appropriately (xml encryption
> error, xml schema error, etc.).  As a result, the language in the sentences
> provided is causing some confusion.  I should have provided that context in
> the initial message.  Does the additional context change your view?  I think
> it would be easier for developers (and meet the intended objective with the
> language change, but it may be technical and not editorial).  Does that change
> your view?
> 
> The document is focused on applying the HTTP transport to define an
> application-layer protocol for RID (at least according to the abstract), so to
> some extent it has its feet on both sides of the fence. ;-)
> 
> If the text is changed it might clarify what to do in the case of an invalid
> HTTP request at the transport layer.  In doing so, wouldn't we then be
> introducing the same ambiguity at the application layer for an invalid RID
> message?  In this case it would be undefined as to what to do if you have a
> valid HTTP request from a transport perspective with an invalid RID message
> from an application perspective.  It might make sense instead to change it to:
> 
> "If a RID system receives an improper HTTP Request or an improper RID message
> in a valid HTTP Request,  it MUST return an appropriate 4xx Client Error
> result code to the requesting RID system."
> 
> I agree that the text is confusing as one developer interpreted it to apply to
> the RID messages and another interpreted it as applying to HTTP since the
> codes are specific to HTTP and not the application layer.  I believe the
> intent was that it applied to the HTTP error level as this document was
> focused on transport.  I see your point that this may be a technical change.
> The following sentence has the same problem, do you agree with the assessment
> and what do others think?
> 
> Thanks,
> Kathleen
> The above suggested text changes the RFC 2119 requirement.  I wouldn't
> consider it as editorial as the intent is debatable if there wasn't any
> (prior) discussion to support it.
>

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 27 Nov 2012 16:11:20 -0500

Thanks, David.

Yes, UnrecognizedFormat for the Justification attribute would be the correct response at the RID layer.

We have some consensus it seems.  Brian and Sean may want to weigh in as well (or anyone else).

Best regards,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Black, David
Sent: Tuesday, November 27, 2012 3:48 PM
To: Waltermire, David A.
Cc: [email-masked]
Subject: Re: [mile] RFC6546 possible editorial errata

Hi Dave,

Thanks,
--David

> Moriarty, Kathleen

---

From: Brian Trammell <[email-masked]>
Date: Wed, 28 Nov 2012 00:49:48 +0100

Hi, Kathleen, all,

(chair hat off) (6546 author hat on)

I'm a little confused on terminology here; "malformed" with respect to a RID message meaning "not well-formed XML", or "XML not corresponding to the RID schema"?

In any case, since there's an application-layer mechanism for reporting such errors it makes sense to use it, of course. However, I'd find something deeply odd about returning a 200 OK which inside it contained an Acknowledgment signaling UnrecognizedFormat -- the response status and response body would mismatch then.

I'd suggest instead 400 Bad Request, with Acknowledgment as response body.

Which leaves us with NEW (a little stilted, can probably stand some editorial improvement...)

  If a RID system receives an improper HTTP Request,
  it MUST return an appropriate 4xx Client Error result code to the
  requesting RID system. If a RID system receives a malformed RID message, 
  it MUST return an Acknowledgment RID message, with 'Denied' as the
  AuthorizationStatus attribute of RequestStatus and 'UnrecognizedFormat' 
  as the Justification attribute of RequestStatus, in a response with 
  result code 400 Bad Request. If a RID system cannot process a RID message
  received in an HTTP Request due to an error on its own side, it MUST
  return an appropriate 5xx Server Error result code to the requesting
  RID system.

Best regards,

Brian

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 27 Nov 2012 19:30:06 -0500

Hi Brian,

Malformed is the wrong word, we are really talking about the IODEF schema or some embedded schema via the SCI draft not being conformant.  Or you could have some other schema sent in RID that is not recognized by the receiving system (something other than IODEF).  As such, handling that error at the RID application layer is easier than at the HTTP layer from a development perspective.  There are a range of possible things that could occur and malformed is not really the right word to describe UnrecognizedFormat.  By changing the response to a 400 with an Acknowledgement now, that is pretty significant as the flows and tables change to allow an Ack to come back in either a 200 or a 400 depending on the Justification value selected.  I think for developers, handling HTTP at the HTTP layer is easier and then application errors at the RID layer.  I think it is a smaller change and may be better for adoption by developers rather than having them do both before sending an HTTP 400 message.

Does that help clear up your confusion?  Any thoughts?

Thanks,
Kathleen

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Tuesday, November 27, 2012 6:50 PM
To: Moriarty, Kathleen
Cc: Black, David; Waltermire, David A.; [email-masked]
Subject: Re: [mile] RFC6546 possible editorial errata

Hi, Kathleen, all,

Best regards,
Brian

---

From: Brian Trammell <[email-masked]>
Date: Wed, 28 Nov 2012 21:49:50 +0100

Hi, Kathleen, all,

I suppose if we view 6546 as a completely separate layer for RID, it makes sense for 200 OK to mean "I accepted your RID message", or "here is a response" even if that response indicates error.

In that case, the original fix (remove "improper RID message") would be the correct one; I (as a contributor) would be okay with that. But yes, it's clearly a technical ambiguity (in any case, the new text changes how I'd implement it) and therefore a technical erratum.

Best regards,

Brian

---

From: Sean Turner <[email-masked]>
Date: Thu, 29 Nov 2012 11:36:49 -0500

wfm

spt

On 11/28/12 3:49 PM, Brian Trammell wrote:
>> Malformed is the wrong word, we are really talking about the IODEF schema or some embedded schema via the SCI draft not being conformant.  Or you could have some other schema sent in RID that is not recognized by the receiving system (something other than IODEF).  As such, handling that error at the RID application layer is easier than at the HTTP layer from a development perspective.  There are a range of possible things that could occur and malformed is not really the right word to describe UnrecognizedFormat.  By changing the response to a 400 with an Acknowledgement now, that is pretty significant as the flows and tables change to allow an Ack to come back in either a 200 or a 400 depending on the Justification value selected.  I think for developers, handling HTTP at the HTTP layer is easier and then application errors at the RID layer.  I think it is a smaller change and may be better for adoption by developers rather than having them do both before sending an HTTP 4
 0
>   0 message.