Subject: [Simple] message-session-07: why responses?

From: Pekka Pessi <[email-masked]>
Date: Thu, 12 Aug 2004 19:13:49 +0300

Hello all,

The current MSRP draft now includes extensive REPORT facilities. I
wonder why we still keep the responses in the spec?

During the discussion between Orit and rest of the world last
spring AFAIR the most compelling reason for hop-by-hop responses
is that they provide explicit keepalive functionality. When using
responses, relays have to buffer transactions only until they
receive application-level confirmation. Without response, relays
could not get any indication when the next-hop connection failed.

Could we simply use explicit keepalive messages, say, single-hop
SEND without body with Report-Success: yes (or PING/PONG a'la IRC
or HELLO or KEEPALIVE)? An MSRP entity could send such a keepalive
request any time, and it would know that all the messages sent
before keepalive were actually received when it receives the
suitable keepalive reply request.

Instead of error responses (like 401), we could use REPORT with
appropriate Status.

--Pekka

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

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 13 Aug 2004 18:42:43 -0700

Hi Pekka,

A few things:

- Certain types of errors are more appropriate to inform the requester 
about using a response (for example, a 403).

- Responses to SEND requests are hop-by-hop instead of end-to-end like 
REPORT requests.  This is actually used by different combinations of 
the current Report-Success / Report-Failure headers.

- Responses to AUTH are end-to-end.  We need to use responses to carry 
the Use-Path information in a response to an AUTH back to the MSRP 
Client that sent the AUTH request.  Because the way the authorization 
works, you can't carry this information in a REPORT.  You would need to 
send a REPORT request to a URI that the client didn't know about yet.

hope this helps.

thanks,
-rohan

---

From: Pekka Pessi <[email-masked]>
Date: Tue, 17 Aug 2004 19:07:54 +0300

Hi Rohan, 

>- Certain types of errors are more appropriate to inform the requester about
>using a response (for example, a 403).

>REPORT requests.  This is actually used by different combinations of the
>current Report-Success / Report-Failure headers.

>- Responses to AUTH are end-to-end.  

That is actually my main problem, some requests don't generate
responses (REPORT, anything with Report-Failure: partial/no), some
requests generate hop-by-hop responses, others end-to-end. It
looks like things get *interesting* when there is large payload in
a REPORT or AUTH or extension request (chunk or not to chunk...). 

The world would be happier place if an element could always just
send a REPORT, syntax would be simpler, there would be less
messages, protocol would be more symmetric, no conversion from
response to REPORT would be needed etc. etc.

Of course, a hop-by-hop REPORT is also *interesting*, like, it
probaly has to include either the transact-id or Byte-Range from
request it reports. However, the Report-Range (or something) is
probably needed by msrp-relay-01++, too, as it introduces the
REPORTs that are sent after each received chunk.

>We need to use responses to carry the Use-Path information in a
>response to an AUTH back to the MSRP Client that sent the AUTH
>request. Because the way the authorization works, you can't carry
>this information in a REPORT. You would need to send a REPORT
>request to a URI that the client didn't know about yet.

I don't see any reason why the challenge and/or credential headers
or Use-Path could not be transmitted in a special request. For
example, it is possible to use AUTH in both directions. An added
bonus is that a relay could authenticate itself with the client.

Of course, some of these issues must already have been discusssed,
but I'll try to catch up with the last 4 months of SIMPLE...

--Pekka

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 17 Aug 2004 09:51:37 -0700

Hi Pekka,

On Aug 17, 2004, at 9:07 AM, Pekka Pessi wrote:
>> the

The spec forbids sending contents larger than 2k in anything other than 
a SEND request. You MUST NOT chunk a REPORT or AUTH request.

> response to REPORT would be needed etc. etc.

Because of chunking, some intermediate relays need to keep a little bit 
of state. Without hop-by-hop responses, these relays cannot clean up.

If you banned response codes completely, you would still need something 
to carry the hop-by-hop status of send requests.  You could call this a 
RESPONSE request if you liked.  You could also try to combine this with 
the existing semantics of REPORT, but then you would need to add 
additional headers that the client would have to look at to figure out 
what the REPORT was about, and relays would still need to *convert* 
between one type of REPORT and another.  I don't see any benefit there.

> REPORTs that are sent after each received chunk.

Probably I should have mentioned the separation of semantics between 
responses and REPORTs.  I'm sorry I did not bring it up as it may help 
illustrate why these can be cleanly separated.  Responses carry 
information about the status of a *transaction*.  REPORT requests carry 
information about the delivery of a *complete message*.

The REPORT always contains the Message ID.  (The transaction ID of the 
last hop is meaningless to the original sender in an environment with 
any relays). I can already say in a REPORT that the message was 
abandoned at byte-range position 573,482. The Byte-Range header is just 
carried in the report.

> or Use-Path could not be transmitted in a special request.

I don't see any *benefit* to using a separate request either.  You 
still need to send the request over the same path over which you 
received it.  You now need an *additional* header to carry the 
transaction-id of the original request.  All the same restrictions and 
requirements are there.  Congratulations, you just added zero value to 
the protocol and you had to carry around an additional now meaningless 
psuedo-random identifier.

Furthermore, the semantics are that the transaction succeeded or 
failed.  That's what responses are for.

> For

It does not make sense to use AUTH in both directions. The relay 
already authenticates to the client by providing a certificate in the 
initial TLS exchange. The semantics of the AUTH request is that a 
client is requesting authorization of a URL on the relay.

thanks,
-rohan

---

From: Aki Niemi <[email-masked]>
Date: Tue, 17 Aug 2004 20:09:47 +0300

On Tue, 2004-08-17 at 19:51, ext Rohan Mahy wrote:
snip---
> of state. Without hop-by-hop responses, these relays cannot clean up.

Keep this state for what? For being able to retransmit, over TCP? Can't
the upstream node at least push back with a 4xx response, or is 2xx the
only one ever coming back?

Cheers,
Aki

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 17 Aug 2004 10:52:23 -0700

> only one ever coming back?

There are two categories of state.  For a relay just forwarding 
requests, but offering Report-Failure: yes, the relay needs to keep 
track of the sending URL for a specific message-id.  If the relay 
receives a negative response on a specific message-id, it needs to 
generate a REPORT back to the originator.

When rechunking, the relay also needs to buffer the incoming message, 
keep track of which byte-ranges have been received and which have not, 
deal with out-of-order chunks. The relay needs the hop-by-hop positive 
responses to figure out when it can flush various parts of its buffers.

thanks,
-rohan