Subject: Re: [Simple] Re: IMDN: Do we need record-route?

From: Hisham Khartabil <[email-masked]>
Date: Thu, 2 Nov 2006 10:06:35 +0100

When you implement IMDN, you will not implement specific 
implementations for SIP MESSAGE and MSRP SEND. It is not mandatory to 
populate the IM and IMDN requests with the headers in question.

Hisham

On Oct 30, 2006, at 8:38 AM, Miguel Garcia wrote:

> I am not really convinced that we need IMDN record route. Let's try to 
> analyze it.
>
> I would expect that an MSRP IM receiver that gets a request for IMDN, 
> builds an MSRP SEND request that has the same headers (namely 
> From-Path and To-Path) than any other regular SEND request that the 
> endpoint would send. So, if the network (relays, intermediaries, 
> mixers, etc.) is able to route any asynchronous SEND request that such 
> endpoint would send, it would route any IMDN in the same manner.
>
> I would not expect that the endpoint has to dig into the IMDN CPIM 
> headers of the received IM to build an MSRP SEND request (that carries 
> the IMDN) in a different manner than any other regular SEND request. 
> Not having to take a look at the record-route headers will simplify 
> implementations substantially, because the IMDN will be considered a 
> special payload of a regular SEND request (at the moment the spec. 
> considers it a special payload f a special SEND request).
>
> I would therefore, advocate for removing these headers in MSRP IMDN.
>
> /Miguel
>
> Eric Burger wrote:
>> On the one hand, good point. On the other, won¹t the MSRP relays be
>> transparent? If so, then I would leave the specification as is, 
>> especially
>> since once we take it out someone will want to gateway from MSRP to 
>> SMS ;-)
>> On 10/26/06 5:42 AM, "Miguel Garcia" <[email-masked]> 
>> wrote:
>>> Hi:
>>>
>>> First, I want to express my support for the current version of the 
>>> IMDN
>>> draft, I think it is going in the right direction. Especially, it is
>>> easier to read than earlier versions.
>>>
>>> The draft defines the Original-To, IMDN-Route, and IMDN-Record-Route
>>> CPIM headers. I see the need for this CPIM headers when SIP is the
>>> transport protocol. However, I don't find a reason for them if MSRP 
>>> is
>>> the transport protocol. I think endpoints will send IMDNs through the
>>> same MSRP logical session where the IM was received. If at the other
>>> side there is an intermediary, for sure there is some logic on top 
>>> that
>>> is able to route back to the original sender.
>>>
>>> So is there a usage of these headers in MSRP?
>>>
>>> BR,
>>>
>>>         Miguel
>>> --
>>> Miguel A. Garcia           tel:+358-50-4804586
>>> sip:[email-masked]
>>> Nokia Research Center      Helsinki, Finland
>>>
>
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> sip:[email-masked]
> Nokia Research Center      Helsinki, Finland
>
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
>

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

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 02 Nov 2006 11:23:34 +0200

But what you are saying is that, when you implement IMDN, you need to do 
a specific implementation of MSRP for IMDN, which makes less sense.

I disagree with your statement that when you implement IMDN you wouldn't 
do specific implementations for SIP MESSAGE and MSRP SEND, at least, the 
draft seems to indicate the opposite in Sections 12 and 13. 
Specifically, Section 13.1.1 already contains normative text indicating 
differences between SIP and MSRP.

    "Therefore, an IM Sender MUST NOT create MSRP SEND
    requests requiring a positive-delivery notification or a negative-
    delivery notification."

/Miguel

Hisham Khartabil wrote:
> When you implement IMDN, you will not implement specific implementations 
> for SIP MESSAGE and MSRP SEND. It is not mandatory to populate the IM 
> and IMDN requests with the headers in question.
> 
> Hisham
> 
>>> On 10/26/06 5:42 AM, "Miguel Garcia" <[email-masked]> wrote:
>>>> Hi:
>>>>
>>>> First, I want to express my support for the current version of the IMDN
>>>> transport protocol. However, I don't find a reason for them if MSRP is
>>>> side there is an intermediary, for sure there is some logic on top that

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 2 Nov 2006 15:44:11 +0100

I was referring to the processing of the IMDN. If there are 
IMDN-Record-Route headers in the IM, then the client convert those into 
IMDN-Route headers in the IMDN. If intermediaries don't add any 
IMDN-Record-Route headers (in the case of MSRP relays), the client 
realises there are none and routes the IMDN accordingly.

Hisham

On Nov 2, 2006, at 10:23 AM, Miguel Garcia wrote:

> But what you are saying is that, when you implement IMDN, you need to 
> do a specific implementation of MSRP for IMDN, which makes less sense.
>
> I disagree with your statement that when you implement IMDN you 
> wouldn't do specific implementations for SIP MESSAGE and MSRP SEND, at 
> least, the draft seems to indicate the opposite in Sections 12 and 13. 
> Specifically, Section 13.1.1 already contains normative text 
> indicating differences between SIP and MSRP.
>
>>> I am not really convinced that we need IMDN record route. Let's try 
>>> to analyze it.
>>>
>>> I would expect that an MSRP IM receiver that gets a request for 
>>> IMDN, builds an MSRP SEND request that has the same headers (namely 
>>> mixers, etc.) is able to route any asynchronous SEND request that 
>>> such endpoint would send, it would route any IMDN in the same 
>>> manner.
>>>
>>> headers of the received IM to build an MSRP SEND request (that 
>>> carries the IMDN) in a different manner than any other regular SEND 
>>> request. Not having to take a look at the record-route headers will 
>>> simplify implementations substantially, because the IMDN will be 
>>> considered a special payload of a regular SEND request (at the 
>>> moment the spec. considers it a special payload f a special SEND 
>>> request).
>>>

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 03 Nov 2006 08:53:32 +0200

But this is the problem: due to the IMDN processing, the implementation 
now needs to do something especial: inspect the Record Route headers, 
and send the message to that next-hop. What happens if the next hop is 
an entity that does not have an active MSRP session with the IM 
Receiver? Do we need to INVITE? To who, what happens if the Record-Route 
contains an MSRP URI? Do you create an INVITE addressed in the 
Request-URI to the MSRP URI? You see, things don't make sense (IMHO).

I would expect that an IM receiver parses the request for an IMDN, 
creates the IMDN, and blindly feeds the IMDN in the same MSRP session 
where the IM was received. This works in scenarios with MSRP relays, 
intermediaries, etc. And this simplifies the implementation and makes it 
consistent with any other IM that the IM receiver would have got, and 
reply to.

/Miguel

Hisham Khartabil wrote:
>>>> such endpoint would send, it would route any IMDN in the same manner.
>>>>