The IESG has approved the following documents: - 'The Message Session Relay Protocol ' <draft-ietf-simple-message-sessions-19.txt> as a Proposed Standard - 'Relay Extensions for the Message Sessions Relay Protocol (MSRP) ' <draft-ietf-simple-msrp-relays-10.txt> as a Proposed Standard These documents are products of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-19.txt Technical Summary A series of related instant messages between two or more parties can be viewed as part of a "message session", that is, a conversational exchange of messages with a definite beginning and end. This is in contrast to individual messages each sent independently. Messaging schemes that track only individual messages can be described as "page-mode" messaging, whereas messaging that is part of a "session" with a definite start and end is called "session-mode" messaging. This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Working Group Summary This document reflects WG consensus. It defines the Message Session Relay Protocol (MSRP). The working group has been working on this draft for years and have arrived at this after several re-starts. Protocol Quality This document was reviewed for the IESG by Jon Peterson. Hisham Khartabil was the PROTO shepherd for this document. RFC Editor Note On draft-ietf-simple-message-sessions-19.txt: Section 7.2 paragraph 3 OLD The endpoint then inserts an appropriate To-Path header field. If the request triggering the response was a SEND request, the To-Path header field is formed by copying the last (right-most) URI in the From-Path header field of the request. (Responses to SEND requests are returned only to the previous hop.) For responses to all other request methods, the To-Path header field contains the full path back to the original sender. This full path is generated by taking the list of URIs from the From-Path of the original request, reversing the list, and writing the reversed list into the To-Path of the response. (Legal REPORT requests do not request responses, so this specification doesn't exercise the behavior described above, however we expect that extensions for gateways and relays will need such behavior.) NEW The endpoint then inserts an appropriate To-Path header field. If the request triggering the response was a SEND request, the To-Path header field is formed by copying the first (left-most) URI in the From-Path header field of the request. (Responses to SEND requests are returned only to the previous hop.) For responses to all other request methods, the To-Path header field contains the full path back to the original sender. This full path is generated by copying the list of URIs from the From-Path of the original request into the To- Path of the response. (Legal REPORT requests do not request responses, so this specification doesn't exercise the behavior described above, however we expect that extensions for gateways and relays will need such behavior.) Section 7.1.1 paragraph 7 OLD If the value of "Failure-Report" is set to "yes", then the sender of the request runs a timer. If a 200 response to the transaction is not received within 30 seconds from the time the last byte of the transaction is sent, or submitted to the operating system for sending, the element MUST inform the user that the request probably failed. If the value is set to "partial", then the element sending the transaction does not have to run a timer, but MUST inform the user if it receives a non-recoverable error response to the transaction. NEW If the value of "Failure-Report" is set to "yes", then the sender of the request runs a timer. If a 200 response to the transaction is not received within 30 seconds from the time the last byte of the transaction is sent, or submitted to the operating system for sending, the element MUST inform the user that the request probably failed. If the value is set to "partial", then the element sending the transaction does not have to run a timer, but MUST inform the user if it receives a non-recoverable error response to the transaction. There is no requirement to wait for a response prior to sending the next request. Section 7.2 Last Paragraph OLD Finally, the endpoint inserts a From-Path header field containing the URI that identifies it in the context of the session, followed by the end-line after the last header field. The response MUST be transmitted back on the same connection on which the original request arrived. NEW Finally, the endpoint inserts a From-Path header field containing the URI that identifies it in the context of the session, followed by the end-line after the last header field. Since a response is never chunked, the continuation flag in the end-line will always contain a dollar sign ("$"). The response MUST be transmitted back on the same connection on which the original request arrived. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
