Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2020-01-21
11 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
11 (System) Notify list changed from mmusic-chairs@ietf.org, draft-ietf-mmusic-file-transfer-mech@ietf.org to (None)
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Chris Newman
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2009-05-06
11 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2009-05-06
11 Cindy Morgan [Note]: 'RFC 5547' added by Cindy Morgan
2009-05-05
11 (System) RFC published
2009-04-02
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-04-02
11 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-04-02
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-04-01
11 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-04-01
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-04-01
11 (System) IANA Action state changed to In Progress
2009-04-01
11 Cindy Morgan IESG state changed to Approved-announcement sent
2009-04-01
11 Cindy Morgan IESG has approved the document
2009-04-01
11 Cindy Morgan Closed "Approve" ballot
2009-03-31
11 Robert Sparks
[Ballot comment]
I've seen multiple implementations of this already - it is alive in the wild.

I'm agree that better tools for describing what would …
[Ballot comment]
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.
2009-03-31
11 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2009-03-09
11 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2009-02-18
11 Chris Newman [Ballot Position Update] Position for Chris Newman has been changed to No Objection from Discuss by Chris Newman
2009-02-17
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-02-17
11 (System) New version available: draft-ietf-mmusic-file-transfer-mech-11.txt
2009-01-30
11 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2009-01-30
11 (System) Removed from agenda for telechat - 2009-01-29
2009-01-29
11 (System) [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by IESG Secretary
2009-01-29
11 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2009-01-29
11 Lisa Dusseault
[Ballot comment]
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 …
[Ballot comment]
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".
2009-01-29
11 Lisa Dusseault [Ballot Position Update] New position, Abstain, has been recorded by Lisa Dusseault
2009-01-29
11 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2009-01-29
11 Jari Arkko
[Ballot comment]
I too would have wanted to see negotiation of existing file transfer mechanisms as opposed to a new one. Is this mechanism deployed, …
[Ballot comment]
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.
2009-01-29
11 Jari Arkko
[Ballot discuss]
This is related to the context-sensitive grammar issue, but I have
an additional problem. ABNF parsers actually fail to parse the ABNF
here: …
[Ballot discuss]
This is related to the context-sensitive grammar issue, but I have
an additional problem. ABNF parsers actually fail to parse the ABNF
here:

  filetype-selector    = "type:" type "/" subtype *(";"parameter)
2009-01-29
11 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2009-01-29
11 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2009-01-29
11 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2009-01-28
11 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-01-28
11 Chris Newman
[Ballot comment]
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.  …
[Ballot comment]
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).
2009-01-28
11 Chris Newman
[Ballot discuss]
The following ABNF:

  filetype-selector    = "type:" type "/" subtype *(";"parameter)
                      …
[Ballot discuss]
The following ABNF:

  filetype-selector    = "type:" type "/" subtype *(";"parameter)
                                      ; parameter defined in RFC 2045

results in a grammar that is extremely context-sensitive.
The RFC 2045 "parameter" ABNF allows free insertion of
linear-white-space (including comments and line folding), so the
following would be legal:
    type:foo/bar;blatz=( hash:sha-1:... ) hash
In addition, the variant of quoted string used for parameter values
by RFC 2045 allows a construction such as:
    type:foo/bar;blatz="\" hash:sha-1:.."
In the two examples above, the "hash:sha-1" is part of the comment
or parameter value, not a selector.

If this really is your intention, I recommend adding some examples
showing the degenerate parsing cases so people following the spec
can test their parsers.  Otherwise, updates to the ABNF may be
appropriate to simplify these cases.
2009-01-28
11 Chris Newman [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman
2009-01-28
11 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2009-01-28
11 Tim Polk
[Ballot comment]
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 …
[Ballot comment]
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!)
2009-01-28
11 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2009-01-28
11 Magnus Westerlund
[Ballot comment]
C1. Section 6: ABNF errors

attribute            = file-selector-attr / file-disp-attr /
              …
[Ballot comment]
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.
2009-01-28
11 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-01-27
11 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-01-24
11 Cullen Jennings State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Cullen Jennings
2009-01-24
11 Cullen Jennings Placed on agenda for telechat - 2009-01-29 by Cullen Jennings
2009-01-24
11 Cullen Jennings [Ballot Position Update] New position, Yes, has been recorded for Cullen Jennings
2009-01-24
11 Cullen Jennings Ballot has been issued by Cullen Jennings
2009-01-24
11 Cullen Jennings Created "Approve" ballot
2009-01-22
10 (System) New version available: draft-ietf-mmusic-file-transfer-mech-10.txt
2008-12-24
11 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-12-23
11 Amanda Baber
IANA comments:

Upon approval of this document, IANA will make the following
assignments in the "att-field (media level only)" registry at
http://www.iana.org/assignments/sdp-parameters

Type SDP Name …
IANA comments:

Upon approval of this document, IANA will make the following
assignments in the "att-field (media level only)" registry at
http://www.iana.org/assignments/sdp-parameters

Type SDP Name Reference
---- ------------------ ---------
att-field (media level only)
file-date [RFC-mmusic-file-transfer-mech-09]
file-disposition [RFC-mmusic-file-transfer-mech-09]
file-icon [RFC-mmusic-file-transfer-mech-09]
file-range [RFC-mmusic-file-transfer-mech-09]
file-selector [RFC-mmusic-file-transfer-mech-09]
file-transfer-id [RFC-mmusic-file-transfer-mech-09]

We understand the above to be the only IANA Actions for this document.
2008-12-19
11 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Richard Barnes.
2008-12-13
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Richard Barnes
2008-12-13
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Richard Barnes
2008-12-10
11 Amy Vezza Last call sent
2008-12-10
11 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-12-10
11 Cullen Jennings State Changes to Last Call Requested from AD Evaluation by Cullen Jennings
2008-12-10
11 Cullen Jennings Last Call was requested by Cullen Jennings
2008-12-10
11 (System) Ballot writeup text was added
2008-12-10
11 (System) Last call text was added
2008-12-10
11 (System) Ballot approval text was added
2008-12-10
11 Cullen Jennings State Changes to AD Evaluation from Publication Requested by Cullen Jennings
2008-11-17
11 Cindy Morgan
PROTO writeup for: draft-ietf-mmusic-file-transfer-mech-09.txt
          title: A Session Description Protocol (SDP) Offer/Answer
      Mechanism to Enable File Transfer

Requested …
PROTO writeup for: draft-ietf-mmusic-file-transfer-mech-09.txt
          title: A Session Description Protocol (SDP) Offer/Answer
      Mechanism to Enable File Transfer

Requested Publication Status: Proposed Standard
PROTO shepherd: Joerg Ott (MMUSIC WG Co-Chair)

---------------------------------------------------------------------------

    (1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

    The document shepherd is Joerg Ott , co-chair
    of the MMUSIC WG.

    I have personally reviewed this document and consider it ready
    for publication.  Besides the textual review, the ID nits tool
    has not found any issues and the contained ABNF compiles.

    (1.b) Has the document had adequate review both from key WG members
          and from key non-WG members? Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

    The draft has received ample discussion based upon repeated solid
    reviews over a number of years and has been subject to repeated
    discussion in the WG meetings.  The breadth and depth of the
    reviews were adequate.  Implementations

    (1.c) Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

    No.  The draft expands on SDP for which MMUSIC is the responsible
    WG and on MSRP for which review was provided by individual members
    of the SIMPLE WG.

    (1.d) Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of? For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it. In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

    No concerns.  No IPR disclosures filed.

    (1.e) How solid is the WG consensus behind this document? Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

    The draft has undergone two Working Group Last Calls (on -05 and -07)
    and the comments received were incorporated into the draft.  There
    is solid consensus inside the WG for publication.

    (1.f) Has anyone threatened an appeal or otherwise indicated extreme
          discontent? If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director. (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

    No.

    (1.g) Has the Document Shepherd personally verified that the
          document satisfies all ID nits? (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/). Boilerplate checks are
          not enough; this check needs to be thorough. Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

    Yes.  All checks pass.

    (1.h) Has the document split its references into normative and
          informative? Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state? If such normative references exist, what is the
          strategy for their completion? Are there normative references
          that are downward references, as described in [RFC3967]? If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

    Yes, the references are split.
    No, there are no dependencies on incomplete documents.

    (1.i) Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

    Yes, the IANA section exists, matches the content of the document,
    and clearly identifies the action and target contacts.

    (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

    Yes.

    (1.k) The IESG approval announcement includes a Document
          Announcement Write-Up. Please provide such a Document
          Announcement Write-Up? Recent examples can be found in the
          "Action" announcements for approved documents. The approval
          announcement contains the following sections:
          Technical Summary
              Relevant content can frequently be found in the abstract
              and/or introduction of the document. If not, this may be
              an indication that there are deficiencies in the abstract
              or introduction.
          Working Group Summary
              Was there anything in WG process that is worth noting? For
              example, was there controversy about particular points or
              were there decisions where the consensus was particularly
              rough?
          Document Quality
              Are there existing implementations of the protocol? Have a
              significant number of vendors indicated their plan to
              implement the specification? Are there any reviewers that
              merit special mention as having done a thorough review,
              e.g., one that resulted in important changes or a
              conclusion that the document had no substantive issues? If
              there was a MIB Doctor, Media Type or other expert review,
              what was its course (briefly)? In the case of a Media Type
              review, on what date was the request posted?

    Proposed announcment text:

    Technical summary:

        The document defines extensions to the SDP offer/answer model
to enable file transfer as part of SDP-negotiated multimedia
sessions.  It also specifies using MSRP for the actual file
transmission.

    Working Group summary:

        The MMUSIC WG has firm consenses on publishing this document
as Proposed Standard.

    Document quality:

        The document is considered ready for publication.

    An early interoperability test of independent implementations
from various major vendors on an image sharing specification
(which uses the file transfer I-D as a basis) took place
already in 2007 under the auspices of the GSM Association.
The interop event provided useful input for this and other
specifications.

    Personnel:

        The document shepherd is Joerg Ott, the responsible AD is
Cullen Jennings.
2008-11-17
11 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2008-11-03
09 (System) New version available: draft-ietf-mmusic-file-transfer-mech-09.txt
2008-05-20
08 (System) New version available: draft-ietf-mmusic-file-transfer-mech-08.txt
2008-03-27
07 (System) New version available: draft-ietf-mmusic-file-transfer-mech-07.txt
2007-12-21
06 (System) New version available: draft-ietf-mmusic-file-transfer-mech-06.txt
2007-11-19
05 (System) New version available: draft-ietf-mmusic-file-transfer-mech-05.txt
2007-10-24
04 (System) New version available: draft-ietf-mmusic-file-transfer-mech-04.txt
2007-06-05
03 (System) New version available: draft-ietf-mmusic-file-transfer-mech-03.txt
2007-05-18
02 (System) New version available: draft-ietf-mmusic-file-transfer-mech-02.txt
2007-04-27
01 (System) New version available: draft-ietf-mmusic-file-transfer-mech-01.txt
2006-12-18
00 (System) New version available: draft-ietf-mmusic-file-transfer-mech-00.txt