From iptel-bounces@ietf.org Wed Nov 02 08:45:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXIvN-0002vi-Ad; Wed, 02 Nov 2005 08:45:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXIvL-0002vG-Gn for iptel@megatron.ietf.org; Wed, 02 Nov 2005 08:45:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06758 for ; Wed, 2 Nov 2005 08:44:45 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXJ9v-0001rB-S2 for iptel@ietf.org; Wed, 02 Nov 2005 09:00:13 -0500 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 02 Nov 2005 14:44:53 +0100 id 00068164.4368C2D5.00005E38 Message-ID: <4368C2C9.2040101@enum.at> Date: Wed, 02 Nov 2005 14:44:41 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: iptel@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [Iptel] review of draft-ietf-iptel-trunk-group-04.txt X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Hi, from my perspective, the document is in a very good shape - however, i've found two small nits: - "VoIP" is never expanded in the draft, and does not appear on the list of well known abbreviations of http://www.rfc-editor.org/policy.html. - Figure 1 on page 9 breaks to page 10 because of a single line. This should be corrected for readability, probably by removing the "empty" line in the figure above "Send to PSTN" (or a similar "trick"). What i'm not sure about is the naming of the example sections. Personally, i prefer to know from the section title what the example is all about, so i suggest changing the "Example 1" title into "Basic call flow" and "Example 2" into "Cross domain call flow". Opinions about this? cheers alex _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Nov 02 14:13:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXO2i-0006W7-CU; Wed, 02 Nov 2005 14:13:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXO2g-0006Rd-64 for iptel@megatron.ietf.org; Wed, 02 Nov 2005 14:13:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02284 for ; Wed, 2 Nov 2005 14:12:40 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXOHJ-0002IQ-2g for iptel@ietf.org; Wed, 02 Nov 2005 14:28:10 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA2JChu7000226; Wed, 2 Nov 2005 13:12:43 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id jA2JCgQ13883; Wed, 2 Nov 2005 13:12:43 -0600 (CST) Message-ID: <43690FAB.7070307@lucent.com> Date: Wed, 02 Nov 2005 13:12:43 -0600 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Mayrhofer Subject: Re: [Iptel] review of draft-ietf-iptel-trunk-group-04.txt References: <4368C2C9.2040101@enum.at> In-Reply-To: <4368C2C9.2040101@enum.at> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1024726057==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1024726057== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060300000003000006020400" This is a cryptographically signed message in MIME format. --------------ms060300000003000006020400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Alexander Mayrhofer wrote: > Hi, > > from my perspective, the document is in a very good shape - however, > i've found two small nits: Alex: Thank you for your time in turning this around so quickly. I will incorporate the two nits and re-name the Examples sections as you suggest. > - "VoIP" is never expanded in the draft, and does not appear on the list > of well known abbreviations of http://www.rfc-editor.org/policy.html. > > - Figure 1 on page 9 breaks to page 10 because of a single line. This > should be corrected for readability, probably by removing the "empty" > line in the figure above "Send to PSTN" (or a similar "trick"). > > What i'm not sure about is the naming of the example sections. > Personally, i prefer to know from the section title what the example is > all about, so i suggest changing the "Example 1" title into "Basic call > flow" and "Example 2" into "Cross domain call flow". Opinions about this? Best regards, - vijay -- Vijay K. Gurbani, Ph.D. vkg@{lucent.com,research.bell-labs.com,acm.org} Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 --------------ms060300000003000006020400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTExMDIxOTEyNDNaMCMGCSqGSIb3DQEJ BDEWBBQ0M2NNEsUqkOX+bqzQedoXjW7NCjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAteMjcsCXVvHXzi5NH+ToqmDhDvL4h6s8vqXPZfpvWOOX73ikTU78 X578DKssn9FKdJXZi7H5/eul/7e+/B4uyKRjMnxUSpoWOly3kBdgMNI0DOca8a4W/nJsiwZr FI5iFf1vodWzDHlBVBRV8oGwwPUXIA9x+p29pwnO/P9f6DYAAAAAAAA= --------------ms060300000003000006020400-- --===============1024726057== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============1024726057==-- From iptel-bounces@ietf.org Thu Nov 03 05:57:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXcmE-0002jb-0B; Thu, 03 Nov 2005 05:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXcmB-0002j6-22 for iptel@megatron.ietf.org; Thu, 03 Nov 2005 05:56:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23491 for ; Thu, 3 Nov 2005 05:56:37 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXd0w-0003ne-1c for iptel@ietf.org; Thu, 03 Nov 2005 06:12:15 -0500 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 03 Nov 2005 11:56:25 +0100 id 00068359.4369ECDD.0000106E Message-ID: <4369ECD1.2040906@enum.at> Date: Thu, 03 Nov 2005 11:56:17 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: iptel@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Subject: [Iptel] trunk-group draft: parameter name contemplation... X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org After reading through RFC3261 and RFC3966 again, i'd appreciate your comments of the following issue: According to the ABNF of draft-ietf-iptel-trunk-group-04, trunk group related parameters to the "tel" URI are to be specified in the exact order tel:;trgrp=BLA;trunk-context=example.com so that the "trunk-context" parameter immediately follows the "trgrp" parameter. According to RFC3261, Section 19.1.6, telephone-subscriber parameters should be ordered lexically by parameter name when they are incorporated in a SIP URI user part. This would not change anything in the plain example above ("trunk-context" > "trgrp"). However, if a future parameter with a name "between" those two parameters is introduced (see example below): tel:;troll=yes;trgrp=BLA;trunk-context=example.com It would be mapped to a SIP URI of: sip:;trgrp=BLA;troll=yes;trunk-context=example.com@example.net effectively splitting the trunk parameters because the new parameter "troll" is lexically in between. Broken implementations might then not recognize the trunk parameters because they expect "trunk-group" immediately following "trgrp" even in SIP URIs. Does the group consider this a problem? If it does, the issue could probably be mitigated by either: - renaming one of the parameters ("trgrp-context"?) [that does not _solve_ it, as there are always strings "between"] - instructing IANA to not register any tel URI parameter "between" - relaxing the order of the parameters - clarifying that clients which parse SIP user parts as tel URI must must not rely on the parameter order. Anything else? comments appreciated. Alex Mayrhofer enum.at _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Nov 03 07:59:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXegf-0008Os-Hz; Thu, 03 Nov 2005 07:59:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXege-0008On-1Z for iptel@megatron.ietf.org; Thu, 03 Nov 2005 07:59:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29136 for ; Thu, 3 Nov 2005 07:59:01 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXevQ-000167-MY for iptel@ietf.org; Thu, 03 Nov 2005 08:14:41 -0500 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 03 Nov 2005 13:59:10 +0100 id 0006836F.436A09A2.0000169C Message-ID: <436A0994.402@enum.at> Date: Thu, 03 Nov 2005 13:59:00 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Richard Shockey Subject: Re: [Iptel] One more trivial NIT on iptel-tel-enumdi-02 References: <4363DEB3.3080304@shockey.us> In-Reply-To: <4363DEB3.3080304@shockey.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "iptel@ietf.org" , Stastny Richard , Lawrence Conroy X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org All, > Cullen Jennings wrote: >> The BNF does not add the enumdi to the par rule in the tel RFC. And >> the IANA >> registry question would also impact this. >> >> I'm also wondering if I am nuts thinking that the we need to say that >> this >> draft updates the par line. It makes sense to me but if others think >> this is >> not needed - let me know I am nuts. I second that we need to say this. The last sentence of the section (which, btw, should mention "enumdi" instead of "enum-dip-indicator"?) should at least specify where in the tel URI can appear. I like the style from draft-ietf-iptel-trunk-group, btw. I also think that "No considerations for IANA" should be clarified. Without the background of the tel URI registry draft this is a imho bit misleading (and, could be interpreted as an suggestion that tel URI parameters do not need to be registered/coordinated at all [otoh, 3966 section 5.4 clarifies this already]). >> Can we also get someone to do a NITS review of this draft. It the >> review was >> already done in the ENUM group then I am happy to skip it. My comments are as follows: - As Cullen already pointed out, there's a IPR Boilerplate issue. I've not investigated this in detail. - Secion 1 has a small typo in it: "thisdocument" - Abbreviations: There are a lot of abbreviations which are never spelled out. I've spotted "VoIP", "UAS", "UAC", "ENUM", "PSTN", "URI" (spelled out in abstract only - is this ok?), "NAPTR", "RR" not to be on the list of well known abbreviations. - Abstract: The second sentenct of the abstract is a bit too long for my poor Engrish ;), would appreciate comments from native speakers here. In addition, it only talks about "receiving" an enumdi URI which could lead to the impression that the document is only about handling, but not creating the parameter in URIs. Furthermore, the ID-Checklist mandates to not use any citations in abstracts - Please remove references to RFCs from it. Please expand any abbreviations - this could lead to cluttering of the first sentence, maybe "SIP Proxies, H.323 gatekeepers and other VoIP elements" should be simply replaced by "network elements". - Readability: Generally, there are a few rather long nested sentences. It makes the document hard to read in some points. - URI examples: "<" and ">" are not part of the URI itself - they are a way of embedding URIs in other protocols. Please remove them from the examples. - IANA considerations: see comment above. - ABNF is used in the document: Please change its reference to normative. cheers Alex Mayrhofer enum.at _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Sun Nov 06 11:27:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYnMW-00063U-Vp; Sun, 06 Nov 2005 11:27:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYnMV-00063O-Sk for iptel@megatron.ietf.org; Sun, 06 Nov 2005 11:27:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04983 for ; Sun, 6 Nov 2005 11:26:55 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYnbv-0006GB-Vu for iptel@ietf.org; Sun, 06 Nov 2005 11:43:17 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 06 Nov 2005 08:27:10 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jA6GR362006968; Sun, 6 Nov 2005 08:27:03 -0800 (PST) Received: from 10.21.81.125 ([10.21.81.125]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 6 Nov 2005 16:27:09 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sat, 05 Nov 2005 08:16:04 -0800 Subject: Re: [Iptel] review of draft-ietf-iptel-trunk-group-04.txt From: Cullen Jennings To: "iptel@ietf.org" , "Vijay K. Gurbani" Message-ID: Thread-Topic: [Iptel] review of draft-ietf-iptel-trunk-group-04.txt Thread-Index: AcXiJDg6dwFcsU4XEdq7RgARJEEJ/A== In-Reply-To: <4368C2C9.2040101@enum.at> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org I think we need to change the IANA section to just say it has no IANA registration since 3966 never created a registry. I'd like to delete the comment in the abstract about the mailing list to use. Need to check that none of the "trunk-group" got broken across a line break. Abstract ahs weird "group- related". Need to remove the -. Last para before section 4 - change "this Internet draft" to "this specification" Again in section 4.4 change "draft MAY" to "specification MAY" Last para before section 6 need to change "this draft" to "this specification" Update tgrep ref to version 06 On 11/2/05 5:44 AM, "Alexander Mayrhofer" wrote: > Hi, > > from my perspective, the document is in a very good shape - however, i've > found two small nits: > > - "VoIP" is never expanded in the draft, and does not appear on the list of > well known abbreviations of http://www.rfc-editor.org/policy.html. > > - Figure 1 on page 9 breaks to page 10 because of a single line. This should > be corrected for readability, probably by removing the "empty" line in the > figure above "Send to PSTN" (or a similar "trick"). > > What i'm not sure about is the naming of the example sections. Personally, i > prefer to know from the section title what the example is all about, so i > suggest changing the "Example 1" title into "Basic call flow" and "Example > 2" into "Cross domain call flow". Opinions about this? > > cheers > > alex > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Sun Nov 06 11:27:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYnMY-000640-Ec; Sun, 06 Nov 2005 11:27:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYnMW-00063T-JC for iptel@megatron.ietf.org; Sun, 06 Nov 2005 11:27:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04986 for ; Sun, 6 Nov 2005 11:26:55 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYnbx-0006GB-Gw for iptel@ietf.org; Sun, 06 Nov 2005 11:43:17 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 06 Nov 2005 08:27:12 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jA6GR364006968; Sun, 6 Nov 2005 08:27:05 -0800 (PST) Received: from 10.21.81.125 ([10.21.81.125]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 6 Nov 2005 16:27:10 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sat, 05 Nov 2005 08:29:47 -0800 Subject: Re: [Iptel] trunk-group draft: parameter name contemplation... From: Cullen Jennings To: Alexander Mayrhofer , "iptel@ietf.org" , "Vijay K. Gurbani" Message-ID: Thread-Topic: [Iptel] trunk-group draft: parameter name contemplation... Thread-Index: AcXiJiLGYYBQ+E4ZEdq7RgARJEEJ/A== In-Reply-To: <4369ECD1.2040906@enum.at> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org That is a great catch. I think we should fix the BNF so that it relaxes the order constraint and perhaps add a note pointing out the the troll example. Seems there are two ways to fix the ABNF, one would be par = parameter / extension / isdn-sub / trunk-group / trunk-group-context and then add text that say if there is a trunk-group there MUST be a trunk-group-context. The other way might be to define trunk-group = ";tgrp=" trunk-group-lable [ *(par) ] ";trunk-context=" trunk-context Now par is defined as allowing a trunk-group in it and trunk-group allows a par in it and I no longer know if this is a valid ABNF. I think I prefer the first approach. Cullen On 11/3/05 2:56 AM, "Alexander Mayrhofer" wrote: > > After reading through RFC3261 and RFC3966 again, i'd appreciate your > comments of the following issue: > > According to the ABNF of draft-ietf-iptel-trunk-group-04, trunk group > related parameters to the "tel" URI are to be specified in the exact order > > tel:;trgrp=BLA;trunk-context=example.com > > so that the "trunk-context" parameter immediately follows the "trgrp" > parameter. According to RFC3261, Section 19.1.6, telephone-subscriber > parameters should be ordered lexically by parameter name when they are > incorporated in a SIP URI user part. This would not change anything in the > plain example above ("trunk-context" > "trgrp"). However, if a future > parameter with a name "between" those two parameters is introduced (see > example below): > > tel:;troll=yes;trgrp=BLA;trunk-context=example.com > > It would be mapped to a SIP URI of: > > sip:;trgrp=BLA;troll=yes;trunk-context=example.com@example.net > > effectively splitting the trunk parameters because the new parameter "troll" > is lexically in between. Broken implementations might then not recognize the > trunk parameters because they expect "trunk-group" immediately following > "trgrp" even in SIP URIs. > > Does the group consider this a problem? > > If it does, the issue could probably be mitigated by either: > > - renaming one of the parameters ("trgrp-context"?) > [that does not _solve_ it, as there are always strings "between"] > - instructing IANA to not register any tel URI parameter "between" > - relaxing the order of the parameters > - clarifying that clients which parse SIP user parts as tel URI must > must not rely on the parameter order. > > Anything else? > > comments appreciated. > > Alex Mayrhofer > enum.at > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Sun Nov 06 15:04:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYqka-0005oT-Cf; Sun, 06 Nov 2005 15:04:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX7Em-0003ux-L2 for iptel@megatron.ietf.org; Tue, 01 Nov 2005 20:16:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28070 for ; Tue, 1 Nov 2005 20:16:02 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX7TB-0003az-Qi for iptel@ietf.org; Tue, 01 Nov 2005 20:31:23 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 50A3E737AC; Wed, 2 Nov 2005 01:16:09 +0000 (GMT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/mixed; boundary=Apple-Mail-4-115628912 Message-Id: <91A6319C-3917-44C7-8451-BF11080356C8@insensate.co.uk> From: lconroy Subject: Re: [Iptel] idnits draft-ietf-iptel-tel-enumdi-01 Date: Wed, 2 Nov 2005 01:16:07 +0000 To: Cullen Jennings X-Mailer: Apple Mail (2.734) X-Spam-Score: 1.3 (+) X-Scan-Signature: 214c4b9fd640cafeeaa09a981bfa7351 X-Mailman-Approved-At: Sun, 06 Nov 2005 15:04:17 -0500 Cc: "iptel@ietf.org" , Stastny Richard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org --Apple-Mail-4-115628912 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Cullen, folks, Well spotted. Why Internet-drafts ->silently<- dropped the original attempt at -02 I have no idea. herewith the new, improved, -02 draft with updated boilerplate. (from experience, if we submit it as -03, then it will be rejected as it replaces -01). I also include an html file with the -01 to -02 delta from rfcdiff. In terms of the review, yes - there is only one real change to the body text, and that was to remove a typo (see the delta web page for details). BTW, here is the idnits report on the new draft: ----------------------------------------------- idnits 1.82 tmp/draft-ietf-iptel-tel-enumdi-02.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. No nits found. Checking nits according to http://www.ietf.org/ietf/1id- guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. No nits found. ----------------------------------------------- enjoy - this one will go into internet-drafts after IETF shadow. all the best, Lawrence --Apple-Mail-4-115628912 Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-iptel-tel-enumdi-02.txt" Content-Disposition: attachment; filename=draft-ietf-iptel-tel-enumdi-02.txt Content-Transfer-Encoding: quoted-printable IPTEL R. Stastny Internet-Draft Oefeg Expires: March 5, 2006 R. Shockey Neustar Inc. L. Conroy Siemens Roke Manor Research September 2005 The ENUM Dip Indicator parameter for the "tel" URI Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 5, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines a new parameter "enumdi" in the "tel" Uniform Resource Identifier (URI) as defined in RFC3966 to support the handling of ENUM queries in SIP proxies, H.323 gatekeepers and other VoIP network elements. The presence of the "enumdi" parameter indicates to the VoIP network element receiving an URI containing an Stastny, et al. Expires March 5, 2006 [Page 1] =0C Internet-Draft ENUM Dip Indicator "tel" URI parameter September 2005 E.164 number that an ENUM query as defined in RFC3761 has already been performed on the E.164 number indicated by the previous VoIP network element. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Normative Rules . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Handling an URI with the "enumdi" parameter . . . . . . . 6 4.2. Adding the "enumdi" parameter to URIs . . . . . . . . . . 6 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Stastny, et al. Expires March 5, 2006 [Page 2] =0C Internet-Draft ENUM Dip Indicator "tel" URI parameter September 2005 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in thisdocument are to be interpreted as described in BCP 14, RFC2119 [1]. Stastny, et al. Expires March 5, 2006 [Page 3] =0C Internet-Draft ENUM Dip Indicator "tel" URI parameter September 2005 2. Introduction VoIP network elements (including UAS and UAC) may be set up in different ways to handle E.164 [2] numbers during call setup, depending on the capabilities provided. One common approach is to query ENUM as defined in RFC3761 [3]. If the ENUM query leads to a result, the call is set-up accordingly. If the ENUM query does not lead finally to a result, another database may be queried and/or the call may finally routed to the PSTN. In doing so, the call may be routed to another VoIP network element. To indicate in signalling to this next VoIP element that an ENUM query has already be made for the "tel" URI (specified in RFC3966 [4]), the "enumdi" parameter is used, to prevent the next VoIP network element from repeating redundant queries. Stastny, et al. Expires March 5, 2006 [Page 4] =0C Internet-Draft ENUM Dip Indicator "tel" URI parameter September 2005 3. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC2234 [6]. enumdi =3D *1(enum-dip-indicator) enum-dip-indicator =3D ";enumdi" The "enum-dip-indicator" can appear in the "tel" URI at most once. Stastny, et al. Expires March 5, 2006 [Page 5] =0C Internet-Draft ENUM Dip Indicator "tel" URI parameter September 2005 4. Normative Rules This section discusses how a VoIP network element handles a received "tel" URI that contains the "enumdi" parameter or has accessed ENUM in e164.arpa for a given E.164 number and needs to add the parameter to a "tel" URI. 4.1. Handling an URI with the "enumdi" parameter If a VoIP network element receives a "tel" URI containing the "enumdi" parameter, the VoIP network element SHOULD NOT retrieve the related information for this number from ENUM in e164.arpa even if it would normally do so. If the received "tel" URI is to be passed to the next network element, the VoIP network element MUST pass on the received URI containing the "enumdi" parameter unchanged. 4.2. Adding the "enumdi" parameter to URIs When a VoIP network element accesses ENUM in e164.arpa for a given E.164 number and the result of the query is NXDOMAIN, and the network element chooses to pass the call to the next network element by using a "tel" URI, the "enumdi" parameter MUST be set. When a VoIP network element accesses ENUM in e164.arpa for a given E.164 number and either: o the result of the query includes a NAPTR RR containing a "tel" URI that has the same E.164 number, or o the result of the query includes a NAPTR RR containing a "tel" URI with the "enumdi" parameter set, then if that retrieved "tel" URI is chosen to be passed to the next network element, the sending VoIP network element MUST pass on the retrieved URI with the "enumdi" parameter set. Stastny, et al. Expires March 5, 2006 [Page 6] =0C Internet-Draft ENUM Dip Indicator "tel" URI parameter September 2005 5. Examples a. A VoIP network element "server.example.com" receives a "tel" URI . The VoIP network element accesses the DNS for NAPTR RR in 8.3.0.0.6.9.2.3.6.1.4.4.e164.arpa., and gets the response NXDOMAIN. The VoIP network element decides to route the call to the PSTN via another VoIP network element called "gw.example.com". It therefore signals to the next VoIP network element with: or (using the procedures of RFC3261 [5] section 19.1.6): . b. A VoIP network element "server.example.com" receives a "tel" URI . The VoIP network element accesses the DNS for NAPTR RR in 8.3.0.0.6.9.2.3.6.1.4.4.e164.arpa., and receives the same "tel" URI in reply (i.e. ). The VoIP network element decides to route the call to the PSTN via another VoIP network element "gw.example.com". It therefore signals to the next VoIP network element with: or (using the procedures of RFC3261 [5] section 19.1.6): . Stastny, et al. Expires March 5, 2006 [Page 7] =0C Internet-Draft ENUM Dip Indicator "tel" URI parameter September 2005 6. Security Considerations In addition to those security implications discussed in the "tel" URI [4] specification, there are new security implications associated with the defined parameter. If the "enumdi" is illegally inserted into the "tel" URI when the signaling message carrying the "tel" URI is en route to the destination entity, the call may be routed to the PSTN network, incurring unexpected charges or causing a downstream VoIP network element to reject the call setup. It is less a problem if the "enumdi" is illegally removed. An additional ENUM query may be performed to retrieve the routing number information and have the "enumdi" included again. It is RECOMMENDED that protocols carrying the "tel" URI ensure message integrity during the message transfer between the two communicating network elements so as to detect any unauthorized changes to the content of the "tel" URI and other information. Stastny, et al. Expires March 5, 2006 [Page 8] =0C Internet-Draft ENUM Dip Indicator "tel" URI parameter September 2005 7. IANA Considerations This document requires no IANA actions. Stastny, et al. Expires March 5, 2006 [Page 9] =0C Internet-Draft ENUM Dip Indicator "tel" URI parameter September 2005 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. [3] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [4] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 8.2. Informative References [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [7] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. [8] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [9] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. Stastny, et al. Expires March 5, 2006 [Page 10] =0C Internet-Draft ENUM Dip Indicator "tel" URI parameter September 2005 Authors' Addresses Richard Stastny Oefeg Postbox 147 1103 Vienna Austria Phone: +43-664-420-4100 Email: Richard.stastny@oefeg.at Richard Shockey Neustar Inc. 46000 Center Oak Plaza Sterling, VA 20166 United States Phone: +1-571-434-5651 Email: richard.shockey@neustar.biz Lawrence Conroy Siemens Roke Manor Research Roke Manor Romsey United Kingdom Phone: +44-1794-833666 Email: lwc@roke.co.uk Stastny, et al. Expires March 5, 2006 [Page 11] =0C Internet-Draft ENUM Dip Indicator "tel" URI parameter September 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Stastny, et al. Expires March 5, 2006 [Page 12] =0C --Apple-Mail-4-115628912 Content-Type: text/html; x-unix-mode=0644; x-mac-hide-extension=yes; name="enumdi-01-02-delta.html" Content-Disposition: attachment; filename=enumdi-01-02-delta.html Content-Transfer-Encoding: 7bit Diff: draft-ietf-iptel-tel-enumdi-01.txt - draft-ietf-iptel-tel-enumdi-02.txt
 draft-ietf-iptel-tel-enumdi-01.txt   draft-ietf-iptel-tel-enumdi-02.txt 
IPTEL R. Stastny IPTEL R. Stastny
Internet-Draft Oefeg Internet-Draft Oefeg
Expires: September 2, 2005 R. Shockey Expires: March 5, 2006 R. Shockey
Neustar Inc. Neustar Inc.
L. Conroy L. Conroy
Siemens Roke Manor Research Siemens Roke Manor Research
March 1, 2005 September 2005
The ENUM Dip Indicator parameter for the "tel" URI The ENUM Dip Indicator parameter for the "tel" URI
<draft-ietf-iptel-tel-enumdi-01.txt> <draft-ietf-iptel-tel-enumdi-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2005. This Internet-Draft will expire on March 5, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines a new parameter "enumdi" in the "tel" Uniform This document defines a new parameter "enumdi" in the "tel" Uniform
Resource Identifier (URI) as defined in RFC3966 to support the Resource Identifier (URI) as defined in RFC3966 to support the
handling of ENUM queries in SIP proxies, H.323 gatekeepers and other handling of ENUM queries in SIP proxies, H.323 gatekeepers and other
skipping to change at page 2, line 16 skipping to change at page 2, line 14
E.164 number that an ENUM query as defined in RFC3761 has already E.164 number that an ENUM query as defined in RFC3761 has already
been performed on the E.164 number indicated by the previous VoIP been performed on the E.164 number indicated by the previous VoIP
network element. network element.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Normative Rules . . . . . . . . . . . . . . . . . . . . . . . 6 4. Normative Rules . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Handling an URI with the "enumdi" parameter . . . . . . . 6 4.1. Handling an URI with the "enumdi" parameter . . . . . . . 6
4.2 Adding the "enumdi" parameter to URIs . . . . . . . . . . 6 4.2. Adding the "enumdi" parameter to URIs . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1 Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2 Informative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
thisdocument are to be interpreted as described in BCP 14, RFC2119 thisdocument are to be interpreted as described in BCP 14, RFC2119
[1]. [1].
2. Introduction 2. Introduction
skipping to change at page 6, line 12 skipping to change at page 6, line 12
The "enum-dip-indicator" can appear in the "tel" URI at most once. The "enum-dip-indicator" can appear in the "tel" URI at most once.
4. Normative Rules 4. Normative Rules
This section discusses how a VoIP network element handles a received This section discusses how a VoIP network element handles a received
"tel" URI that contains the "enumdi" parameter or has accessed ENUM "tel" URI that contains the "enumdi" parameter or has accessed ENUM
in e164.arpa for a given E.164 number and needs to add the parameter in e164.arpa for a given E.164 number and needs to add the parameter
to a "tel" URI. to a "tel" URI.
4.1 Handling an URI with the "enumdi" parameter 4.1. Handling an URI with the "enumdi" parameter
If a VoIP network element receives a "tel" URI containing the If a VoIP network element receives a "tel" URI containing the
"enumdi" parameter, the VoIP network element SHOULD NOT retrieve the "enumdi" parameter, the VoIP network element SHOULD NOT retrieve the
related information for this number from ENUM in e164.arpa even if it related information for this number from ENUM in e164.arpa even if it
would normally do so. would normally do so.
If the received "tel" URI is to be passed to the next network If the received "tel" URI is to be passed to the next network
element, the VoIP network element MUST pass on the received URI element, the VoIP network element MUST pass on the received URI
containing the "enumdi" parameter unchanged. containing the "enumdi" parameter unchanged.
4.2 Adding the "enumdi" parameter to URIs 4.2. Adding the "enumdi" parameter to URIs
When a VoIP network element accesses ENUM in e164.arpa for a given When a VoIP network element accesses ENUM in e164.arpa for a given
E.164 number and the result of the query is NXDOMAIN, and the network E.164 number and the result of the query is NXDOMAIN, and the network
element chooses to pass the call to the next network element by using element chooses to pass the call to the next network element by using
a "tel" URI, the "enumdi" parameter MUST be set. a "tel" URI, the "enumdi" parameter MUST be set.
When a VoIP network element accesses ENUM in e164.arpa for a given When a VoIP network element accesses ENUM in e164.arpa for a given
E.164 number and either: E.164 number and either:
o the result of the query includes a NAPTR RR containing a "tel" URI o the result of the query includes a NAPTR RR containing a "tel" URI
that has the same E.164 number, or that has the same E.164 number, or
o the result of the query includes a NAPTR RR containing a "tel" URI o the result of the query includes a NAPTR RR containing a "tel" URI
with the "enumdi" parameter set, with the "enumdi" parameter set,
then if that retrieved "tel" URI is chosen to be passed to the next then if that retrieved "tel" URI is chosen to be passed to the next
network element, the sending VoIP network element MUST pass on the network element, the sending VoIP network element MUST pass on the
retrieved URI with the "enumdi" parameter set. retrieved URI with the "enumdi" parameter set.
5. Examples 5. Examples
a. A VoIP network element "server.example.com" receives a "tel" URI a. A VoIP network element "server.example.com" receives a "tel" URI
skipping to change at page 8, line 14 skipping to change at page 8, line 14
6. Security Considerations 6. Security Considerations
In addition to those security implications discussed in the "tel" URI In addition to those security implications discussed in the "tel" URI
[4] specification, there are new security implications associated [4] specification, there are new security implications associated
with the defined parameter. with the defined parameter.
If the "enumdi" is illegally inserted into the "tel" URI when the If the "enumdi" is illegally inserted into the "tel" URI when the
signaling message carrying the "tel" URI is en route to the signaling message carrying the "tel" URI is en route to the
destination entity, the call may be routed to the PSTN network, destination entity, the call may be routed to the PSTN network,
incurring unexpected charges or the causing a downstream VoIP network incurring unexpected charges or causing a downstream VoIP network
element to reject the call setup. element to reject the call setup.
It is less a problem if the "enumdi" is illegally removed. An It is less a problem if the "enumdi" is illegally removed. An
additional ENUM query may be performed to retrieve the routing number additional ENUM query may be performed to retrieve the routing number
information and have the "enumdi" included again. information and have the "enumdi" included again.
It is RECOMMENDED that protocols carrying the "tel" URI ensure It is RECOMMENDED that protocols carrying the "tel" URI ensure
message integrity during the message transfer between the two message integrity during the message transfer between the two
communicating network elements so as to detect any unauthorized communicating network elements so as to detect any unauthorized
changes to the content of the "tel" URI and other information. changes to the content of the "tel" URI and other information.
7. IANA Considerations 7. IANA Considerations
This document requires no IANA actions. This document requires no IANA actions.
8. References 8. References
8.1 Normative References 8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[2] ITU-T, "The International Public Telecommunication Number Plan", [2] ITU-T, "The International Public Telecommunication Number Plan",
Recommendation E.164, May 1997. Recommendation E.164, May 1997.
[3] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource [3] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004. Application (ENUM)", RFC 3761, April 2004.
[4] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, [4] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004. December 2004.
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
8.2 Informative References 8.2. Informative References
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[7] Bradner, S., "The Internet Standards Process -- Revision 3", [7] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, BCP 9, October 1996. RFC 2026, BCP 9, October 1996.
[8] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, [8] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
February 2004. February 2004.
 End of changes. 16 change blocks. 
24 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/
--Apple-Mail-4-115628912 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On 29 Oct 2005, at 17:33, Cullen Jennings wrote: > Ok, I'm pretty sure I have tracked down what happened to this. The IPR > statement is wrong and it was rejected. It looks like it has the > 3667 IPR > boiler plate and it needs the 3978. Anything submitted after last May > without the 3978 has been rejected. > > Check you xml has ipr="full3978". Run idnits. XML2RFC will generate > many > things that contain all kinds of problems including lines too wide, > invalid > characters, and bad IPR. > > >> From a review point of view, it looks like there is no difference >> from the 01 version to the 02 version that got mailed to the list. >> Is that correct? > --Apple-Mail-4-115628912 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --Apple-Mail-4-115628912-- From iptel-bounces@ietf.org Sun Nov 06 15:32:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYrBh-0004aI-2S; Sun, 06 Nov 2005 15:32:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYrBe-0004aD-Ft for iptel@megatron.ietf.org; Sun, 06 Nov 2005 15:32:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18664 for ; Sun, 6 Nov 2005 15:31:58 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYrR6-0003zI-NN for iptel@ietf.org; Sun, 06 Nov 2005 15:48:22 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2005 12:32:12 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA6KW8dv014157; Sun, 6 Nov 2005 12:32:09 -0800 (PST) Received: from 10.21.122.30 ([10.21.122.30]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 6 Nov 2005 20:32:43 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 06 Nov 2005 12:32:08 -0800 Subject: Re: [Iptel] One more trivial NIT on iptel-tel-enumdi-02 From: Cullen Jennings To: Alexander Mayrhofer , Richard Shockey , "Vijay K. Gurbani" Message-ID: Thread-Topic: [Iptel] One more trivial NIT on iptel-tel-enumdi-02 Thread-Index: AcXjEShMZrc2Vk8EEdqCeAARJEEJ/A== In-Reply-To: <436A0994.402@enum.at> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: "iptel@ietf.org" , Stastny Richard , Lawrence Conroy X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org On 11/3/05 4:59 AM, "Alexander Mayrhofer" wrote: > I also think that "No considerations for IANA" should be clarified. Without > the background of the tel URI registry draft this is a imho bit misleading > (and, could be interpreted as an suggestion that tel URI parameters do not > need to be registered/coordinated at all [otoh, 3966 section 5.4 clarifies > this already]). Makes sense - we have this same problem across all these drafts. Anyone have suggestions on text to put in. I want it clear to IANA that they don't have to do anything. > >>> Can we also get someone to do a NITS review of this draft. It the >>> review was >>> already done in the ENUM group then I am happy to skip it. > > My comments are as follows: > Many thanks for the excellent review. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 08 01:48:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZNHa-0003Ns-7s; Tue, 08 Nov 2005 01:48:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZNHX-0003IX-TY for iptel@megatron.ietf.org; Tue, 08 Nov 2005 01:48:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14753 for ; Tue, 8 Nov 2005 01:48:09 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZNXH-00016M-Nc for iptel@ietf.org; Tue, 08 Nov 2005 02:04:53 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jA86mK4p028966; Tue, 8 Nov 2005 00:48:20 -0600 (CST) Received: from lucent.com (vkg.lra.lucent.com [192.11.171.226]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id jA86mJo28079; Tue, 8 Nov 2005 00:48:19 -0600 (CST) Message-ID: <43704A51.6090205@lucent.com> Date: Tue, 08 Nov 2005 00:48:49 -0600 From: "Vijay K. Gurbani" Organization: Wireless Research and Development Group User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings , Alexander Mayrhofer Subject: Re: [Iptel] trunk-group draft: parameter name contemplation... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: "iptel@ietf.org" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Cullen Jennings wrote: > That is a great catch. Agreed. Thanks for connecting the obtuse dots, Alex. More inline. > I think we should fix the BNF so that it > relaxes the order constraint and perhaps add a note pointing out the > the troll example. > > Seems there are two ways to fix the ABNF, one would be > par = parameter / extension / isdn-sub / trunk-group / > trunk-group-context > > and then add text that say if there is a trunk-group there MUST be a > trunk-group-context. The other way might be to define > > trunk-group = ";tgrp=" trunk-group-lable [ *(par) ] ";trunk-context=" > trunk-context There is one more option that does not depend on lexicographical ordering at all. For the sake of completeness, I will list it here, but I will note that if we had to choose, I would rather choose Cullen's first option listed above. The third option is to have one name-value parameter, but impose some order on the value portion of that parameter. In other words, par = parameter / extension/ isdn-sub / trunk-group trunk-group = ";tgrp=" trunk-group-label and impose some order on trunk-group-label such that what used to be "trunk-context" occurs now in trunk-group-label, possibly following the label itself in some well defined manner. While this shields implementations from lexicographical ordering, it has the capacity to introduce some brittleness in system. For that reason, I prefer Cullen's first option. It appears to be one with the least amount of disruption to what is currently specified. Any other thoughts? If not, I will just as soon choose it... Thanks, - vijay _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 08 10:13:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZV9l-00054I-Gs; Tue, 08 Nov 2005 10:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZV9j-00054D-V4 for iptel@megatron.ietf.org; Tue, 08 Nov 2005 10:13:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10539 for ; Tue, 8 Nov 2005 10:12:36 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZVPY-0006Gy-Lr for iptel@ietf.org; Tue, 08 Nov 2005 10:29:25 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 08 Nov 2005 07:12:54 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jA8FCoeQ013271; Tue, 8 Nov 2005 07:12:51 -0800 (PST) Received: from 10.21.81.137 ([10.21.81.137]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 Nov 2005 15:13:26 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 08 Nov 2005 07:12:51 -0800 Subject: Re: [Iptel] trunk-group draft: parameter name contemplation... From: Cullen Jennings To: "Vijay K. Gurbani" , Alexander Mayrhofer Message-ID: Thread-Topic: [Iptel] trunk-group draft: parameter name contemplation... Thread-Index: AcXkduKqISFTOFBqEdqJOQARJEEJ/A== In-Reply-To: <43704A51.6090205@lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Cc: "iptel@ietf.org" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org On 11/7/05 10:48 PM, "Vijay K. Gurbani" wrote: > Any other thoughts? If not, I will just as soon choose it... I'm voting for just choose soon :-) _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Nov 10 22:29:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaPb5-0002YZ-3K; Thu, 10 Nov 2005 22:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaPb3-0002Y3-OD for iptel@megatron.ietf.org; Thu, 10 Nov 2005 22:29:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08144 for ; Thu, 10 Nov 2005 22:28:33 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaPrN-0006A4-1e for iptel@ietf.org; Thu, 10 Nov 2005 22:45:55 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 10 Nov 2005 19:28:50 -0800 X-IronPort-AV: i="3.99,115,1131350400"; d="scan'208"; a="673862742:sNHT25327644" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAB3SVZS025595; Thu, 10 Nov 2005 19:28:48 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 19:28:43 -0800 Received: from [10.21.113.175] ([10.21.113.175]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 19:28:42 -0800 Message-ID: <43740FF3.2060303@cisco.com> Date: Thu, 10 Nov 2005 22:28:51 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: iptel@ietf.org, Rohan Mahy References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2005 03:28:42.0906 (UTC) FILETIME=[0413CFA0:01C5E670] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Subject: [Iptel] Re: draft-mahy-iptel-cpc-03.txt X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Rohan, Did you intend this as an *alternative* to the proposed P-CPC parameter??? Or do you intend them to coexist and be used in different contexts? This draft isn't necessarily limited to sip, so I suppose usage conventions for sip may be out of scope, but I think there are some questions that need answering in that regard. - Section 3 says this should be "applied to URIs that characterize the originator of a call". Typically this will also be the identity used to provide "callerid". Should these attributes be displayed as part of the callerid? - a uri with parameters doesn't compare equal to one without. When call screening based on a black or white list of URIs, must that list be populated with the correct attributes? - When used with P-Asserted-ID, if Privacy is *not* invoked, so that the P-A-ID header is passed to the callee, should these parameters be removed? If so, what would give the terminating proxy, that isn't responsible for this address, the right to make such a change? - what happens if the police are originating a call with an identity that can only be represented as a sip uri? (E.g. sip:police@example.com) IMO these are roles of the identity, not part of the identity. Paul _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Nov 16 00:15:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcFZL-0003i0-2g; Wed, 16 Nov 2005 00:10:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcFZJ-0003fw-GN for iptel@megatron.ietf.org; Wed, 16 Nov 2005 00:10:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29616 for ; Wed, 16 Nov 2005 00:10:16 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcFqf-00031m-N2 for iptel@ietf.org; Wed, 16 Nov 2005 00:28:47 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2005 21:10:39 -0800 X-IronPort-AV: i="3.97,336,1125903600"; d="scan'208"; a="230923603:sNHT25184484" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAG5AWIq023077; Tue, 15 Nov 2005 21:10:33 -0800 (PST) Received: from 10.82.241.51 ([10.82.241.51]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Nov 2005 05:11:15 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 15 Nov 2005 19:53:25 -0800 Subject: Re: [Iptel] Re: draft-mahy-iptel-cpc-03.txt From: Cullen Jennings To: Paul H Kyzivat , "iptel@ietf.org" , Rohan Mahy Message-ID: Thread-Topic: [Iptel] Re: draft-mahy-iptel-cpc-03.txt Thread-Index: AcXqYUuKifzdJFZUEdqSOgARJEEJ/A== In-Reply-To: <43740FF3.2060303@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org >From memory, I may have this wrong .... I think that awhile back, the WG decided Rohan should proceed with this as an individual submission. Cullen On 11/10/05 7:28 PM, "Paul Kyzivat" wrote: > Rohan, > > Did you intend this as an *alternative* to the proposed P-CPC > parameter??? Or do you intend them to coexist and be used in different > contexts? > > This draft isn't necessarily limited to sip, so I suppose usage > conventions for sip may be out of scope, but I think there are some > questions that need answering in that regard. > > - Section 3 says this should be "applied to URIs that characterize the > originator of a call". Typically this will also be the identity used to > provide "callerid". Should these attributes be displayed as part of the > callerid? > > - a uri with parameters doesn't compare equal to one without. When call > screening based on a black or white list of URIs, must that list be > populated with the correct attributes? > > - When used with P-Asserted-ID, if Privacy is *not* invoked, so that the > P-A-ID header is passed to the callee, should these parameters be > removed? If so, what would give the terminating proxy, that isn't > responsible for this address, the right to make such a change? > > - what happens if the police are originating a call with an identity > that can only be represented as a sip uri? (E.g. sip:police@example.com) > > IMO these are roles of the identity, not part of the identity. > > Paul > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Nov 18 05:42:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3hR-000621-3U; Fri, 18 Nov 2005 05:42:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3hO-0005zj-3m for iptel@megatron.ietf.org; Fri, 18 Nov 2005 05:42:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08112 for ; Fri, 18 Nov 2005 05:41:55 -0500 (EST) Received: from smtp13.clb.oleane.net ([213.56.31.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed3zC-0002eO-Cl for iptel@ietf.org; Fri, 18 Nov 2005 06:00:55 -0500 Received: from Pavillonquatre ([194.3.133.88]) (authenticated) by smtp13.clb.oleane.net with ESMTP id jAIAgAIg009276 for ; Fri, 18 Nov 2005 11:42:14 +0100 Message-Id: <200511181042.jAIAgAIg009276@smtp13.clb.oleane.net> From: "Chantal Ladouce" To: Date: Fri, 18 Nov 2005 11:41:49 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXsLK5HwzEBmBVlQZOwqfSTuXJgJA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Subject: [Iptel] IMS at the International SIP 2006 - Paris - France X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0076046650==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============0076046650== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C5EC35.107E4660" This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C5EC35.107E4660 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Carriers Experience on SIP based IMS Real Size Experiments . Extending SIP IMS Architecture from Wireless to Wireline Networks . Challenges in IMS Testing Everything you need to know on IMS and SIP will be delivered at the International SIP conference to be held in Paris next 21-24 February 2006. Get all details at: http://www.upperside.fr/sip2006/sip2006program.htm#day2 ------=_NextPart_000_0063_01C5EC35.107E4660 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Carriers = Experience on SIP based IMS Real Size = Experiments

=

. Extending = SIP IMS Architecture from Wireless to Wireline Networks

=

. Challenges in = IMS Testing

=

 

Everything you = need to know on IMS and SIP will be delivered at the International SIP = conference to be held in Paris next 21-24 February 2006.

=

 

Get all details = at:

=

 

http://w= ww.upperside.fr/sip2006/sip2006program.htm#day2

 

 

------=_NextPart_000_0063_01C5EC35.107E4660-- --===============0076046650== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0076046650==-- From iptel-bounces@ietf.org Mon Nov 21 01:34:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee5GP-000110-LD; Mon, 21 Nov 2005 01:34:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee5GN-00010Y-UX for iptel@megatron.ietf.org; Mon, 21 Nov 2005 01:34:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07813 for ; Mon, 21 Nov 2005 01:34:13 -0500 (EST) Received: from web26714.mail.ukl.yahoo.com ([217.146.177.71]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ee5Ym-0000Xf-Lp for Iptel@ietf.org; Mon, 21 Nov 2005 01:53:53 -0500 Received: (qmail 74130 invoked by uid 60001); 21 Nov 2005 06:34:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bqn7K0GKJj+QwrtIxNs6oDxR6oMXuTxIPEQt6lXB1qmMOVs1k8jgYWVeg7JcmMtxNdmMkHP3lBRybgEAK/tW56j9BJaV0NFkaFhuLO4NNcWzUr1+TaE0eyphvFXuzYljvdO+lzMzAB6+Pnld0tRF4NlQg8BNoOFJThwSE6ewwxE= ; Message-ID: <20051121063442.74128.qmail@web26714.mail.ukl.yahoo.com> Received: from [157.159.46.172] by web26714.mail.ukl.yahoo.com via HTTP; Mon, 21 Nov 2005 07:34:41 CET Date: Mon, 21 Nov 2005 07:34:41 +0100 (CET) From: zaghouani hamdi To: Iptel@ietf.org In-Reply-To: <4D6E93075B31154298572E6B73CA849D02EC5717@noida-mail.bbnet.ad> MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Subject: [Iptel] problem: killed process X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0265402948==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org --===============0265402948== Content-Type: multipart/alternative; boundary="0-1492677041-1132554881=:74126" --0-1492677041-1132554881=:74126 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id BAA07813 hi, =20 I'm working on SER server. I'm using two SIP servers and a SIP phone (eyeBeam). Using the SIP phone, I register to the first SER server. this server s= end the request to the second server ( act as an Application Server) whi= ch send it back to the first.=20 =20 according to the SER programming guide : the SER server, Upon startup, = all children execute "recvfrom" function. The process will enter the ker= nel mode. When there is no data to be processed at the moment, the kerne= l will put the process on list of processes waiting for data and the pro= cess will be put asleep. =20 My problem is : when I run the SIP Phone, the first registration goes well and the 2 se= rvers exchanges the message without any problem( a child process is awak= ed to process the message) . But when I close the SIP Phone and the 2 se= rvers begun exchanging messages ( register with "expire header" 0), the = child process is killed (I don't know how) so the server is shutdown. sometimes I close the SIP phone without problem. and I get the problem = when I run the SIP Phone again. =20 I recieve this : ...... 33(18738) DBG: tcp_main_loop: dead child 14 (shutting down?) 0(18702) child process 18719 exited by a signal 11 0(18702) core was not generated 0(18702) INFO: terminating due to SIGCHLD 1(18703) INFO: signal 15 received ...... =20 =20 Do you have any idea how to resolve this problem. I ve worked on this problem for more than a week but vainly. I can't re= solve it. =20 ps: I added one module in the first server( I wrote c fonctions). when = the first server recieve the message from the SIP Phone, it process thi= s message before forwarding it to the seconde server.=20 =20 thanks a lot=20 =20 Hamdi who need your help. =20 =09 --------------------------------- Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messeng= er T=E9l=E9chargez le ici ! =20 --0-1492677041-1132554881=:74126 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id BAA07813

= hi,

I'm working on SER server.
I'm using two SIP server= s and a SIP phone (eyeBeam).
Using the SIP phone, I register to the = first SER server. this server send the request to the second server ( ac= t as an Application Server) which send it back to the first.

= according to the SER programming guide : the SER server, Upon startup, a= ll children execute "recvfrom" function. The process will enter the kern= el mode. When there is no data to be processed at the moment, the kernel= will put the process on list of processes waiting for data and the proc= ess will be put asleep.

My problem is :
when I run the SI= P Phone, the first registration goes well and the 2 servers exchanges th= e message without any problem( a child process is awaked to process the = message) . But when I close the SIP Phone and the 2 servers begun exchanging messages ( register with "expire header" 0), t= he child process is killed (I don't know how) so the server is shutdown.=
sometimes I close the SIP phone = without problem. and I get the = problem when I run the SIP Phone again.

I recieve this = :
......
33(18738) DBG: tcp_main_loop: dead child 14 (shuttin= g down?)
0(18702) child process 18719 exited by a signal 11
= 0(18702) core was not generated
0(18702) INFO: terminating due= to SIGCHLD
1(18703) INFO: signal 15 received
......

Do you have any idea how to resolve this problem.
I ve wor= ked on this problem for more than a week but vainly. I can't resolve it.<= br>
ps: I added one module in the first server( I wrote c fonction= s). when the first server recieve the message from the SIP Phone, it pro= cess this message before forwarding it to the seconde server.

thanks a lot

Hamdi who need your= help.



=20 Appel audio GRATUIT partout dans le monde= avec le nouveau Yahoo! Messenger
=20 T=E9l=E9chargez le ici !=20 =20 --0-1492677041-1132554881=:74126-- --===============0265402948== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0265402948==-- From iptel-bounces@ietf.org Tue Nov 29 13:40:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAOv-0006YZ-Vv; Tue, 29 Nov 2005 13:40:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAOr-0006V7-CN for iptel@megatron.ietf.org; Tue, 29 Nov 2005 13:40:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17560 for ; Tue, 29 Nov 2005 13:39:35 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhAiy-00074A-RP for iptel@ietf.org; Tue, 29 Nov 2005 14:01:09 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jATIe6u5018091; Tue, 29 Nov 2005 12:40:06 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id jATIe6r06782; Tue, 29 Nov 2005 12:40:06 -0600 (CST) Message-ID: <438CA085.80307@lucent.com> Date: Tue, 29 Nov 2005 12:40:05 -0600 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF IPTEL WG X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Cc: Cullen Jennings Subject: [Iptel] Nits review for trunk-group X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0987200337==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0987200337== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020308080904020608030107" This is a cryptographically signed message in MIME format. --------------ms020308080904020608030107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks: During the nits review of trunk-group, the two points of feedback were the lexicographic ordering of tel URI parameters and updating the draft to reflect the newly created I-D on tel URI parameter IANA registry. Accordingly, I am proposing that the trunk-group I-D be modified as described below (if you want to see this in the context of the draft, please see http://www.iit.edu/~gurbvij/I-D/draft-ietf-iptel-trunk-group-05.html or http://www.iit.edu/~gurbvij/I-D/draft-ietf-iptel-trunk-group-05.txt). I propose that Section 6 be modified as follows: The ABNF will now look like: par = parameter / extension / isdn-subaddress / trunk-group / trunk-context trunk-group = ";tgrp=" trunk-group-label trunk-context = ";trunk-context=" descriptor The following paragraph will be added: Trunk groups are identified by two parameters: "tgrp" and "trunk- context"; both of these parameters MUST be present in a tel URI to identify a trunk group. All implementations conforming to this specification MUST generate both of these parameters when using trunk groups. If an implementation receives a tel URI with only one of the "tgrp" or "trunk-context" parameters, it MUST act as if there were not any trunk group identifiers present at all in that URI. Whether or not to further process such an URI is up to the discretion of the implementation, however, if a decision is made to process it, the implementation must act as if there were not any trunk group identifiers present in the URI. In addition, a historical note is to be added on the lexicographic ordering of URI parameters as specified in rfc3261: Note that the base comparison rules for a sip or sips URI that has been derived from a tel URI mandate that the telephone-subscriber parameters be ordered lexically by parameter name (see Section 19.1.6 of [3]). Thus, when comparing a sip URI that has been derived from a tel URI, implementations MUST not assume that the "tgrp" and "trunk-context" parameters will appear in a consecutive manner because parameters defined by other tel URI extensions may lexically fit between "tgrp" and "trunk-context". Section 9 (IANA considerations) be modified as follows: The IANA registry for tel URIs is specified in [5]. It is initially seeded with the two trunk group parameters contained in this specification. For the sake of completeness, the IANA template for the two trunk group parameters is also specified below. Parameter name: tgrp ... Parameter name: trunk-context ... I will be submitting the final document early next week. Thanks, - vijay -- Vijay K. Gurbani, Ph.D. vkg@{lucent.com,research.bell-labs.com,acm.org} Lucent Technologies/Bell Laboratories, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 --------------ms020308080904020608030107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTExMjkxODQwMDVaMCMGCSqGSIb3DQEJ BDEWBBSJyTngue8tIDRPEy4NAvB+IMjeAjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAcHwsJ90S8cpt45I5n0RnvRFVIe7Wenyl2WTkX3zSwhfgMo3BbvfV dwOSZJ0QJeWknbJ4A2BGJbh7HfSngyd11GXMwzCgSrWGwgVks1uggQNtD7bAt7QhWylvYi1+ 88tzLCvzW3x6zXds7Ui7OSq7SMWpEJQek6Yi3Jx9zd3MB5sAAAAAAAA= --------------ms020308080904020608030107-- --===============0987200337== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0987200337==--