Subject: [MMUSIC] WGLC on draft-ietf-mmusic-file-transfer-mech-07.txt

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 15 Apr 2008 15:47:14 -0600

This is to announce a Working Group Last Call for comments on 
http://tools.ietf.org/html/draft-ietf-mmusic-file-transfer-mech-07

Please provide your comments to the authors and the mmusic mailing list
by April 30, 2008 (two weeks from today).

Thank you,
Joerg and Jean-Francois.

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Vikram Chhibber" <[email-masked]>
Date: Mon, 28 Apr 2008 11:29:33 +0530

There is one correction I see in section 8.4
"  A file receiver that wishes to abort an ongoing transfer first must
   determine if the MSRP sender wishes to receive failure reports.  If
   the current MSRP SEND request sets the Failure-Report header to a
   value different than "no", then the file receiver generates an MSRP
   413 response to the current MSRP SEND request (see Section 10.5 of
   RFC 4975 [RFC4975]).  Then the file receiver SHOULD close the MSRP
   session.  This is done by sending a new SDP offer that sets the port
   number to zero in the related "m=" line that describes the file
   transfer (see Section 8.2 of RFC 3264 [RFC3264]).  This SDP offer
   MUST conform with the requirements expressed in Section 8.1.2.  The
   'file-transfer-id' attribute MUST be the same that identifies the
   ongoing transfer.  Then the file sender sends the SDP offer to the
   file receiver."

The last line should be: "Then the file sender sends the SDP answer to
the file receiver."

Also, what prevents the file sender to send re-INVITE with port 0 for
file-transfer media description if it receives 413 response? This may
lead to crossing of re-INVITE requests resulting in 491 response. This
can happen other way too when the sender aborts the file transfer, on
receiving '#', the receiver can send re-INVITE with port 0. Do we
emphasis that the "aborter" should only send re-INVITE?

---

From: <[email-masked]>
Date: Mon, 28 Apr 2008 13:30:15 +0300

Vikram:

Inline comments. 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Vikram Chhibber
>Sent: 28 April 2008 09:00
>To: Jean-Francois Mule
>Cc: [email-masked]
>Subject: Re: [MMUSIC] WGLC on 
>draft-ietf-mmusic-file-transfer-mech-07.txt
>
>There is one correction I see in section 8.4 "  A file 
>receiver that wishes to abort an ongoing transfer first must
>The last line should be: "Then the file sender sends the SDP 
>answer to the file receiver."

No, no, it isn't like that. The whole paragraph is about creating an SDP
offer to abort a file. A file receiver creates the SDP offer and sends
to to the file sender, so, the last sentence should say "Then the file
receiver sends the SDP offer to the file sender".

>
>
>Also, what prevents the file sender to send re-INVITE with 
>port 0 for file-transfer media description if it receives 413 
>response? This may lead to crossing of re-INVITE requests 
>resulting in 491 response. This can happen other way too when 
>the sender aborts the file transfer, on receiving '#', the 
>receiver can send re-INVITE with port 0. Do we emphasis that 
>the "aborter" should only send re-INVITE?

Nothing prevents the file sender to send a re-INVITE at any time,
including the situation you describe.

But I think that the entity who aborts the file transfer should be
responsible for doing it at both the media and signaling level, but
nothing prevents for the other party to abort the signaling, once the
media has been aborted. 

I'll take these comments into account when creating a new revision.

/Miguel

>>  Please provide your comments to the authors and the mmusic mailing 
>> list  by April 30, 2008 (two weeks from today).
>>
>>  Thank you,
>>  Joerg and Jean-Francois.
>>