SDP: Session Description Protocol
draft-ietf-mmusic-sdp-new-26
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
26 | (System) | post-migration administrative database adjustment to the No Objection position for Ted Hardie |
2012-08-22
|
26 | (System) | post-migration administrative database adjustment to the No Objection position for Bill Fenner |
2012-08-22
|
26 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2006-02-21
|
26 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2006-02-14
|
26 | Amy Vezza | IESG state changed to Approved-announcement sent |
2006-02-14
|
26 | Amy Vezza | IESG has approved the document |
2006-02-14
|
26 | Amy Vezza | Closed "Approve" ballot |
2006-02-14
|
26 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2006-02-14
|
26 | Jon Peterson | Note field has been cleared by Jon Peterson |
2006-01-25
|
26 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-01-25
|
26 | (System) | New version available: draft-ietf-mmusic-sdp-new-26.txt |
2006-01-19
|
26 | Jon Peterson | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jon Peterson |
2006-01-13
|
26 | Michelle Cotton | IANA Comments: The following message was sent to Jon. Not sure if there was any follow-up to these questions. -----Original Message----- From: Michelle Cotton [mailto: … IANA Comments: The following message was sent to Jon. Not sure if there was any follow-up to these questions. -----Original Message----- From: Michelle Cotton [mailto:michelle.cotton@icann.org] Sent: Thursday, December 01, 2005 4:09 PM To: 'jon.peterson@neustar.biz' Subject: IANA Comments: draft-ietf-mmusic-sdp-new-25.txt Hi Jon, So I just reviewed draft-ietf-mmusic-sdp-new-25.txt and have a couple questions. I can't find if there is anything new that IANA needs to do. Do the references need change in the sdp-parameters registry for those registrations mentioned in this document? I can't find the Encryption Key Access Methods registry...any ideas where this is or if it ever got set up? I'm not super clear that what the IANA registration rules are. Is RFC3388 still the document that is the official document describing the registration rules for sdp parameters? RFC3388 say a Standards track document is needed. This document says the following as well: IANA may refer any registration to the IESG Transport Area Directors for review, and may request revisions to be made before a registration will be made. Sorry if these questions are all over the place. I'm at the ICANN meeting right now...I'm super tired (esp after going through all those docs for the telechat today!) :) Let me know if I can clarify anything. Looking forward to your response. Thanks, Michelle IANA |
2005-12-02
|
26 | (System) | Removed from agenda for telechat - 2005-12-01 |
2005-12-01
|
26 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2005-12-01
|
26 | (System) | [Ballot Position Update] Position for Ned Freed has been changed to Discuss from No Record |
2005-12-01
|
26 | (System) | [Ballot Position Update] Position for Steven Bellovin has been changed to Discuss from No Record |
2005-12-01
|
26 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten |
2005-12-01
|
26 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand |
2005-12-01
|
26 | (System) | [Ballot Position Update] Position for Erik Nordmark has been changed to Yes from No Record |
2005-12-01
|
26 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2005-12-01
|
26 | Russ Housley | [Ballot discuss] Please expand the security considerations to include the following points: - It is generally a good idea to indicate the algorithm … [Ballot discuss] Please expand the security considerations to include the following points: - It is generally a good idea to indicate the algorithm that a cryptographic key is intended to support. However, the k= field does not provide this tagging. - Many security protocols require two keys, one for confidentiality and another for integrity. However, the k= field can only provide a single key. |
2005-12-01
|
26 | Bert Wijnen | [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen |
2005-12-01
|
26 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley |
2005-11-30
|
26 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2005-11-30
|
26 | Russ Housley | [Ballot discuss] Please expand the security considerations to include the following points: - It is generally a good idea to indicate the algorithm … [Ballot discuss] Please expand the security considerations to include the following points: - It is generally a good idea to indicate the algorithm that a cryptographic key is intended to support. However, the k= field does not provide this tagging. Please tell implementors how to deal with this shortcoming. - Many security protocols require two keys, one for confidentiality and another for integrity. However, the k= field can only provide a single key. Please tell implementors how to deal with this shortcoming. Is there a particular security protocol and algorithm for which this mechanism works well? |
2005-11-30
|
26 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman |
2005-11-30
|
26 | Scott Hollenbeck | [Ballot comment] I've looked at Ned's old discuss and believe it has been addressed. The normative reference to RFC 2234 should be updated to 4234, … [Ballot comment] I've looked at Ned's old discuss and believe it has been addressed. The normative reference to RFC 2234 should be updated to 4234, but I assume that'll be done by the RFC Editor. |
2005-11-30
|
26 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2005-11-30
|
26 | Brian Carpenter | [Ballot comment] Long editorial comments are in the Gen-ART review by Spencer Dawkins. I wouldn't mind seeing a new version that takes account of these. … [Ballot comment] Long editorial comments are in the Gen-ART review by Spencer Dawkins. I wouldn't mind seeing a new version that takes account of these. Review will be placed at http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-mmusic-sdp-new-25-dawkins.txt |
2005-11-30
|
26 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter |
2005-11-28
|
26 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman |
2005-11-22
|
26 | Jon Peterson | State Changes to IESG Evaluation from IESG Evaluation::Point Raised - writeup needed by Jon Peterson |
2005-11-22
|
26 | Jon Peterson | Placed on agenda for telechat - 2005-12-01 by Jon Peterson |
2005-11-22
|
26 | Jon Peterson | [Note]: 'Ancient returning item: no longer has enough ballot positions to advance. Mercy for these poor souls, new reviewers!' added by Jon Peterson |
2005-10-21
|
26 | Bill Fenner | [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Discuss by Bill Fenner |
2005-10-19
|
26 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie |
2005-10-19
|
26 | Ted Hardie | [Ballot comment] I've decided to move to no-objection for this, and to enter the previous DISCUSS text as a comment. I still think the issues … [Ballot comment] I've decided to move to no-objection for this, and to enter the previous DISCUSS text as a comment. I still think the issues should be fixed, but I've decided it is better not to hold the draft for them. n Section 5, for the description of u= I'd suggest eliminating "as used by WWW clients." and adding a citation to draft-fielding-uri-rfc2396bis (or at least rfc2396). Note that this definition seems to presume that all URIs used will be dereferencable, which is not true for all URIs. If this is a limitation, then it should be stated. The k= also seems to presume that the URI is dereferencable. If this is a limitation of the URI, it should be made explicit which schemes are appropriate here. Frankly, it seems to mean http:; if that is the case, specifying it seems like a good idea. Even for dereferencable URI schemes, not all will use MIME to mark the reply (think of an ftp: URI, for example). When they do, the mime content-encoding specifies the encoding of the _message_, so reusing the word "encoding" here seems problematic. How would "For those URI schemes which use MIME, the content-encoding and content-type headers of the reply may provide guidance on the format of the key." work? On that same hobby horse, the ABNF in the appendix has: ; sub-rules of 'u=' uri = URI-reference; see RFC1630 and RFC2732 I think this should be a pointer to 2396 or the 2396bis draft. For the a= inactive designation, we've discussed what addresses to use for sessions which are being set up but for which addresses are not yet known. It was suggested apps use something like "sdp.inactive" so that the .inactive TLD could reinforce the a=inactive flag. In that instance, would the presence of that TLD be a condition under which the RTCP SHOULD is appropriately not done, and no RTCP sent? If so, is mentioning that case appropriate here? In the IANA considerations, it looks the draft should specify that the IANA must update the MIME media type registration to point to this doc instead of RFC 2327. Notes: Having Section 5 contain so much without sub-headers made it hard to give pointers to sections in the comments; that may be true for others using the spec as well. In section 5, in the section describing the first subfield of c= Just as a query, has anyone considered using a specific marker of private address realms for SDP? That is, using a network type other than IN to indicate that the domain name or address given are not globally unique/globally reachable? In the Security considerations, "Many different protocols may be used to distribute session description," looks like session description should be plural. |
2005-08-18
|
26 | Erik Nordmark | [Ballot comment] Comment transferred from old ballot: Intro/abstract doesn't say the document obsoletes RFC 2137, which I think is the intent. The text on … [Ballot comment] Comment transferred from old ballot: Intro/abstract doesn't say the document obsoletes RFC 2137, which I think is the intent. The text on internationalization says UTF-8 only applies to informational fields. Does this mean it isn't required to perform any normalization whatsoever on the UTF-8? Would it make sense to explicitly state that normalization isn't needed. Typo: removed. It is assumed that transports of SDP specify will specify this. s/specify// |
2005-08-18
|
26 | Steven Bellovin | [Ballot discuss] Discuss comment transferred from old ballot: k= strikes me as almost useless. It doesn't have enough information (such as algorithm) to really be … [Ballot discuss] Discuss comment transferred from old ballot: k= strikes me as almost useless. It doesn't have enough information (such as algorithm) to really be usable. I see no protection against replay prevention, nor any mention of that as a requirement for secure transport of SDP announcements. In fact, nothing is said about channel requirements in this context other than "secure and trusted". Is k= really used? Should it be deleted in favor of a pointer to draft-ietf-mmusic-sdescriptions? The Security Consideration section says that automatic mechanisms SHOULD NOT be used to start up interactive applications without user knowledge. I'd prefer MUST NOT, and I'd ask for consent, not simplhy knowledge. See the /dev/audio part of http://www.cert.org/advisories/CA-1993-15.html for why this is a problem... |
2005-08-18
|
26 | Ned Freed | [Ballot discuss] Discuss comment transferred from old ballot: This document should explicitly say it obsoletes RFC 2327. This document apparently defines the application/sdp media … [Ballot discuss] Discuss comment transferred from old ballot: This document should explicitly say it obsoletes RFC 2327. This document apparently defines the application/sdp media type, replacing the definition in RFC 2327, but contains no media type registration form nor any IANA action associated with the registration. (This was also true of RFC 2327.) A 44 page document REALLY needs a table of contents. (I realize the RFC Editor is supposed to deal with this, but RFC 2327 is 42 pages and didn't have a TOC either.) That's it! |
2005-08-17
|
26 | Jon Peterson | [Ballot comment] Comments transferred from old style text ballot: Thanks for your comments Ted - some notes below. - J > -----Original Message----- > From: … [Ballot comment] Comments transferred from old style text ballot: Thanks for your comments Ted - some notes below. - J > -----Original Message----- > From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] > Sent: Tuesday, June 24, 2003 4:01 PM > To: iesg-secretary@ietf.org; iesg@ietf.org > Subject: Evaluation: draft-ietf-mmusic-sdp-new-13 > > > Ted Hardie [ ] [ ] [ X ] [ ] > > DISCUSS: > In Section 5, for the description of u= > > I'd suggest eliminating "as used by WWW clients." and adding a citation > to draft-fielding-uri-rfc2396bis (or at least rfc2396). Note that this > definition seems to presume that all URIs used will be dereferencable, > which is not true for all URIs. If this is a limitation, then it should > be stated. > OK. > The k= also seems to presume that the URI is dereferencable. > If this is a limitation of the URI, it should be made explicit which schemes > are appropriate here. Frankly, it seems to mean http:; if that is the > case, specifying it seems like a good idea. Even for dereferencable > URI schemes, not all will use MIME to mark the reply (think of an > ftp: URI, for example). When they do, the mime content-encoding > specifies the encoding of the _message_, so reusing the word > "encoding" here seems problematic. How would "For those URI > schemes which use MIME, the content-encoding and content-type > headers of the reply may provide guidance on the format of the key." > work? > Yes, I think it would be good to be explicit that this SHOULD be http: or even preferably https: - I guess I can imagine LDAP or something as well, but it would be good to encourage something. I think your wording above on MIME headers is good as well. > On that same hobby horse, the ABNF in the appendix has: > ; sub-rules of 'u=' > uri = URI-reference; see RFC1630 and RFC2732 > > I think this should be a pointer to 2396 or the 2396bis draft. > Agreed. > For the a= inactive designation, we've discussed what addresses to use > for sessions which are being set up but for which addresses are not yet known. > It was suggested apps use something like "sdp.inactive" so that the .inactive > TLD could reinforce the a=inactive flag. In that instance, would the presence > of that TLD be a condition under which the RTCP SHOULD is appropriately > not done, and no RTCP sent? If so, is mentioning that case appropriate here? > Um... that's a trickier case. Agreed, of course, that sending RTCP in this case is pointless. I don't think we've as yet identified any particular magic word (like 'address.invalid') that we'd be into the SDP to signify that this SDP is an IOU. I guess it's the case, though, that if the domainname in the c= line cannot be reached, you can't send RTCP to it - so I'm not sure that there's a danger that RTCP will be sent needlessly that could be prevented here with some additional language. > In the IANA considerations, it looks the draft should specify that the > IANA must update the MIME media type registration to point to this > doc instead of RFC 2327. > True enough. > Notes: > > Having Section 5 contain so much without sub-headers made it hard to > give pointers to sections in the comments; that may be true for others > using the spec as well. > Fair. > In section 5, in the section describing the first subfield of c= > Just as a query, has anyone considered using a specific marker of > private address realms for SDP? That is, using a network type other > than IN to indicate that the domain name or address given are > not globally unique/globally reachable? > Well, whether or not a private address is reachable wrt a particular recipient of SDP is of course a matter of placement and context. The question is what the recipient would do with if it had a different marker for 1918 addrs. If the marker were able to tell the recipient whether or not it could reach the address in question, then it would be useful, sure. But barring that I'm not sure how useful this would be. > In the Security considerations, "Many different protocols may be used > to distribute session description," looks like session description should > be plural. > I'll pass these along. |
2005-08-17
|
26 | Bill Fenner | [Ballot discuss] Discuss transferred from old style text ballot: In the ABNF, the definition of "m1" ends with an extra ). The text says that … [Ballot discuss] Discuss transferred from old style text ballot: In the ABNF, the definition of "m1" ends with an extra ). The text says that type characters are case-sensitive. Unfortunately, this means that ASCII values have to be used in the ABNF instead of strings, since ABNF strings are case-insensitive. e.g. proto-version = "v=" 1*DIGIT CRLF really has to be something like proto-version = %x76 "=" 1*DIGIT CRLF or proto-version = %x76.3d 1*DIGIT CRLF since both "v=0" and "V=0" match the one with "v=". I realize that this latter error is copied from RFC 2327. If this is the only objection I'm not going to stand on it too strongly. |
2005-08-17
|
26 | Ted Hardie | [Ballot discuss] Discuss Transferred from old style text ballot: In Section 5, for the description of u= I'd suggest eliminating … [Ballot discuss] Discuss Transferred from old style text ballot: In Section 5, for the description of u= I'd suggest eliminating "as used by WWW clients." and adding a citation to draft-fielding-uri-rfc2396bis (or at least rfc2396). Note that this definition seems to presume that all URIs used will be dereferencable, which is not true for all URIs. If this is a limitation, then it should be stated. The k= also seems to presume that the URI is dereferencable. If this is a limitation of the URI, it should be made explicit which schemes are appropriate here. Frankly, it seems to mean http:; if that is the case, specifying it seems like a good idea. Even for dereferencable URI schemes, not all will use MIME to mark the reply (think of an ftp: URI, for example). When they do, the mime content-encoding specifies the encoding of the _message_, so reusing the word "encoding" here seems problematic. How would "For those URI schemes which use MIME, the content-encoding and content-type headers of the reply may provide guidance on the format of the key." work? On that same hobby horse, the ABNF in the appendix has: ; sub-rules of 'u=' uri = URI-reference; see RFC1630 and RFC2732 I think this should be a pointer to 2396 or the 2396bis draft. For the a= inactive designation, we've discussed what addresses to use for sessions which are being set up but for which addresses are not yet known. It was suggested apps use something like "sdp.inactive" so that the .inactive TLD could reinforce the a=inactive flag. In that instance, would the presence of that TLD be a condition under which the RTCP SHOULD is appropriately not done, and no RTCP sent? If so, is mentioning that case appropriate here? In the IANA considerations, it looks the draft should specify that the IANA must update the MIME media type registration to point to this doc instead of RFC 2327. Notes: Having Section 5 contain so much without sub-headers made it hard to give pointers to sections in the comments; that may be true for others using the spec as well. In section 5, in the section describing the first subfield of c= Just as a query, has anyone considered using a specific marker of private address realms for SDP? That is, using a network type other than IN to indicate that the domain name or address given are not globally unique/globally reachable? In the Security considerations, "Many different protocols may be used to distribute session description," looks like session description should be plural. |
2005-08-17
|
26 | Russ Housley | [Ballot discuss] Discuss transferred from old style text ballot: Section 4.3 talks about private sessions. It says: … [Ballot discuss] Discuss transferred from old style text ballot: Section 4.3 talks about private sessions. It says: "The details of how encryption is performed are dependent on the mechanism used to convey SDP - e.g. mechanisms are defined for SDP transported using SAP [RFC2974] and SIP [RFC3261]." Why aren't S/MIME for email and TLS for WWW included here? In section 5, the discussion of encryption keys says: "k=clear: The encryption key is included untransformed in this key field. This method MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure channel. k=base64: The encryption key is included in this key field but has been base64 encoded because it includes characters that are prohibited in SDP. This method MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure channel." These restrictions are necessary but not sufficient. You must also ensure that the secure channel is with the party that is authorized to join the session, not an intermediary. If a caching server is used, there ought to be a way to keep the server from accessing the key. Also, it is generally a good idea to indicate the algorithm that a cryptographic key is intended to support. I suggest that the encryption key type be revised to specify the key as well as the algorithm that the key will be used with. Finally, many security protocols require two keys, one for confidentiality and another for integrity. This specification does not support the transfer of two keys. In section 6, the document says: "Use of the "k=" field poses a significant security risk, since it conveys session encryption keys in the clear. SDP MUST NOT be used to convey key material, unless it can be guaranteed that the channel over which the SDP is delivered is both private and authenticated." I agree. It would therefore be desirable for the "k=" field to support two other alternatives. First, it would be nice to name the key without actually including the key. In PEM (see RFC 1040), the Recipient-ID was used to name key-encryption keys, and a similar scheme could be employed here. Second, it would be nice to encrypt the session key in a key that is not included in SDP. PEM also includes a mechanism for wrapped symmetric keys. |
2005-08-17
|
26 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Amy Vezza |
2005-08-17
|
26 | Amy Vezza | [Ballot Position Update] New position, Yes, has been recorded for Jon Peterson by Amy Vezza |
2005-08-17
|
26 | Amy Vezza | [Ballot Position Update] New position, Yes, has been recorded for Allison Mankin by Amy Vezza |
2005-08-17
|
26 | Amy Vezza | [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Amy Vezza |
2005-08-17
|
26 | Amy Vezza | [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Amy Vezza |
2005-08-17
|
26 | (System) | Ballot has been issued |
2005-08-17
|
26 | Amy Vezza | [Ballot Position Update] New position, Discuss, has been recorded for Bill Fenner by Amy Vezza |
2005-08-17
|
26 | Amy Vezza | Created "Approve" ballot |
2005-08-17
|
26 | (System) | Ballot writeup text was added |
2005-08-17
|
26 | (System) | Last call text was added |
2005-08-17
|
26 | (System) | Ballot approval text was added |
2005-07-19
|
25 | (System) | New version available: draft-ietf-mmusic-sdp-new-25.txt |
2005-02-18
|
24 | (System) | New version available: draft-ietf-mmusic-sdp-new-24.txt |
2004-12-13
|
23 | (System) | New version available: draft-ietf-mmusic-sdp-new-23.txt |
2004-11-29
|
22 | (System) | New version available: draft-ietf-mmusic-sdp-new-22.txt |
2004-10-27
|
21 | (System) | New version available: draft-ietf-mmusic-sdp-new-21.txt |
2004-10-26
|
26 | Jon Peterson | State Changes to IESG Evaluation::Point Raised - writeup needed from IESG Evaluation::AD Followup by Jon Peterson |
2004-10-26
|
26 | Jon Peterson | Still waiting on sdescriptions and key-mgmt as better approaches to the k= line issue. |
2004-09-20
|
20 | (System) | New version available: draft-ietf-mmusic-sdp-new-20.txt |
2004-08-18
|
19 | (System) | New version available: draft-ietf-mmusic-sdp-new-19.txt |
2004-06-11
|
18 | (System) | New version available: draft-ietf-mmusic-sdp-new-18.txt |
2004-06-02
|
26 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-06-02
|
17 | (System) | New version available: draft-ietf-mmusic-sdp-new-17.txt |
2004-05-05
|
16 | (System) | New version available: draft-ietf-mmusic-sdp-new-16.txt |
2003-10-28
|
15 | (System) | New version available: draft-ietf-mmusic-sdp-new-15.txt |
2003-09-04
|
14 | (System) | New version available: draft-ietf-mmusic-sdp-new-14.txt |
2003-06-27
|
26 | Dinara Suleymanova | State Changes to IESG Evaluation :: Revised ID Needed from IESG Evaluation by Suleymanova, Dinara |
2003-06-24
|
26 | Michael Lee | State Changes to IESG Evaluation from In Last Call by Lee, Michael |
2003-06-05
|
26 | Amy Vezza | Status date has been changed to 2003-06-18 from |
2003-06-05
|
26 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Vezza, Amy |
2003-06-04
|
26 | Jon Peterson | It's been long enough - this document needs a new last call. |
2003-06-04
|
26 | Jon Peterson | State Changes to Last Call Requested from AD Evaluation :: Revised ID Needed by Peterson, Jon |
2003-06-04
|
26 | (System) | Last call sent |
2003-05-23
|
13 | (System) | New version available: draft-ietf-mmusic-sdp-new-13.txt |
2003-05-20
|
26 | Allison Mankin | IANA considerations notes and other comments (not major) given to Chairs before San Francisco - they were to discuss with WG. [Note from Allison]. |
2003-04-07
|
26 | Jon Peterson | Shepherding AD has been changed to Peterson, Jon from Mankin, Allison |
2003-03-07
|
12 | (System) | New version available: draft-ietf-mmusic-sdp-new-12.txt |
2003-02-03
|
26 | Allison Mankin | I need to give details for fix of IANA considerations asap - it was Last Called [Note from Allison 2003-Feb-03] |
2002-11-06
|
11 | (System) | New version available: draft-ietf-mmusic-sdp-new-11.txt |
2002-10-22
|
26 | Allison Mankin | State Changes to AD Evaluation -- New ID Needed from Wait for Writeup by mankin |
2002-07-23
|
26 | Stephen Coya | State Changes to Wait for Writeup from Last Call … State Changes to Wait for Writeup from Last Call Issued by scoya |
2002-06-28
|
26 | Jacqueline Hargest | Due date has been changed to 07/12/2002 from by jhargest |
2002-06-28
|
26 | Jacqueline Hargest | State Changes to Last Call Issued from Last Call … State Changes to Last Call Issued from Last Call Requested by jhargest |
2002-06-28
|
26 | Allison Mankin | for proposed standard recycle |
2002-06-28
|
26 | Allison Mankin | Draft Added by mankin |
2002-05-28
|
10 | (System) | New version available: draft-ietf-mmusic-sdp-new-10.txt |
2002-05-17
|
09 | (System) | New version available: draft-ietf-mmusic-sdp-new-09.txt |
2002-04-22
|
08 | (System) | New version available: draft-ietf-mmusic-sdp-new-08.txt |
2002-03-27
|
07 | (System) | New version available: draft-ietf-mmusic-sdp-new-07.txt |
2002-03-04
|
06 | (System) | New version available: draft-ietf-mmusic-sdp-new-06.txt |
2002-02-11
|
05 | (System) | New version available: draft-ietf-mmusic-sdp-new-05.txt |
2001-11-29
|
04 | (System) | New version available: draft-ietf-mmusic-sdp-new-04.txt |
2001-07-18
|
03 | (System) | New version available: draft-ietf-mmusic-sdp-new-03.txt |
2001-05-01
|
02 | (System) | New version available: draft-ietf-mmusic-sdp-new-02.txt |
2001-03-07
|
01 | (System) | New version available: draft-ietf-mmusic-sdp-new-01.txt |
2000-11-21
|
00 | (System) | New version available: draft-ietf-mmusic-sdp-new-00.txt |