From wwwrun@rfc-editor.org Wed Mar 7 11:41:25 2012 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB3911E807F for ; Wed, 7 Mar 2012 11:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj7gAEq-0h0J for ; Wed, 7 Mar 2012 11:41:25 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D3F2711E8072 for ; Wed, 7 Mar 2012 11:41:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8FF2A62179; Wed, 7 Mar 2012 11:41:12 -0800 (PST) To: smcg.stds01@mcglashan.org, timm@rainwillow.com, chris@ns-technologies.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, dworley@avaya.com, eburger@standardstrack.com From: RFC Errata System Message-Id: <20120307194112.8FF2A62179@rfc-editor.org> Date: Wed, 7 Mar 2012 11:41:12 -0800 (PST) Cc: rfc-editor@rfc-editor.org, mediactrl@ietf.org Subject: [MEDIACTRL] [Editorial Errata Reported] RFC6231 (3151) X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 19:41:26 -0000 The following errata report has been submitted for RFC6231, "An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6231&eid=3151 -------------------------------------- Type: Editorial Reported by: Eric Burger Section: 4.5 Original Text ------------- | 433 | Unsupported | request contains | | | | collect and | and | | | | record | elements and | | | | capability | the MS does support | | | | | these operations | | | | | simultaneously. | | Corrected Text -------------- | 433 | Unsupported | request contains | | | | collect and | and | | | | record | elements and | | | | capability | the MS does not | | | | | support these | | | | | operations | | | | | simultaneously. | | Notes ----- Typo discovered in 6231-iana draft. Need anti-sense of description. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6231 (draft-ietf-mediactrl-ivr-control-package-11) -------------------------------------- Title : An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework Publication Date : May 2011 Author(s) : S. McGlashan, T. Melanchuk, C. Boulton Category : PROPOSED STANDARD Source : Media Server Control Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From eburger@standardstrack.com Wed Mar 7 11:55:14 2012 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CE121F85D5 for ; Wed, 7 Mar 2012 11:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O-rccDNQ-1P for ; Wed, 7 Mar 2012 11:55:13 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 88B7621F85D4 for ; Wed, 7 Mar 2012 11:55:13 -0800 (PST) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:59265 helo=[192.168.15.135]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1S5Mwu-0005LU-UY; Wed, 07 Mar 2012 11:55:01 -0800 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-231-655587549; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <20120307194112.8FF2A62179@rfc-editor.org> Date: Wed, 7 Mar 2012 14:55:05 -0500 Message-Id: References: <20120307194112.8FF2A62179@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: timm@rainwillow.com, chris@ns-technologies.com, mediactrl@ietf.org Subject: Re: [MEDIACTRL] [Editorial Errata Reported] RFC6231 (3151) X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 19:55:14 -0000 --Apple-Mail-231-655587549 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This catches a nit that Alexey found in reviewing 6231-iana. On Mar 7, 2012, at 2:41 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC6231, > "An Interactive Voice Response (IVR) Control Package for the Media = Control Channel Framework". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6231&eid=3D3151 >=20 > -------------------------------------- > Type: Editorial > Reported by: Eric Burger >=20 > Section: 4.5 >=20 > Original Text > ------------- > | 433 | Unsupported | request contains | = | >=20 > | | collect and | and | = | >=20 > | | record | elements and | = | >=20 > | | capability | the MS does support | = | >=20 > | | | these operations | = | >=20 > | | | simultaneously. | = | >=20 >=20 >=20 > Corrected Text > -------------- > | 433 | Unsupported | request contains | = | >=20 > | | collect and | and | = | >=20 > | | record | elements and | = | >=20 > | | capability | the MS does not | = | >=20 > | | | support these | = | >=20 > | | | operations | = | >=20 > | | | simultaneously. | = | >=20 >=20 >=20 > Notes > ----- > Typo discovered in 6231-iana draft. Need anti-sense of description. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6231 (draft-ietf-mediactrl-ivr-control-package-11) > -------------------------------------- > Title : An Interactive Voice Response (IVR) Control = Package for the Media Control Channel Framework > Publication Date : May 2011 > Author(s) : S. McGlashan, T. Melanchuk, C. Boulton > Category : PROPOSED STANDARD > Source : Media Server Control > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG --Apple-Mail-231-655587549 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwMzA3MTk1NTA2WjAjBgkqhkiG9w0BCQQxFgQU uh//3Z+cDAPe+JkVPdjOsQSORXowgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEAjoFls3VGa1QDwlCo+6CCWJ4ZwGorVyUSBZXTLcnyhahF3Lbak++Y L3lokZxW6CdGzCOAcY4rRgvds6olwYP/1POqnc6xv/g3A7dYJkoTzTg8m20aeJzLwuWMJ/nhMHsd WK0mW1+Ip2KHL76axkoCPzM30lTzyZfS+l/nj3kuUcr1gRFfeF96AsI4WPvf3G04xYabdbytEfWq N4wgqLn5uRxc/pIwBZK9jtC9zv7lpNP7l0AVupk/GrXRk4en3YcmoDUYny2SaI+HHuNxol8Aobem RRn4xxsmbCO+gzM0IobuSPmYq/CF/HzgUCxlzvc8joYhoYCUkC/4EQs9h/v/IwAAAAAAAA== --Apple-Mail-231-655587549-- From timm@rainwillow.com Wed Mar 7 11:52:36 2012 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFE211E8098 for ; Wed, 7 Mar 2012 11:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-mFq6l4zf1S for ; Wed, 7 Mar 2012 11:52:34 -0800 (PST) Received: from pineapple.asmallorange.com (pineapple.asmallorange.com [184.173.73.184]) by ietfa.amsl.com (Postfix) with ESMTP id EF66F11E8097 for ; Wed, 7 Mar 2012 11:52:33 -0800 (PST) Received: from d64-180-43-124.bchsia.telus.net ([64.180.43.124] helo=[192.168.1.66]) by pineapple.asmallorange.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1S5MuK-001Nwn-BP; Wed, 07 Mar 2012 14:52:20 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Melanchuk In-Reply-To: <20120307194112.8FF2A62179@rfc-editor.org> Date: Wed, 7 Mar 2012 11:52:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <66D0010D-BE97-491C-8519-D0A140020F35@rainwillow.com> References: <20120307194112.8FF2A62179@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - pineapple.asmallorange.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - rainwillow.com X-Mailman-Approved-At: Thu, 08 Mar 2012 10:49:46 -0800 Cc: chris@ns-technologies.com, mediactrl@ietf.org Subject: Re: [MEDIACTRL] [Editorial Errata Reported] RFC6231 (3151) X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 19:52:36 -0000 the errata is correct and its status should be set to verified. On 2012-03-07, at 11:41 AM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC6231, > "An Interactive Voice Response (IVR) Control Package for the Media = Control Channel Framework". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6231&eid=3D3151 >=20 > -------------------------------------- > Type: Editorial > Reported by: Eric Burger >=20 > Section: 4.5 >=20 > Original Text > ------------- > | 433 | Unsupported | request contains | = | >=20 > | | collect and | and | = | >=20 > | | record | elements and | = | >=20 > | | capability | the MS does support | = | >=20 > | | | these operations | = | >=20 > | | | simultaneously. | = | >=20 >=20 >=20 > Corrected Text > -------------- > | 433 | Unsupported | request contains | = | >=20 > | | collect and | and | = | >=20 > | | record | elements and | = | >=20 > | | capability | the MS does not | = | >=20 > | | | support these | = | >=20 > | | | operations | = | >=20 > | | | simultaneously. | = | >=20 >=20 >=20 > Notes > ----- > Typo discovered in 6231-iana draft. Need anti-sense of description. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6231 (draft-ietf-mediactrl-ivr-control-package-11) > -------------------------------------- > Title : An Interactive Voice Response (IVR) Control = Package for the Media Control Channel Framework > Publication Date : May 2011 > Author(s) : S. McGlashan, T. Melanchuk, C. Boulton > Category : PROPOSED STANDARD > Source : Media Server Control > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG From rjsparks@nostrum.com Thu Mar 8 14:19:23 2012 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A023121E8062 for ; Thu, 8 Mar 2012 14:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.252 X-Spam-Level: X-Spam-Status: No, score=-102.252 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTuvpv2-V5jS for ; Thu, 8 Mar 2012 14:19:22 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AD58921E8065 for ; Thu, 8 Mar 2012 14:19:13 -0800 (PST) Received: from unexplicable.local (pool-71-170-125-181.dllstx.fios.verizon.net [71.170.125.181]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q28MJCEP041890 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 16:19:12 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F593060.5020002@nostrum.com> Date: Thu, 08 Mar 2012 16:19:12 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "mediactrl@ietf.org" , draft-ietf-mediactrl-mrb@tools.ietf.org, mediactrl-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 71.170.125.181 is authenticated by a trusted mechanism) Subject: [MEDIACTRL] AD review: draft-ietf-mediactrl-mrb-12 X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 22:19:23 -0000 Summary: There are several concerns to address with a revised ID before progressing this to IETF LC. This was a very difficult document to read, and the existing flow made some spec bugs hard to find. I encourage the working group to consider another editorial pass focusing on informing the implementer while working on the technical questions below. First a question: Why is the use of different in 5.2.3 (the consumer interface) than it is in the publish interface? It has the server pick the initial value of a sequence space that the client has to use for subsequent requests. Why is that important? Technical/Process issues: The document currently normatively references RFC5705 ("Keying Material Exporters for Transport Layer Security (TLS)"). It's obvious from the place where this reference is made that it meant to reference RFC5707 ("Media Server Language (MSML)"). This is a _really_ big bug to have gotten through the various reviews that should have caught it so far. The working group should discuss the intended reference. If the document is changed to reference RFC5707 (at least as 5705 is currently referenced), it will be a downref (5707 was published on the independent stream). The registration in 13.1 does not match the template required by RFC6230 - please correct it. The media-type review pointed out that the registrations in this document are using an outdated template. Please update them to use the templates in RFC4288. Sections 13.6 and 13.7 use an incorrect URI for registering the schema - it should be urn:ietf:params:xml:schema:mrb-publish and urn:ietf:params:xml:schema:mrb-consumer, not :ns:. (:ns: is right as the identifier for the namespace, but not the schema) There are several places (5.1.4.16 is the first) where the document is using xml:lang to try to specify what language is supported for automatic speech recognition or text to speech. That's not an appropriate use for that descriptor - xml:lang describes what language the xml entity it appears in should be interpreted with - see . You probably want something like en instead. The phrase "compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the <...> applies" occurs throughout the document. It is not precise. Which related IANA registry? I think you are trying to say "as it appears in 'Control Packages' subregistry of the 'IANA Media Control Channel Framework Parameters' registry. Since this occurs so often, it might be worth figuring out a way to present this using a reference. Section 5.1.3.1 - Please clarify the scope of uniqueness of id. Is it the intent that these only be unique within the scope of a given MS, MRB pair? Or is there a need for it to be unique across all the subscriptions concurrent in a given deployment? Section 5.1.3.1's description of confuses what the MRB is asking for vs what the MS gave it. This may be a structural problem - this section is about requests, and its description of is written from a request point of view, but is reused by responses in 5.1.5. This section should be clear that this is just the duration the MRB is asking for, and that the MS may provide a different value, and if it does, that's what to use to determine when to "subscribe again". It's also only implicit right now that if a success response doesn't say anything about the duration of the subscription, the duration is what was requested (or at least that's how I'm reading the document). Please make that clearer. (Editorial question: Why is the discussion of this request and response separated by the (really long) discussion of the notification?) Section 5.1.4.1 - The scope for uniqueness for is still vague - what does "system wide" mean? Are you trying to say "chosen such that it is extremely unlikely that two different media servers would present the same id to a given MRB"? Can the document provide guidance on constricting this id? Section 5.1.4.5 and .6 - What is an "inactive RTP session"? (Can you provide a definition or a reference to a definition?). Section 5.1.4.13's speaks of a "specific available algorithm". What defines the values that can appear here? Section 5.1.4.13's says the element can contain a non-XCON layout name as long as it is "properly prefixed". Please be more precise with what "properly prefixed" means. In section 5.1.4.14, what does it mean to "support" these kinds of tone? Can you provide pointers to help explain how this will be used? In section 5.1.4.15, what defines the values that can occur in ? Are these restricted to standardized protocols? Are the names case sensitive? Is (for example) HTTPS meaningful here? What is a receiver supposed to do with values it doesn't understand? Should the values appear in a registry? Is there advice the document should give MS or client implementers about the security implications of choosing how to populate this list? In section 5.1.4.17, it's not clear what the values for the support attribute of are allowed to be. Are they the literal strings "RFC5552","RFC4240", and "IVR-Package"? If so, why is IVR-Package different (and not "RFC6231"). Are these values case-sensitive? Should the possible values be in a registry? Are the values "RFC4733" and "Media" occuring in the various places dtmf-support is discussed case-sensitive? The protocol allows describing the civic location of a media server, and qualifying a request with the civic location of a media server. These should say something about the level of specificity of the provided location (do you just say what region something is in, or do you specify its location down to a room number?) The security considerations section is silent on the ramifications, particularly those of being able to influence where potentially large amounts of traffic are about to be sourced from. It would help to understand the tradeoff of providing this information by providing some discussion of why it needs to appear here. There are several sections that talk about declaring support for SRTP (such as 5.1.4.21), but they don't appear to account for indicating what keying mechanism is used. Section 5.1.5 and 5.2.6.1 declare that implementations must return a 420 error if they receive XML with attributes/elements they don't understand. How is the sender supposed to figure out what attribute/element caused the 420 to happen? Right now, I don't see what's supposed to prevent one MRB from affecting the subscriptions from another MRB. It looks like a malicious MRB A could remove MRB B's subscriptions. A well meaning MRB A could accidentally disrupt MRB B. The short description of relying on authentication from the protocol you are embedding this one in doesn't seem to address that case. The security considerations section should at least discuss the threat. Similarly, what keeps one MRB from removing another MRB's session at an MS? The document uses the term "call leg" in several places, and it's not clear exactly what that means in each context. RFC3261 stopped using that term for a reason. In some of the places this document uses the phrase it means "dialog". In others it means "media session". Please clarify each instance. Would it be possible to remove the term "call leg" from the document altogether? In section 5.2.2.1, what prevents the MRB's INVITE from parallel forking on the way to the MSes? What is it supposed to do if it gets back multiple 200 OKs to that INVITE? Similarly, what is it supposed to do with failures? That question has two aspects. First, what can it do "downstream"? Can it effectively serial-fork if the first MS it tried didn't work out? Should it follow redirect requests?. Then, what is it supposed to do upstream? If, say, there was only one MS in the universe, and it returned a 603 to the INVITE, what SIP response is the MRB supposed to return to the INVITE it received? Section 5.2.2.1's first bullet in the third list of bullets (starting "Include a payload in the SIP 2xx class response" is confused with respect to its actors. It seems to be trying to put a requirement on the MRB about constructing the application/sdp part of the multipart body, but the MRB can only copying something that the MS constructed. The 4th bullet of section 5.2.2.1's third list of bullets inspires the question of whether MRBs in IAMM support offerless invites. Please make it clear in the document what an MRB should do with an INVITE that contains no SDP. Does the last sentence of 5.2.3 conflict with the last sentence of 5.2.2.1? Editorial: Please consider another editorial pass through the document. There are several sections that are much harder to read than they could be. Some careful repositioning when discussions start to wander from the main point of a section would help significantly. Throughout, please change MIME type to media type. Why does the document say "SIP 2xx class response" instead of "SIP 200 OK". What other response are you anticipating? It's not incorrect, but it's odd that you leave this flexibility for SIP and not for HTTP. There are several chunks of text that will not age well. The first paragraph of the Introduction is a prime example. Many of these could simply be deleted. The others should be rewritten to make sense to an implementer 10 years from now. There are many sections that introduce confusion through passive voice and extraneous text. Please consider removing as much passive voice as possible and deleting sentences like the first in section 4. There is also some editorializing that is not needed (such as the first sentence of 5.2.2). Please review each of those and confirm they add something necessary to the document. I found page 14 (sections 5 and 5.1) particularly hard to understand. I think the text there can be made much shorter. The idea that MS selection is performed with the best information available is distributed (and buried) in several sections. Consider moving the point to a standalone discussion, and state it as simply as possible. In section 5.1.4.11, the semantics of max-prepared-duration are not clearly represented. It would help to say "will be kept in the prepared state before timing out" instead of "can be prepared" in the first paragraph. Adding a pointer to 4.4.2.2.6 of RFC6231 would also help. In section 5.1.4.10, consider noting that the element describes media types, and might better have been named "media-format" but the name "file-format" is being used due to existing implementations. Section 5.1.4.19: "not meant to provide any explicit information" is not what you mean. This field is definitely providing explicit information. What are you actually trying to clarify? Section 5.2 claims the Consumer interface is defined by the 'application/mrb-consumer+xml MIME type. This document defines the interface, it uses that media type. Please clarify the language in this section. Section 5.2.2.1 first sentence - this is a strange use of MUST. Why is it there? Should 5.2.3's first sentence say "media resource server" where it currently says "media resource"? At the end of 5.2.1.2, lease hasn't been defined (and was only pointed to prior to this in the document once, long before here). Consider discussing leases earlier, or at least providing another forward reference. The discussion of in section 5.2.6.1.1.1 (do we really need 6 levels of section heading?) seems confused about actors - it recommends consumer clients refresh a leas, but provides an example of a server refreshing a transaction. Section 8, 5th bullet uses "in advance" once more than it needed to. In section 12, the document says a couple of times that security considerations from other documents MUST be used. What does that mean? Please adjust the text to clarify. It would be appropriate to say that security considerations from other documents are applicable. It would be appropriate to point to specific mechanics those security consideration sections call out and say those MUST be used. While adjusting, please avoid the temptation to be vague and say something like "the appropriate mitigation techniques from MUST be used". "Appropriate" in that context is not precise enough. Consider noting that Ben's RAI review was on an early version of this document (it was on -03) (unless, of course, his review gets updated to reflect this version.) From iesg-secretary@ietf.org Mon Mar 19 11:54:14 2012 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE1921F8864; Mon, 19 Mar 2012 11:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ow-q3BxGE5TX; Mon, 19 Mar 2012 11:54:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE7C21F88CF; Mon, 19 Mar 2012 11:54:13 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120319185413.25842.56768.idtracker@ietfa.amsl.com> Date: Mon, 19 Mar 2012 11:54:13 -0700 Cc: mediactrl mailing list , mediactrl chair , RFC Editor Subject: [MEDIACTRL] Protocol Action: 'IANA Registry for MEDIACTRL Interactive Voice Response Control Package' to Proposed Standard (draft-ietf-mediactrl-6231-iana-00.txt) X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 18:54:15 -0000 The IESG has approved the following document: - 'IANA Registry for MEDIACTRL Interactive Voice Response Control Package' (draft-ietf-mediactrl-6231-iana-00.txt) as a Proposed Standard This document is the product of the Media Server Control Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mediactrl-6231-iana/ Technical Summary This document creates an IANA registry for the response codes for the MEDIACTRL Interactive Voice Response Control Package, RFC6231. Working Group Summary This document corrects an oversight in RFC6231, asking IANA to create a registry that RFC6231 clearly intended to create - the format, initial contents and maintenance rules were specified in RFC6231. This document was reviewed by the working group concurrently with IETF LC. Document Quality This document is essentially an IANA considerations section with content from RFC6231. Personnel Eric Burger is the Document Shepherd. Robert Sparks is the responsible Area Director. RFC Editor Note (applies to -00) The following correction adds a missing word "not" to the description of the 433 code: (please view in fixed width font) OLD: ------------- | 433 | Unsupported | request contains | | | | collect and | and | | | | record | elements and | | | | capability | the MS does support | | | | | these operations | | | | | simultaneously. | | NEW: -------------- | 433 | Unsupported | request contains | | | | collect and | and | | | | record | elements and | | | | capability | the MS does not | | | | | support these | | | | | operations | | | | | simultaneously. | | Please make this change to the IANA considerations section: OLD: Please create the following registry. NEW: Please create the following registry, with a name of "MEDIACTRL Interactive Voice Response Control Package Registry" From wwwrun@rfc-editor.org Sat Mar 24 11:27:38 2012 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAE321F8528; Sat, 24 Mar 2012 11:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.157 X-Spam-Level: X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PjPWMQN777x; Sat, 24 Mar 2012 11:27:38 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1E121F8510; Sat, 24 Mar 2012 11:27:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CB998B1E004; Sat, 24 Mar 2012 11:14:08 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120324181408.CB998B1E004@rfc-editor.org> Date: Sat, 24 Mar 2012 11:14:08 -0700 (PDT) Cc: mediactrl@ietf.org, rfc-editor@rfc-editor.org Subject: [MEDIACTRL] RFC 6505 on A Mixer Control Package for the Media Control Channel Framework X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 18:27:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6505 Title: A Mixer Control Package for the Media Control Channel Framework Author: S. McGlashan, T. Melanchuk, C. Boulton Status: Standards Track Stream: IETF Date: March 2012 Mailbox: smcg.stds01@mcglashan.org, timm@rainwillow.com, chris@ns-technologies.com Pages: 89 Characters: 187038 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mediactrl-mixer-control-package-14.txt URL: http://www.rfc-editor.org/rfc/rfc6505.txt This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections. The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications. The package also defines elements for auditing package capabilities and mixers [STANDARDS-TRACK] This document is a product of the Media Server Control Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC