Subject: Re: [mile] RFC6546 possible editorial errata

From: "Field, John" <[email-masked]>
Date: Tue, 11 Dec 2012 11:45:53 -0500

Sorry for the long message and for chiming in a bit late here...been busy trying to implement this stuff :-)

I'd suggest a couple of points, which I think can summarize where we are, and help us converge:

- If the RID message was successful, then the Acknowledgement message should be optional.
        - return HTTP status code 200.
- If the RID message was received OK (actual transport worked), but RID message was unsuccessful, then the (negative) Acknowledgement is required.
        - If the failure was in processing the RID message *content*, then HTTP status code is 200 because delivery (transport) worked fine.
                - The Acknowledgement message will explain the failure, i.e. use RequestStatus=Denied and
                        - Justification=(CannotProcess | UnrecognizedFormat | etc.  ) as appropriate.
                        - CannotProcess -> legal/policy exception.  UnrecognizedFormat -> syntax failure.
                                - There may be other Justifications needed....TBD.

I don't think we should require HTTP status 400 if the RID application message content was the problem.  The 400 code is specifically referring to the validity of the HTTP request.  For example, one must return 400 if the size of the actual HTTP body received does not agree with the value of the HTTP header "Content-length:  nnn".

Finally, it's important to note that an HTTP 4xx return code may be generated by the HTTP transport layer. But in this case, my RID application code -- higher up in the stack -- probably never even sees the RID message and so I don't get a chance to send the Acknowledgement.

In general, then, I think I agree with the original intent of RFC 6546 which was to use HTTP status codes 200 and 202, and use the Acknowledgement message to convey RID-specific status information.  Other HTTP status codes such as 400 or 405 may be generated by the lower layers in the stack, but these are not generated by RID processing logic.

So, I think I agree with the change that was originally proposed at the beginning of this thread (repeated here for your convenience :-)

>>>>> 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.
>>>>

However, now that I look at it, I wonder whether the statement is simply redundant, and out of scope for the RID transport specification.  Maybe we should say nothing at all about 400, since all we are doing with this new text is just restating HTTP behavior.  (This still does constitute a technical change since we would no longer be requiring the 400 status code when the error is with the RID content).

In addition, the 500 condition is required whenever the RID message cannot be processed *and the RID server is unable to generate an Acknowledgement*.

Last, but not least, I suggest that the comments in the previous paragraph of RFC 6546 about not generating/following 30x redirects are valid and should remain, but could be moved to the security considerations section (Not sure, but I think that would be an editorial change, not a technical one).

Sorry again for the long message.  I hope this helps.

Regards,
John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Thursday, November 29, 2012 11:37 AM
To: [email-masked]
Subject: Re: [mile] RFC6546 possible editorial errata

wfm

spt

On 11/28/12 3:49 PM, Brian Trammell wrote:
> 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
>
> On 28 Nov 2012, at 1:30, "Moriarty, Kathleen" <[email-masked]> wrote:
>
>> 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 4
 0
>   0 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,
>>
>> (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
>>
>> On Nov 27, 2012, at 10:11 PM, Moriarty, Kathleen wrote:
>>
>>> 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,
>>>
>>> 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
>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>>> Waltermire, David A.
>>>> Sent: Tuesday, November 27, 2012 10:57 AM
>>>> To: Moriarty, Kathleen; SM
>>>> Cc: [email-masked]
>>>> Subject: Re: [mile] RFC6546 possible editorial errata
>>>>
>>>> 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 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
>>>>
>>>> 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 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,
>>>> 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:
>>>>> 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.
>>>>
>>>> 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
>>>>
>>>> _______________________________________________
>>>> mile mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mile
>>>
>>> _______________________________________________
>>> mile mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mile
>>>
>>> _______________________________________________
>>> mile mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mile
>>
>
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>
_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile