Subject: [Simple] MSRP: direction attributes

From: Miguel Garcia <[email-masked]>
Date: Mon, 15 May 2006 13:27:08 +0300

Hi:

I think this issue was discussed, but never concluded, perhaps because 
we didn't copy the MSRP authors in the e-mail discussion.

Amit has been arguing that the MSRP I-D does not discuss the interaction 
of the SDP direction attributes with MSRP. To be more specific of the 
problem description, assume I have an SDP offer for an MSRP 
unidirectional session, so I would include the a=sendonly (if I want to 
send) attribute.

Now, I believe the direction attribute affects MSRP SEND request. 
Specifically, it shouldn't affect the generation of REPORT requests from 
the other party, as REPORT requests are kind-of control protocol.

Further more... the direction attribute shouldn't affect IMDN responses, 
which will be generated also with SEND requests.

As a counter party, I reproduce here what SDP-new says about this 
direction attributes and their relation to RTP and RTCP. I think we need 
to extrapolate the same ideas to MSRP:

          Note that recvonly
          applies to the media only, not to any associated control
          protocol (e.g. an RTP based system in recvonly mode SHOULD
          still send RTCP packets).

and later:

          Note that sendonly
          applies only to the media, and any associated control protocol
          (e.g.  RTCP) SHOULD still be received and processed as normal.

So, since the MSRP draft is silent about this relation of the SDP 
direction attributes, I think there should be an explicit mention of how 
to deal with. I can proposed to add the following text to the draft:

------
8.9   SDP direction attribute and MSRP

SDP defines a number of attributes that modify the direction of media 
flows. These are the "sendonly", "recvonly", "inactive", and "sendrecv" 
attributes.

If a "sendonly" or "recvonly" attribute modifies an MSRP media 
description line, the attribute indicates the direction of MSRP SEND 
requests that contain regular payload. Unless otherwise specified, these 
attributes do not affect the direction of other requests, such as 
REPORT, or SEND requests that contain some kind of control protocol 
(e.g., IMDN reports), which should be generated according to the 
protocol rules as if no direction attribute were present.
---

Is this acceptable? If so, please include this text in the draft and 
proceed with it as soon as possible.

BR,

         Miguel

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 May 2006 15:26:42 -0500

I agree in general with your opinion about how a=sendonly should work  
in MSRP.

My only concern about putting the language in the MSRP draft is that  
draft has already been submitted to the IESG. Assuming they don't ask  
for a rewrite, that leaves the option of adding it in the auth 48  
period, or creating a separate draft. I think this change is  
borderline for being appropriate for an auth 48 change. (Certainly,  
we've seen much more substantive auth48 changes before :-)  )

Perhaps the chairs will comment?

Comment on the proposed language inline:

On May 15, 2006, at 5:27 AM, Miguel Garcia wrote:

> Hi:
>
> I think this issue was discussed, but never concluded, perhaps  
> because we didn't copy the MSRP authors in the e-mail discussion.
>
> Amit has been arguing that the MSRP I-D does not discuss the  
> interaction of the SDP direction attributes with MSRP. To be more  
> specific of the problem description, assume I have an SDP offer for  
> an MSRP unidirectional session, so I would include the a=sendonly  
> (if I want to send) attribute.
>
> Specifically, it shouldn't affect the generation of REPORT requests  
> from the other party, as REPORT requests are kind-of control protocol.
>
> Further more... the direction attribute shouldn't affect IMDN  
> responses, which will be generated also with SEND requests.
>
> direction attributes and their relation to RTP and RTCP. I think we  
> need to extrapolate the same ideas to MSRP:
>
>          Note that recvonly
> direction attributes, I think there should be an explicit mention  
> of how to deal with. I can proposed to add the following text to  
> the draft:
>
>
> ------
> SDP defines a number of attributes that modify the direction of  
> media flows. These are the "sendonly", "recvonly", "inactive", and  
> "sendrecv" attributes.
>
> description line, the attribute indicates the direction of MSRP  
> SEND requests that contain regular payload. Unless otherwise  
> specified, these attributes do not affect the direction of other  
> requests, such as REPORT, or SEND requests that contain some kind  
> of control protocol (e.g., IMDN reports), which should be generated  
> according to the protocol rules as if no direction attribute were  
> present.
> ---
>

I agree with everything except the "or Send requests that contain  
some kind of control protocol..." part. I'm not sure we can  
generalize that all such content should ignore a sendonly attribute.  
It would be better to leave that up to the specification for the  
particular control protocol. It might make sense for IMDN, but if  
someone were to define the "mind control protocol for MSRP", for  
example, I'm not sure that overriding "sendonly" would make sense.

>
> Is this acceptable? If so, please include this text in the draft  
> and proceed with it as soon as possible.
>
> BR,
>
>         Miguel
>
> --

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 16 May 2006 22:35:57 +0200

On May 16, 2006, at 10:26 PM, Ben Campbell wrote:

> for a rewrite

That's a big assumption :) I think we ca add this clarifying text for a 
rev after the IETF last call.

Hisham

> , that leaves the option of adding it in the auth 48 period, or 
> creating a separate draft. I think this change is borderline for being 
> appropriate for an auth 48 change. (Certainly, we've seen much more 
> substantive auth48 changes before :-)  )
>
>> an MSRP unidirectional session, so I would include the a=sendonly (if 
>> I want to send) attribute.
>>
>> direction attributes, I think there should be an explicit mention of 
>> how to deal with. I can proposed to add the following text to the 
>> draft:
>>
>>
>> ------
>> flows. These are the "sendonly", "recvonly", "inactive", and 
>> "sendrecv" attributes.
>>
>> requests that contain regular payload. Unless otherwise specified, 
>> these attributes do not affect the direction of other requests, such 
>> as REPORT, or SEND requests that contain some kind of control 
>> protocol (e.g., IMDN reports), which should be generated according to 
>> the protocol rules as if no direction attribute were present.
>> ---
>>
>
> I agree with everything except the "or Send requests that contain some 
> kind of control protocol..." part. I'm not sure we can generalize that 
> all such content should ignore a sendonly attribute. It would be 
> better to leave that up to the specification for the particular 
> control protocol. It might make sense for IMDN, but if someone were to 
> define the "mind control protocol for MSRP", for example, I'm not sure 
> that overriding "sendonly" would make sense.
>
>>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 17 May 2006 15:57:15 +0200

On May 16, 2006, at 10:26 PM, Ben Campbell wrote:

> I agree in general with your opinion about how a=sendonly should  
> work in MSRP.
>
> My only concern about putting the language in the MSRP draft is  
> that draft has already been submitted to the IESG. Assuming they  
> don't ask for a rewrite, that leaves the option of adding it in the  
> auth 48 period, or creating a separate draft. I think this change  
> is borderline for being appropriate for an auth 48 change.  
> (Certainly, we've seen much more substantive auth48 changes  
> before :-)  )
>

We will need Jon's opinion on this but I suggest, write the text,  
make a diff, check it in to SVN - send the diff to Jon and see if  
wants to

a) have us submit new version
b) add it as RFC editor note
c) ignore (unlikely)

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 May 2006 09:01:44 -0500

Will do.

On May 17, 2006, at 8:57 AM, Cullen Jennings wrote:

>> don't ask for a rewrite, that leaves the option of adding it in  
>> the auth 48 period, or creating a separate draft. I think this  
>> change is borderline for being appropriate for an auth 48 change.