Session Description Protocol (SDP) Media Capabilities Negotiation
draft-ietf-mmusic-sdp-media-capabilities-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-02-26
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-01-18
|
17 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-01-17
|
17 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-01-11
|
17 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-01-08
|
17 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-01-07
|
17 | (System) | IANA Action state changed to In Progress |
2013-01-07
|
17 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2013-01-07
|
17 | Amy Vezza | IESG has approved the document |
2013-01-07
|
17 | Amy Vezza | Closed "Approve" ballot |
2013-01-07
|
17 | Amy Vezza | Ballot approval text was generated |
2013-01-04
|
17 | Alexey Melnikov | Request for Telechat review by GENART Completed: Ready. Reviewer: Alexey Melnikov. |
2013-01-04
|
17 | Flemming Andreasen | New version available: draft-ietf-mmusic-sdp-media-capabilities-17.txt |
2013-01-03
|
16 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2012-12-20
|
16 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2012-12-20
|
16 | Ralph Droms | |
2012-12-20
|
16 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-12-20
|
16 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-12-20
|
16 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-12-20
|
16 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-12-19
|
16 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-12-19
|
16 | Pete Resnick | [Ballot comment] One minor question added to my original comments: The writeup does not indicate any implementation of this. Is that true? There are no … [Ballot comment] One minor question added to my original comments: The writeup does not indicate any implementation of this. Is that true? There are no implementations yet? This stuff is well outside of my area of expertise. After a read through, I have found nothing *in* my area of expertise that is problematic. A couple of requirements language issues, but nothing that should stop the document unless other ADs think these problems could cause serious problems: 3.4.1.1: The following happens elsewhere in the document, but this is a good example: Each potential configuration MUST include a config-number that is unique in the entire SDP... That's ambiguous. What "MUST" be done here? Do you mean: Each potential configuration MUST include a config-number, which is unique in the entire SDP. Or do you mean: The config-number of each potential configuration MUST be unique in the entire SDP. Or do you mean: Each potential configuration MUST include a config-number, and each config-number MUST be unique in the entire SDP. Which is it? They have 3 different meanings. The first is saying to the implementer, "You might not think the config number is required, but it is and you'll screw up the other side if you leave it out." The second is saying, "You might not think the config number needs to be unique, but it does and you'll screw up the other side if it's not." And the third is saying the combination of the first two. It is probably worth reviewing 2119 usage throughout the document, as ambiguities in requirements is a bad thing. And even though this is ambiguous, the RFC Editor will likely not try to correct it because they always assume that things around requirements language were worded carefully. Please check them. 3.4.2.1: The answerer MUST first determine... I very much doubt that this is an interoperability requirement. There are several instances of this sort. Please remove these MUSTs. |
2012-12-19
|
16 | Pete Resnick | Ballot comment text updated for Pete Resnick |
2012-12-19
|
16 | Pete Resnick | [Ballot comment] This stuff is well outside of my area of expertise. After a read through, I have found nothing *in* my area of expertise … [Ballot comment] This stuff is well outside of my area of expertise. After a read through, I have found nothing *in* my area of expertise that is problematic. A couple of requirements language issues, but nothing that should stop the document unless other ADs think these problems could cause serious problems: 3.4.1.1: The following happens elsewhere in the document, but this is a good example: Each potential configuration MUST include a config-number that is unique in the entire SDP... That's ambiguous. What "MUST" be done here? Do you mean: Each potential configuration MUST include a config-number, which is unique in the entire SDP. Or do you mean: The config-number of each potential configuration MUST be unique in the entire SDP. Or do you mean: Each potential configuration MUST include a config-number, and each config-number MUST be unique in the entire SDP. Which is it? They have 3 different meanings. The first is saying to the implementer, "You might not think the config number is required, but it is and you'll screw up the other side if you leave it out." The second is saying, "You might not think the config number needs to be unique, but it does and you'll screw up the other side if it's not." And the third is saying the combination of the first two. It is probably worth reviewing 2119 usage throughout the document, as ambiguities in requirements is a bad thing. And even though this is ambiguous, the RFC Editor will likely not try to correct it because they always assume that things around requirements language were worded carefully. Please check them. 3.4.2.1: The answerer MUST first determine... I very much doubt that this is an interoperability requirement. There are several instances of this sort. Please remove these MUSTs. |
2012-12-19
|
16 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-12-19
|
16 | Stephen Farrell | [Ballot comment] - 3.3.5: Does the crypto field only ever contain symmetric key material or initialisation values? If so, why only have a SHOULD NOT … [Ballot comment] - 3.3.5: Does the crypto field only ever contain symmetric key material or initialisation values? If so, why only have a SHOULD NOT for use of real key materials in a latent (or potential?) configuration? I don't see why that is not a MUST NOT. Actually, having a MUST for some known value would maybe be even better, e.g. all zeros, so long as that didn't break anything. (Same thing if crypto can occur in an answer as a latent value.) |
2012-12-19
|
16 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-12-18
|
16 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-12-18
|
16 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-12-18
|
16 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-12-18
|
16 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-12-17
|
16 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-12-17
|
16 | Robert Sparks | [Ballot comment] Nits: Do you want to explicitly say whether a range of 3-1 is semantically legal? It is syntactically valid, and the text doesn't … [Ballot comment] Nits: Do you want to explicitly say whether a range of 3-1 is semantically legal? It is syntactically valid, and the text doesn't require the number represented by the digits to the right of the hyphen to be greater than that to the left. This (and several documents that have gone before it) use 1*10(DIGIT) for things like media-cap-num. That means it would be syntactically valid to say things like a=rmcap:1 PCMU/8000 and a=rmcap:00001 PCMU/8000 Do those mean the same thing? If someone included a pcfg with m=0001|0002 in an offer, and the answer had a acfg with m=1, should the offerer recognize that as the same as its 0001? Would it be better to restrict the syntax to avoid this question? |
2012-12-17
|
16 | Robert Sparks | [Ballot Position Update] New position, Yes, has been recorded for Robert Sparks |
2012-12-17
|
16 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-12-13
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to Alexey Melnikov |
2012-12-13
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to Alexey Melnikov |
2012-12-13
|
16 | Gonzalo Camarillo | Placed on agenda for telechat - 2012-12-20 |
2012-12-13
|
16 | Gonzalo Camarillo | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2012-12-13
|
16 | Gonzalo Camarillo | Ballot has been issued |
2012-12-13
|
16 | Gonzalo Camarillo | [Ballot Position Update] New position, Yes, has been recorded for Gonzalo Camarillo |
2012-12-13
|
16 | Gonzalo Camarillo | Created "Approve" ballot |
2012-12-13
|
16 | Gonzalo Camarillo | Ballot writeup was changed |
2012-12-12
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-12-12
|
16 | Flemming Andreasen | New version available: draft-ietf-mmusic-sdp-media-capabilities-16.txt |
2012-11-26
|
15 | Alexey Melnikov | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Alexey Melnikov. |
2012-11-21
|
15 | Gonzalo Camarillo | State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead |
2012-11-12
|
15 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-11-09
|
15 | Pearl Liang | IANA has reviewed draft-ietf-mmusic-sdp-media-capabilities-15 and has the following comments: IANA understands that, upon approval of this document, there are five actions which IANA must complete. … IANA has reviewed draft-ietf-mmusic-sdp-media-capabilities-15 and has the following comments: IANA understands that, upon approval of this document, there are five actions which IANA must complete. First, in the SDP Attrribute subregistry - att-field (both session and media level) - in the Session Description Protocol (SDP) Parameters registry located at: www.iana.org/assignments/sdp-parameters/sdp-parameters.xml the following four SDP attributes will be registered as follows: Type: att-field (both session and media level) SDP Name: rmcap Reference: [ RFC-to-be ] Type: att-field (both session and media level) SDP Name: omcap Reference: [ RFC-to-be ] Type: att-field (both session and media level) SDP Name: mfcap Reference: [ RFC-to-be ] Type: att-field (both session and media level) SDP Name: mscap Reference: [ RFC-to-be ] Second, in the SDP Attribute subregistry - att-field (media level only) - in the Session Description Protocol (SDP) Parameters registry located at: www.iana.org/assignments/sdp-parameters/sdp-parameters.xml the following SDP attribute will be registered as follows: Type: att-field (media level only) SDP Name: lcfg Reference: [ RFC-to-be ] Third, in the SDP Attribute subregistry - att-field (session level) - in the Session Description Protocol (SDP) Parameters registry located at: www.iana.org/assignments/sdp-parameters/sdp-parameters.xml the following SDP attribute will be registered as follows: Type: att-field (session level) SDP Name: sescap Reference: [ RFC-to-be ] Fourth, in the SDP Capability Negotiation Option Tags subregistry in the Session Description Protocol (SDP) Parameters registry located at: www.iana.org/assignments/sdp-parameters/sdp-parameters.xml the following SDP Capability Negotiation Option Tag will be registered as follows: Option Tag: med-v0 Reference: [ RFC-to-be ] Fifth, a series of changes are to be made to the SDP Capability Negotiation Potential Configuration Parameters subregistry in the Session Description Protocol (SDP) Parameters registry located at: www.iana.org/assignments/sdp-parameters/sdp-parameters.xml The name of the registry should be "SDP Capability Negotiation Configuration Parameters Registry" The registry will be changed to have the following information for each registration: Encoding Name: The syntactical value used for the capability negotiation configuration parameter, as defined in [RFC5939], Section 3.5. Descriptive Name: The name commonly used to refer to the capability negotiation configuration parameter. Potential Configuration Definition: A reference to the RFC that defines the configuration parameter in the context of a potential configuration attribute. If the configuration parameter is not defined for potential configurations, the string "N/A" (Not Applicable) MUST be present instead. Actual Configuration Definition: A reference to the RFC that defines the configuration parameter in the context of an actual configuration attribute. If the configuration parameter is not defined for actual configurations, the string "N/A" (Not Applicable) MUST be present instead. Latent Configuration Definition: A reference to the RFC that defines the configuration parameter in the context of a latent configuration attribute. If the configuration parameter is not defined for latent configurations, the string "N/A" (Not Applicable) MUST be present instead. The registration policy is changed to RFC Required as defined in RFC 5226. The existing registrations will be changed as follows: Encoding Name: a Descriptive Name: Attribute Configuration Potential Configuration Definition: [RFC5939] Actual Configuration Definition: [RFC5939] Latent Configuration Definition: [ RFC-to-be ] Encoding Name: t Descriptive Name: Transport Protocol Configuration Potential Configuration Definition: [RFC5939] Actual Configuration Definition: [RFC5939] Latent Configuration Definition: [ RFC-to-be ] In addition, three new registrations will be made in the newly modified registry: Encoding Name: m Descriptive Name: Media Configuration Potential Configuration Definition: [ RFC-to-be ] Actual Configuration Definition: [ RFC-to-be ] Latent Configuration Definition: [ RFC-to-be ] Encoding Name: pt Descriptive Name: Payload Type Number Mapping Potential Configuration Definition: [ RFC-to-be ] Actual Configuration Definition: [ RFC-to-be ] Latent Configuration Definition: [ RFC-to-be ] Encoding Name: mt Descriptive Name: Media Type Potential Configuration Definition: N/A Actual Configuration Definition: N/A Latent Configuration Definition: [ RFC-to-be ] IANA understands that these five actions are the only ones required upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. |
2012-11-01
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2012-11-01
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2012-11-01
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Lt. Mundy |
2012-11-01
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Lt. Mundy |
2012-10-29
|
15 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Session Description Protocol (SDP) Media Capabilities … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Session Description Protocol (SDP) Media Capabilities Negotiation) to Proposed Standard The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Session Description Protocol (SDP) Media Capabilities Negotiation' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. This document updates the IANA Considerations of RFC 5939. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-media-capabilities/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-media-capabilities/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/829/ |
2012-10-29
|
15 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-10-29
|
15 | Amy Vezza | Last call announcement was changed |
2012-10-27
|
15 | Gonzalo Camarillo | Last call was requested |
2012-10-27
|
15 | Gonzalo Camarillo | Ballot approval text was generated |
2012-10-27
|
15 | Gonzalo Camarillo | Ballot writeup was generated |
2012-10-27
|
15 | Gonzalo Camarillo | State changed to Last Call Requested from Publication Requested |
2012-10-27
|
15 | Gonzalo Camarillo | Last call announcement was generated |
2012-10-27
|
15 | Gonzalo Camarillo | Last call announcement was generated |
2012-10-04
|
15 | Amy Vezza | Document Writeup As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version … Document Writeup As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Standards Track (2) 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 The Session Description Protocol (SDP) has a general framework for endpoints to indicate and negotiate capabilities within SDP. However, the base framework defines capabilities for negotiating transport protocols and attributes. In this document, the SDP capability negotiation framework is extended with the ability to additionally indicate and negotiate media types and their associated parameters. Working Group Summary The first version of the document is dating February 2007. Since then, the MMUSIC working group has been progressing the document until getting satisfied with the current version. 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? The document has been reviewed and contributed by many participants of the working group, among others: Culleng Jennings, Christer Holmberg, Matt Lepinski, Joerg Ott, Colin Perkins, Thomas Stach, Ingemar Johansson, Andrew Allen, and Magnus Westerlund. The document was first WGLCed on version 10 (July 2010) and subsequently on version 14 (July 2012). All the open issues have been addressed and the WG has got consensus on version 15. Personnel Miguel Garcia is the Document Shepherd. Gonzalo Camarillo is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd has reviewed version 13 and the requested (minor) changes introduced in versions 14 and 15. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The document has been widely reviewed throughout the time. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. There is no need for this type of reviews. (6) Describe any specific concerns or issues that the Document Shepherd has 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. The Document Shepherd is satisfied with the document. There are no extra concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, authors have confirmed that all appropriate IPR disclosure has been filed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR disclosure #829 submitted. The mailing list was informed on April 4th, 2007. There has not been any e-mail discussion regarding this IPR disclosure. (9) 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 document represents a solid consensus from the WG. It is believed that the WG as a whole understand and agrees with it. (10) 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 publicly available.) No, no such threat exists. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. IDnits reports no issues. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such review is required in this document. (13) Have all references within this document been identified as either normative or informative? Yes, all references are classified as either normative or informative. (14) 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 plan for their completion? There is no such dependency (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document updates RFC 5939, just because an existing registry, initially created by RFC 5939, is modified and updated by this document. The actual extensions defined by this document do not update any document. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The Document Shepherd has reviewed the IANA considerations section. The aim of the section is clear and well done. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None such registries require Expert Review. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The Document Shepherd has validated the ABNF with the BAP parser. BAP indicates a few suggestions to improve the readability of the ABNF. The ABNF seems to be correct. |
2012-10-04
|
15 | Amy Vezza | Note added 'Miguel Garcia (Miguel.A.Garcia@ericsson.com) is the Document Shepherd.' |
2012-10-04
|
15 | Amy Vezza | Intended Status changed to Proposed Standard |
2012-10-04
|
15 | Amy Vezza | IESG process started in state Publication Requested |
2012-10-04
|
15 | Miguel García | IETF state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2012-10-04
|
15 | Miguel García | Annotation tag Doc Shepherd Follow-up Underway cleared. |
2012-10-04
|
15 | Miguel García | Annotation tag Doc Shepherd Follow-up Underway set. |
2012-10-04
|
15 | Miguel García | Changed protocol writeup |
2012-10-04
|
15 | Miguel García | Annotation tag Doc Shepherd Follow-up Underway set. |
2012-10-02
|
15 | Miguel García | - |
2012-10-02
|
15 | Miguel García | Adding write-up |
2012-10-02
|
15 | Flemming Andreasen | New version available: draft-ietf-mmusic-sdp-media-capabilities-15.txt |
2012-08-22
|
14 | Miguel García | IETF state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2012-07-10
|
14 | Miguel García | IETF state changed to In WG Last Call from WG Document |
2012-07-10
|
14 | Miguel García | Annotation tag Other - see Comment Log cleared. |
2012-07-09
|
14 | Miguel García | Consensus achieved. Waiting for shepherd to complete the write-up |
2012-07-09
|
14 | Miguel García | 2-week WGLC started on July 10th, 2012 |
2012-07-09
|
14 | Miguel García | 2-week WGLC started on July 10th, 2012 |
2012-07-09
|
14 | Flemming Andreasen | New version available: draft-ietf-mmusic-sdp-media-capabilities-14.txt |
2012-03-12
|
13 | Flemming Andreasen | New version available: draft-ietf-mmusic-sdp-media-capabilities-13.txt |
2011-10-31
|
12 | (System) | New version available: draft-ietf-mmusic-sdp-media-capabilities-12.txt |
2011-09-01
|
12 | (System) | Document has expired |
2011-07-26
|
12 | Miguel García | Version -10 passed WGLC in August 2010. More discussion and work is needed in the Offer/Answer procedures. |
2011-07-26
|
12 | Miguel García | Annotation tag Other - see Comment Log set. |
2011-03-01
|
11 | (System) | New version available: draft-ietf-mmusic-sdp-media-capabilities-11.txt |
2010-07-12
|
10 | (System) | New version available: draft-ietf-mmusic-sdp-media-capabilities-10.txt |
2010-02-27
|
09 | (System) | New version available: draft-ietf-mmusic-sdp-media-capabilities-09.txt |
2009-07-10
|
08 | (System) | New version available: draft-ietf-mmusic-sdp-media-capabilities-08.txt |
2009-02-26
|
07 | (System) | New version available: draft-ietf-mmusic-sdp-media-capabilities-07.txt |
2009-01-09
|
06 | (System) | New version available: draft-ietf-mmusic-sdp-media-capabilities-06.txt |
2008-07-14
|
05 | (System) | New version available: draft-ietf-mmusic-sdp-media-capabilities-05.txt |
2008-07-12
|
04 | (System) | New version available: draft-ietf-mmusic-sdp-media-capabilities-04.txt |
2008-02-25
|
03 | (System) | New version available: draft-ietf-mmusic-sdp-media-capabilities-03.txt |
2007-11-15
|
02 | (System) | New version available: draft-ietf-mmusic-sdp-media-capabilities-02.txt |
2007-03-16
|
(System) | Posted related IPR disclosure: Cisco's Statement about IPR claimed in draft-ietf-mmusic-sdp-media-capabilities-01.txt | |
2007-02-21
|
01 | (System) | New version available: draft-ietf-mmusic-sdp-media-capabilities-01.txt |
2007-02-14
|
00 | (System) | New version available: draft-ietf-mmusic-sdp-media-capabilities-00.txt |