A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer
draft-ietf-mmusic-file-transfer-mech-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
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-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 |