Subject: [Simple] MSRP: Report-Failure partial

From: Miguel Garcia <[email-masked]>
Date: Tue, 14 Dec 2004 13:53:48 +0200

Hi:

I am trying to understand the concise procedures that affect the 
Report-Failure: partial in MSRP, and I think I am missing something.

On reading the MSRP draft I found contradictory text:

- Second paragraph on 7.1.3 says:

    If the endpoint receives a SEND request with a Report-Failure header
    field ...  "partial", it MUST NOT send a transaction response to the
    request, but SHOULD send an appropriate non-200 class response a
    failure occurs.

So I understand that "partial" means "don't send 200, but send any other 
response".

- Section 7.3 says:

    When the
    request is received, the To-Path will have exactly one URL, which
    MUST map to an existing session that is associated with the
    connection on which the request arrived.  If this is not true, and
    the request contained a Report-Failure header value of "no" or
    "partial", then the receiver SHOULD quietly ignore the request.  If
    the Report-Failure header is not present, or had a value of "yes",
    then the receiver MUST return a 481 response.

Here the text says that "partial" means don't send a 481 response, which 
is obviously in contradiction with 7.1.3.

- Section 7.3.1 then says.

    If the SEND request contained a Content-Type header field indicating
    an unsupported MIME type, the receiver SHOULD send a 415 response or
    failure report, as appropriate for the Report-Failure header field
    value.

That is misleading me in another aspect: by reading the above text I may 
think that the Report-Failure header field value determines whether and 
endpoint sends failure responses or REPORT requests. So one could think 
that "Report-Failure: yes" means send REPORt requests rather than 
failure responses, whereas "Report-Failure: no" means the opposite. I 
believe this is not the intention, right?

So is this something that can be further clarified in the document?

Regards,

         Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Dec 2004 22:22:21 -0700

The goal of "partial" was to report errors except timeouts. The timeout
require the sending hop to run a timer and that receiving hop to send an
acknowledgement to stop the timer. Some systems don't want the overhead of
doing this so choose not to but still report other errors.

We may have the text messed up to describe this.

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 16 Dec 2004 12:05:11 +0200

Cullen:

The explanation about partial looks good. I would welcome this kind of 
discussion written in the base draft, it will certainly help to 
understand things better.

- Miguel

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 18 Dec 2004 12:27:21 -0800

ok - I added some text like that -  will be in next version. More inline

>>> is obviously in contradiction with 7.1.3.
This is wrong - will fix  - have changed to

If this is not true then the receiver MUST generate an 481 error and ignore
the
request. Note that if the Failure-Report header had a value of "no", then no
error report would be sent.

>>> believe this is not the intention, right?

Yep - clear as mud :-) How about

If the SEND request contained a Content-Type header field indicating an
unsupported MIME type, the receiver MUST generate a failure report with a
415 error code. Note that this failure report will not be sent if the
Report-Failure header contains a value of "no".