Subject: [MMUSIC] Re: draft-ietf-mmusic-file-transfer-mech-04 (comments part 2)

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Nov 2007 20:19:34 -0400

Miguel,

Here are my remaining comments on the draft. I have tried to keep these 
distinct from what is being discussed in the other thread.

	Thanks,
	Paul

Section 6 (ABNF):

You removed all references to file-transfer-value, but it is still
defined as a token. Doesn't hurt, but is distracting. I suggest removing 
the definition.

The following:

    The 'hash' selector includes the hash algorithm and its value.
    Possible hash algorithms are those defined in the IANA registry of
    Hash Function Textual Names [2].  Implementations according to this
    specification MUST support the US Secure Hash Algorithm 1 (SHA1)
    [RFC3174].  If need arises, extensions can be drafted to support
    several hashing algorithms.  Therefore, implementations according to
    this specification MUST be prepared to receive SDP containing more
    than a single 'hash' selector in the 'file-selector' attribute.

still seems to be ambiguous about what the normative behavior
is. (I think you could *support* SHA-1 but not offer it and still 
conform to the above.) I think to be compatible with *this* 
specification, an offer that contains a hash must contain an SHA-1 hash. 
Seems like this is worth saying.

A couple of nits about the following:

    The 'file-range' attribute contains the start
    range and end range of the file, separated by a dash "-".  The start
    range value refers to the position of the file where the file
    transfer should start.  The first byte of a file gets the ordinal
    number "1".  The end range value refers position of the file where
    the file transfer should stop.  The end range value MAY contain a "*"
    if the total size of the file is not known in advance.

This reads a little funny due to the naming of the symbols in the
ABNF. The first sentence above implies that two *ranges* are specified -
a "start range" and an "end range", when what you mean is that there are
two values that specify the start and end of a single range. Later, in
8.1.2 you refer to "start offset" and "end offset" which reads much 
better. I suggest that you:

- change the abnf: s/start-range/start-offset/ and
   s/end-range/stop-offset/.

- Then change the text above correspondingly to use "start offset"
   and "stop offset", consistent with 8.1.2.

Also, the phrasing of 'The first byte of a file gets the ordinal number 
"1".' seems a bit odd. How about s/gets/is denoted by/?

Corner case: How is an empty file dealt with? Is it possible to specify
file-range:1-0? If no file-range is specified, then apparently that is
what the default will be. (I suppose if you *knew* the file was empty
there would be no reason to transfer it. But if there is a file which is
empty unbeknownst to you, is it desirable to transfer it? Or not? (I 
think 1-* should denote the whole file even if the file is empty.) I 
won't feel too bad if you don't say anything about this - its something 
that perhaps only I would notice.

Section 8.1.1:

    The file sender MUST add a 'file-transfer-id'
    attribute containing a new identifier value, i.e., not used within
    the current session.

I think this could be clearer about the scope and uniqueness of this
value. Once again 3pcc rears its ugly head. What may seem to be a single
session to one party may in fact map to multiple sessions on the other
side of a B2BUA. If sessions are switched on one side then there is the
possibility of reusing a file transfer id and confusing the other side.
In section 8.1.2 randomness is required, but not here. That would
eliminate the ambiguity. It also might be worth reiterating
that this needs to be random, rather than just different from the prior
offer.

Section 8.2:

I think the explanation of what to do if file-transfer-id isn't new is
still incomplete here. At the moment it is mentioned in 8.2.2, but not
in 8.2.1. Also, in the case where it isn't new the characterizations of
the cases for 8.2.1 and 8.2.2 (of answerer as receiver or sender) are
themselves incomplete. (For the o/a that actually initiates a transfer
the answerer might be the receiver, but then another o/a is done in the
other direction, so that in that exchange the answerer might
hypothetically be the "sender".) So it might be clearer to reserve
sections 8.2.1 and 8.2.2 for those cases where the file-transfer-id is
new, and add another section or two for the case(s) where the file
transfer id is not new.

Also, I wonder about the scope of checking for uniqueness of file 
transfer ids. Noting that the value is the same or different from the 
prior value for the same m= line position is sufficient to distinguish 
the start of a new transfer from a previous transfer. What value is 
there in further uniqueness? Requiring that all previously used ids be 
remembered seems to be an unnecessary burden.

There isn't any clear statement here of what to do if the
file-transfer-id isn't new. But we've been discussing that on the other 
thread, so it would be distracting to discuss it here too.

I have another obscure corner case having to do with 3pcc:

Alice is connected to Bob indirectly via a 3pcc controller CC. They have 
previously transferred a file, which has completed. For some reason CC 
decides to replace Bob in the call with Dave. So CC sends an offerless 
invite to Alice, and sends that on as an offer in an INVITE to Dave.

The SDP from Alice has the MSRP specification and the file-transfer-id 
that had been used with Bob, and they now go to Dave. Dave thinks this 
is the initiation of a new file transfer and a new MSRP connection. He 
will return an answer with a path that is presumably different from the 
prior one. Now what does Alice do?

Section 8.3:

See earlier comments on scope and uniqueness.

Section 8.5:

In general an m= line can be recycled for some entirely different 
purpose. So it could by reused for m=audio in a reinvite. Or it could be 
used for a conversational (non-file-transfer) MSRP session, by omitting 
the file-transfer-id. The latter may not be so obvious, so it might be 
worth stating.

Section 8.6:

You are very explicit that the MSRP *session* cannot be reused for 
another file transfer. But you don't say the same MSRP *connection* 
can't be reused. In fact section 9.2 shows sending two files with the 
same m= line, but explicitly mentions establishing a separate TCP 
connection for each.

It would be a *feature* if the connection could be serially reused for a 
succession of files. (In fact, if you have a *lot* of files to transfer 
it may be very important.) Have you thought about that? Have you 
concluded its undesirable, or too hard to do?

OK. That's all. Sorry for being so lengthly.

Miguel Garcia wrote:
> Hi Paul:
> 
> A few days ago I submitted a new version of the file transfer draft. I 
> was wondering if you could get some spare time to review the draft. Not 
> totally, but perhaps only the list of changes. Since you have reviewed 
> earlier versions, I think your input is much needed.
> 
> This is the draft:
> http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-04.html 
> 
> http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-04.txt 
> 
> 
> And this is the track changes:
> http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-04-from-3.html 
> 
> 
> List of changes:
> 
> - Added the notion of a file-transfer identifier, which is materialized
> in the 'file-transfer-id' attribute. It contains a new identifier per
> new file transfer. This is to avoid that a repetition of the SDP (due to
> session timers, or adding new media streams) causes a new file transfer
> and aborts the ongoing one. The 'file-transfer-id' attribute replaces
> the existing 'file-transfer' attribute.
> 
> - The existing draft had a lot of complexity for dealing with several
> hashing algorithms. Since we use the has just for file transfer
> verification and file identification, just using a single algorithm
> seems to serve the purpose. So, the current version uses SHA-1 and
> leaves the door open for future extensions that can define new hashing
> algorithms.
> 
> - Clarified the requirements that other protocol than MSRP should
> fulfill in order to be used for the file transfer.
> 
> - Clarified that 'sendonly' and 'recvonly' refers to the direction of
> MSRP SEND request, and does not preclude other MSRP messages (200, REPORT).
> 
> - The name selector syntax allows percent encoding.
> 
> - Fixed an error with the hash value syntax
> 
> - The 'file-range' attribute allows to signal the
> "last-byte-of-the-file" with a "*" character (like in MSRP).
> 
> - The 'file-range' terminology has made it consistent: now the terms
> "start range" and "end range" are used to refer to the two integers that
> define the file range.
> 
> - Clarified that it is mandatory to implement message/cpim, but its
> usage is negotiated in SDP.
> 
> - Clarified the use case that involves a non-supporting endpoint wwhich
> does not also support multipart MIME and receives an SDP offer with a
> side-by icon body.
> 
> - Noted that the hash is not used for strong integrity verification.
> 
> - Several other minor clarifications.
> 
> 
> If you find issues, please post them to the MMUSIC list (and cc: me and 
> the other authors).
> 
> Thanks in advance,
> 
>      Miguel
> 
> 

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

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 05 Nov 2007 15:02:39 +0200

Inline

> defined as a token. Doesn't hurt, but is distracting. I suggest removing 

Oh, this is a mistake; It should remain, but it should read
file-transfer-id-value

s/file-transfer-value/file-transfer-id-value

or something shorter, due to lack of space.
> Seems like this is worth saying.

Reasonable... So, I have rephrased a sentence in the text that now reads:

       Implementations according to
       this specification MUST add a <xref target="RFC3174">US
       Secure Hash Algorithm 1 (SHA1)</xref> value if the 'hash'
       selector is present.

>   and "stop offset", consistent with 8.1.2.

Good one, done.

> "1".' seems a bit odd. How about s/gets/is denoted by/?

Good. Much better.
> that perhaps only I would notice.

Interesting... I think we don't have support for "send me an empty
number of bytes". So, the file-range has to have at least one byte. It
does not make sense to request to transfer 0 bytes.

A different thing is if you request a file (without file-range) and it
happens that the file has zero bytes. Then, you will get the metadata,
but nothing else. I think this is a reasonable use case, and it is
supported by the current spec.

My suggestion is do nothing in the document.

> that this needs to be random, rather than just different from the prior

I agree, it should be random. I have modified the above sentence in
8.1.1 to read:

             The
	    file sender MUST add a 'file-transfer-id' attribute
	    containing a new randomly chosen identifier value, which
	    does not clash with other previously used values in the
	    same attribute.

> in 8.2.1. 

I have added the following text at the beginning of Section 8.2.1:

             When the file receiver gets the SDP offer, it
	    first examines the 'file-transfer-id' attribute. If the
	    value of the 'file-transfer-id' attribute has been
	    previously used then the existing session remains without
	    changes, perhaps the file transfer is still in progress,
	    or perhaps it has concluded, but there are no change with
	    respect the current status. The SDP answerer creates a
             regular SDP answer and sends it to the offerer.

The remaining text considers the case when the file-transfer-id 
attribute is new.

> Also, in the case where it isn't new the characterizations of

Wait a minute. In a re-INVITE, the roles of offerer and answerer can be 
swapped with respect the initial INVITE, I agree. But the roles "file 
sender" and "file receiver" are also swapped, so... everything works 
without any  further considerations.

With respect your idea to keep 8.2.1 and 8.2.2 for the initial offer, I 
prefer to keep the structure of the draft close to what implementations 
have to code. I believe the starting point is if you create an SDP offer 
or you receive an SDP offer, not if the offer is initial or not. So, 
let's try to make the implementor's life easier and keep the text 
similar to what people implement.

> remembered seems to be an unnecessary burden.

Notice that the text requires to remember all the values used within the 
same session, not for.... ever. In principle you are right, you just 
need to distinguish if there has been a change with respect the previous 
value. But somehow, I feel more comfortable demanding to remember all 
the previous values for the same session. Typically this is not a big 
burden. So, I prefer to be conservative here.

> prior one. Now what does Alice do?

Erggg... Yeah, good question... Perhaps it should be like this:
- If Alice is the file sender, should she detect the change and send the 
file again? This somehow defeats the purpose of the file-transfer-id, 
which is: if the value does not change, there isn't file transfer

- If Alice is the file receiver, then there shouldn't be a new file 
transfer, but it will be a new one (if Dave happens to have the same 
file). This is because Dave knows nothing about the previous file 
transfer with Bob.

So, what should we say... It is well known that 3PCC breaks a number of 
advanced scenarios... perhaps we should just say that 3PCC breaks file 
transfer.

> purpose. So it could by reused for m=audio in a reinvite. 

Is this possible in SDP? I thought it isn't possible. Somehow I always 
thought that one you write an m= line in SDP, you can never remove it. 
You can set the port to zero, but never totaly remove it or re-use it 
for different media.

> Or it could be 

Theoretically, it is possible. But I would rather restrict the use case 
so that an MSRP-for-file-transfer is not used for conversational MSRP 
and vice versa. It might be a mess to re-use an existing file transfer 
MSRP session for sending instant messaging.

Also: the most likely use case is that two users are already chatting in 
an MSRP session, and then one sends a file to the other. Considering 
that adding an m= line to SDP is "free", I would go for that approach, 
rather than re-using existing lines

> concluded its undesirable, or too hard to do?

The spirit of the draft is to reuse TCP connections for several 
simultaneous or sequential file transfers. This is covered in Section 
8.1.3, which reads:

	    Using an "m=" line per file implies that different files
	    are transferred using different MSRP sessions. However,
	    all those MSRP sessions can be set up to run over a single
	    TCP connection, as described in Section 8.1 of <xref
	    target="RFC4975">RFC 4975 </xref>.

I have also added now:

             The same TCP connection can also be re-used for sequential
             file transfers.

Now, let's examine the example in Section 9.2. This is a pull operation, 
where Alice establishes the TCP connection towards Bob. In the first SDP 
exchange, Bob signals port 8888 in his path attribute. In the second SDP 
exchange, Bob signals port 9999, so obviously Alice would need to 
establish a second TCP connection, since the port number has changed. 
So, the current example is technically correct.

HOWEVER: I think the current example does not represent the behavior of 
most implementations, but just a corner case. So, what I am going to do 
is to change the example, so that the ports used for MSRP are kept 
intact in the second SDP offer. Then, the text of the second SDP 
exchange can say that since a TCP connection is already established, 
there is no need to establish a new TCP connection.

Thanks for all the comments.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland