A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer
RFC 5547

Note: This ballot was opened for revision 11 and is now closed.

(Cullen Jennings) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2009-01-29)
No email
send info
I too would have wanted to see negotiation of existing file transfer mechanisms as opposed to a new one. Is this mechanism deployed, and have the other IM protocols done for the same functionality? There may of course be reasons why an integrated file transfer mechanism is needed.

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Pasi Eronen) No Objection

(Russ Housley) No Objection

(Chris Newman) (was Discuss) No Objection

Comment (2009-01-28)
No email
send info
I'm concerned by the creation of yet-another-file-transfer mechanism.  As
if we didn't have enough with FTP, SFTP, SCP, TFTP, HTTP, RCP,
RSYNC, etc.  Did the authors evaluate reusing existing file transfer
technology and enhancing it to support the missing features, as
necessary?  I can perhaps see the justification for some of the SDP
negotiation, but this is a very monolithic architecture rather than
a more traditional Internet component-based architecture.  This seems
to be re-inventing a traditional IETF application.

I'm also concerned by the complexity of this architecture, particularly
given that it potentially mixes generic file transfer in the same stream
with IM traffic and IM attachments creating a potentially nasty content
dispatching problem as well as a multiplexing problem (something that
has deployed poorly in the applications layer with SSH being perhaps the
sole exception of a widely deployed/used channel multiplexing
technology at that layer).

Although I'm not a huge fan of our media feature standards due to their
complexity, they are the standards we have for cases where one endpoint
is requesting content that meets certain characteristics from another
endpoint.  Why were these existing standards not used?  Was reuse at
least evaluated?  I note the lemonade WG was specifically constrained
to reuse media features by its charter so there are people who feel
strongly about this in the IETF community.  The lemonade WG ended up
reusing the feature tag registry, although not the rest of the framework
based on complexity evaluation.

I'm putting these three issues in a comment as I don't see them as
actionable and thus will not hold a blocking discuss over these issues
(although I may choose to abstain on this document after IESG
discussions).

(Jon Peterson) No Objection

(Tim Polk) No Objection

Comment (2009-01-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 5, para 3 sentence 2
s/selects those file/selects those files/

Section 10, last sentence

s/to dismiss the risk of damage/to mitigate the risk of damage/
(if you don't like mitigate, limit or reduce would work, too!)

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

Comment (2009-03-31)
No email
send info
I've seen multiple implementations of this already - it is alive in the wild. 

I'm agree that better tools for describing what would be accessed would make a more robust system and hope that future work explores that avenue.

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund No Objection

Comment (2009-01-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
C1. Section 6: ABNF errors

attribute            = file-selector-attr / file-disp-attr /
                          file-tr-id-attr / file-date-attr /
                          file-icon-attr / file-range-attr
                          ;attribute is defined in RFC 4566

This would if combined with the RFC 4566 ABNF override the attribute definition which I don't think the intention is. One way to express this correct would be to use the /= between the rulename and the rule extension. 

   filetype-selector    = "type:" type "/" subtype *(";"parameter)

There is a missing white space between ";" and parameter

C2. Section 6: 

I think there might be good to be clearer in the text around the below sentence that all 160 bits of the SHA-1 output is included:

   Implementations according to this
   specification MUST add a US Secure Hash Algorithm 1 (SHA1) [RFC3174]
   value if the 'hash' selector is present.

(Lisa Dusseault) Abstain

Comment (2009-01-29 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The functionality to request a file be sent to the offerer seems ill-motivated and thus it's impossible for a reader to tell if the design meets the requirements of the (unstated) use cases.  I can't tell what use cases exist for requiring a file by name, rather than by kind or other metadata.  

One possibility is that this feature won't be used if the functionality doesn't meet any important use cases.  Another possibility is that it could be used in ways not quite met by the functionality offered -- for example, users could start to use well-known file names like "avatar.jpg" for requests like "Please send me a file that is appropriate for use as an avatar to represent your persona".