From pkyzivat@cisco.com Mon Jan 4 05:31:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69B943A6922 for ; Mon, 4 Jan 2010 05:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.357 X-Spam-Level: ** X-Spam-Status: No, score=2.357 tagged_above=-999 required=5 tests=[FH_DATE_PAST_20XX=10.357, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwgjyzs8UzBG for ; Mon, 4 Jan 2010 05:31:56 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3BF5628C107 for ; Mon, 4 Jan 2010 05:31:56 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ58QUtAZnwN/2dsb2JhbAC/DpM6hDAE X-IronPort-AV: E=Sophos;i="4.47,498,1257120000"; d="scan'208";a="78122355" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 04 Jan 2010 13:31:54 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o04DVs2R021162; Mon, 4 Jan 2010 13:31:54 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Jan 2010 08:31:54 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Jan 2010 08:31:54 -0500 Message-ID: <4B41EDC9.6050204@cisco.com> Date: Mon, 04 Jan 2010 08:31:53 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gonzalo Camarillo , SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jan 2010 13:31:54.0437 (UTC) FILETIME=[47BC6F50:01CA8D42] Subject: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2010 13:31:57 -0000 Gonzalo, Over the holidays I had occasion to review the above document again, and I have a question about the criterion you propose for sending an error response or not: If any of the changes requested in a re-INVITE or in any transaction within it have already been executed (with the exception of target refreshes), the UAS MUST always return a 2xx response. A change to the session state is considered to have been executed when the new media parameters are being used. Therefore, a change to a stream subject to preconditions [RFC4032] is considered to have been executed when the new media parameters start being used; not when the preconditions for the stream are met. Connection establishment messages (e.g., TCP SYN) and connectivity checks (e.g., when using ICE [I-D.ietf-mmusic-ice]) are not considered media either. A UA considers the new parameters to be in use when it sends media using them, or when media that uses the new parameters is received, which should be interpreted as follows. From Section 8.3.1 of RFC 3264 [RFC3264]: "Received, in this case, means that the media is passed to a media sink. This means that if there is a playout buffer, the agent would continue to listen on the old port until the media on the new port reached the top of the playout buffer. At that time, it MAY cease listening for media on the old port." Consider the case where the o/a has been performed, and the UAC has sent media according to the new session description, but the UAS has not yet sent or received that media according to the definition above. In that case, the UAS may choose to send an error response. But the UAC has already made the change to the new session, and so will need to switch again to the old one. This is the case you are attempting to avoid, and yet it has not been avoided. I don't see an easy answer to this - only messy ones. Thanks, Paul From pkyzivat@cisco.com Mon Jan 4 06:52:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75433A690D for ; Mon, 4 Jan 2010 06:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.357 X-Spam-Level: ** X-Spam-Status: No, score=2.357 tagged_above=-999 required=5 tests=[FH_DATE_PAST_20XX=10.357, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hayIfl2TDydX for ; Mon, 4 Jan 2010 06:52:27 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D6AE228C0DD for ; Mon, 4 Jan 2010 06:52:27 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOeOQUurRN+K/2dsb2JhbADACpNFgiyCBAQ X-IronPort-AV: E=Sophos;i="4.47,498,1257120000"; d="scan'208";a="69639692" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 04 Jan 2010 14:52:27 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o04EqQSS024797; Mon, 4 Jan 2010 14:52:26 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Jan 2010 09:52:26 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Jan 2010 09:52:26 -0500 Message-ID: <4B4200A7.6070500@cisco.com> Date: Mon, 04 Jan 2010 09:52:23 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Shida Schubert References: <4B13C4FC.5050907@sipstation.com><98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net><10A79C23-41FB-4FF8-AD55-2F83D7017EFC@gmail.com> <057B55FD-2B09-4296-AB60-6FA7E47EDD37@ntt-at.com> <9886E5FCA6D76549A3011068483A4BD40551C3B6@S4DE8PSAAQB.mitte.t-com.de> <52DC7475-F576-4397-B1CF-0C6ED6540089@gmail.com> <4B1BDE5A.1060608@ericsson.com> <4B1BEF51.1080805@cisco.com> <8FD558CE-A0DD-45B4-ABDD-148986C4C347@ntt-at.com> In-Reply-To: <8FD558CE-A0DD-45B4-ABDD-148986C4C347@ntt-at.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jan 2010 14:52:26.0049 (UTC) FILETIME=[8799EB10:01CA8D4D] Cc: Francois Audet , sipcore@ietf.org, R.Jesske@telekom.de Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2010 14:52:28 -0000 Shida Schubert wrote: > If the focus is about which target (AoR) is to be considered for > any special call handling such as voicemail (use of RFC4458?) > , so when call is forwarded the receiving end knows there is a > preferred identity which is to be honored, then we may have > some work to do with History-Info but otherwise I don't think > there is much more to do beside elaborating the voicemail section. > > Any thoughts? I don't understand how RFC4458 applies here. That applies in the case where you have some node (perhaps a proxy) that *knows* it wants to send a call to VM, and *knows* which mailbox it wants to target. In that case the only goal is to find a way to encode that info into an AOR. AFAIK, the question under discussion here is different. We are passing the call through a number of different intermediaries. More than one of them may have a policy of sending the call to VM under certain circumstances. The goal here is to harmonize the policies such that the call gets to the *right* VM server and mailbox. In fact, the situation is more general than that, since the desired policy may not involve sending the call to VM at all. The solutions that involve H-I all assume various things about the nature of the policies that might be in place along the path. E.g.: - a node that just sends an unanswered call to its own VM server and VM-mailbox is assuming that the policy of prior nodes on the path is irrelevant, or that the desired policy of prior nodes is for later ones to prefer their own VM. - a node that sends an unanswered call to its own VM server, with the selection of VM-mailbox based on the first AOR in H-I is assuming: that the first AOR shares a VM server with it; that the mapping from AOR to VM-mailbox is consistent with its own; and that the caller and/or server for that first AOR intended an unanswered call to go to its VM-mailbox. IMO these are unreasonable assumptions. Thanks, Paul > Regards > Shida > > On Dec 7, 2009, at 2:52 AM, Paul Kyzivat wrote: > >> The main tactic I know of that is currently deployed to address this need is to cancel the forwarded call after a few "rings", hopefully before it is transferred to voicemail there. But of course that doesn't work if you guess wrong about the number of rings, and especially if the call goes direct to voicemail. >> >> While there is no way, once I have forwarded a call to you, for me to *prevent* you from handling the call as voicemail, it is typically in the best interests of both of us. Specifically, if I am forwarding the call to you, but asked you *not* to send the call to your voicemail, then honoring that saves you the trouble handling the voicemail, and also keeps you in my good graces. >> >> So the key here is to communicate preferences for how the call should be handed, and define the recommended handling of calls in the presence of such a recommendation. >> >> The basics to do this have been in callerprefs for a long time. But I don't think they have been considered seriously in this context. I'm not *certain* that is sufficient to address the problem, but it seems like the right starting point. >> >> Note that this sort of approach *does not* require looking back in the History-Info to decide which voice mailbox to use. >> >> Thanks, >> Paul >> >> >> Gonzalo Camarillo wrote: >>> Hi, >>>> When you think about it, it makes sense. >>>> >>>> If you call me, you would expect to get my voicemail, not somebody else's. >>> yes, Paul's example has been discussed *many* times. So, addressing it in some way would be a good thing. >>> Cheers, >>> Gonzalo >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > From gsalguei@cisco.com Mon Jan 4 13:59:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52713A681F for ; Mon, 4 Jan 2010 13:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5H-uUF3ct483 for ; Mon, 4 Jan 2010 13:59:55 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id CCFA23A679C for ; Mon, 4 Jan 2010 13:59:54 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o04LxqAj000663; Mon, 4 Jan 2010 16:59:52 -0500 (EST) Received: from dhcp-64-102-221-199.cisco.com (dhcp-64-102-221-199.cisco.com [64.102.221.199]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o04Lxpw5018846; Mon, 4 Jan 2010 16:59:51 -0500 (EST) Message-Id: <72165739-1538-4905-87E4-B125A3F662A0@cisco.com> From: Gonzalo Salgueiro To: "Eric Burger" In-Reply-To: <503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 4 Jan 2010 16:59:51 -0500 References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <4B39AE2C.9090304@softarmor.com> <503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE , Gonzalo Salgueiro , "Paul E. Jones" Subject: Re: [sipcore] [dispatch] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2010 21:59:55 -0000 I agree with Eric's comments. The need for this is very real and there are serious deficiencies with fax transport using SIP that need to be addressed. The work by the SIP Forum FoIP TG will provide the needed identification, investigation and possible resolution to these problems. I propose we forge ahead with publication of this draft as an informational RFC. Please provide any input on this draft so progress can continue to be made on this. Gonzalo On Jan 3, 2010, at 9:59 AM, Eric Burger wrote: > Looking at this discussion in its entirety, I have to admit to what > might be a retro-verso conclusion. The arguments against fax (a > legacy technology that is 50 years OLDER than voice) have the > identical characteristic of those who said real-time IP > communications would never work. Cannot guarantee anything, only a > best-effort network, no one would want to use it. Blah, blah, blah. > > Really folks: there is a real need, a real market, and a promising > solution space. If *you* do not want to work on it, because ATM is > really the technology of the gods, great. However, there are others > who are working on it, so please either help out or create those > 5-10-year-out technologies that really will replace fax. > > > On Dec 29, 2009, at 2:22 AM, Dean Willis wrote: > >> Paul Kyzivat wrote: >>> I know this is a bit off topic, and doesn't alleviate the problem, >>> but has anybody ever proposed that an INVITE with offer for fax be >>> responded to with a 3xx containing a mailto: URI? Or that ENUM >>> for a fax device yield a mailto uri? >> >> I was going to say "redirect to T.37, since real-time fax over VoIP >> is just a bad idea" but Paul beat me to it. >> >> Seriously: fax over IP really only works when the real-time >> conversion is done close to the edge of the IP network. and the >> core transit is store-and-forward/ The close to the consumer edge, >> the better. Trying to retrofit the timing equirements of fax onto >> RTP is an exercise in futility for those who don't understand the >> concept of lossy networks. >> >> -- >> Dean >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > From dean.willis@softarmor.com Mon Jan 4 16:38:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB363A680C; Mon, 4 Jan 2010 16:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nmrkpblpvzU; Mon, 4 Jan 2010 16:38:36 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 22F1A3A67AD; Mon, 4 Jan 2010 16:38:33 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o050cShq009724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Jan 2010 18:38:30 -0600 Message-Id: <1AA2A44A-3C89-4903-879C-9F74E459C93D@softarmor.com> From: Dean Willis To: Eric Burger In-Reply-To: <503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 4 Jan 2010 18:38:23 -0600 References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <4B39AE2C.9090304@softarmor.com> <503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com> X-Mailer: Apple Mail (2.936) Cc: "Paul E. Jones" , dispatch@ietf.org, SIPCORE Subject: Re: [sipcore] [dispatch] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 00:38:37 -0000 On Jan 3, 2010, at 8:59 AM, Eric Burger wrote: > Looking at this discussion in its entirety, I have to admit to what > might be a retro-verso conclusion. The arguments against fax (a > legacy technology that is 50 years OLDER than voice) have the > identical characteristic of those who said real-time IP > communications would never work. Cannot guarantee anything, only a > best-effort network, no one would want to use it. Blah, blah, blah. > > Really folks: there is a real need, a real market, and a promising > solution space. If *you* do not want to work on it, because ATM is > really the technology of the gods, great. However, there are others > who are working on it, so please either help out or create those > 5-10-year-out technologies that really will replace fax. > > > On Dec 29, 2009, at 2:22 AM, Dean Willis wrote: > >> Paul Kyzivat wrote: >>> I know this is a bit off topic, and doesn't alleviate the problem, >>> but has anybody ever proposed that an INVITE with offer for fax be >>> responded to with a 3xx containing a mailto: URI? Or that ENUM >>> for a fax device yield a mailto uri? >> >> I was going to say "redirect to T.37, since real-time fax over VoIP >> is just a bad idea" but Paul beat me to it. >> >> Seriously: fax over IP really only works when the real-time >> conversion is done close to the edge of the IP network. and the >> core transit is store-and-forward/ The close to the consumer edge, >> the better. Trying to retrofit the timing equirements of fax onto >> RTP is an exercise in futility for those who don't understand the >> concept of lossy networks. >> Do not misunderstand. I'm not saying one can't do fax reliably over IP. I'm saying that it's much easier to do if one converts the circuit- modulated fax signal to something IP friendly at the edge of the IP network, then converts it back at the far edge if necessary. Sometimes tunneling protocols makes sense. However, tunneling a very time-sensitive protocol over a temporaly looser protocol is generally a bad idea. The RT in RTP may be Real Time, but in the absence of some troublingly large buffering and redundant transmission overhead, fax over RTP just isn't Real Timely. If we take a step back and re-assess the requirements, we're likely to end up with a very different architecture than we get from trying to carry fax-squawk-sounds in real time over the net. For example, why can't we just put a T.37 gateway into every ATA? The answer has to do more with the inability to map user-supplied destination phone numbers into email-style addresses than it has to do with the limitations of DSP, processor, and memory in those ATA boxes. Oddly enough, this is exactly the same phone-number transformation problem we're arguing about in general SIP work, and it probably has the same kind of answer. Another approach would be to use a T.37-like transport that uses a more SIP-friendly addressing schema. Fax over MSRP? Fax over XMPP? Both are imminently doable, and the general approach seems quite obvious. It also gives a closer-to-real-time feel to the resulting fax transmission than seems toe be the case with whole-document store-and- forward technologies. -- Dean From gao.yang2@zte.com.cn Mon Jan 4 23:30:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B4F3A67A2; Mon, 4 Jan 2010 23:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -87.976 X-Spam-Level: X-Spam-Status: No, score=-87.976 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_83=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AuGKfJgw9XL; Mon, 4 Jan 2010 23:30:53 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id B2FFE3A67E4; Mon, 4 Jan 2010 23:30:51 -0800 (PST) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91102001811080; Tue, 5 Jan 2010 15:06:00 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 78921.5060307279; Tue, 5 Jan 2010 15:30:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o057UbTu019100; Tue, 5 Jan 2010 15:30:37 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4B41EDC9.6050204@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 5 Jan 2010 15:29:24 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-01-05 15:30:28, Serialize complete at 2010-01-05 15:30:28 Content-Type: multipart/alternative; boundary="=_alternative 00293BA9482576A2_=" X-MAIL: mse2.zte.com.cn o057UbTu019100 Cc: SIPCORE , sipcore-bounces@ietf.org Subject: [sipcore] =?gb2312?b?tPC4tDogIFF1ZXN0aW9uIG9uIGRyYWZ0LWNhbWFyaWxs?= =?gb2312?b?by1zaXBjb3JlLXJlaW52aXRlLTAxLnR4dA==?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 07:30:54 -0000 This is a multipart message in MIME format. --=_alternative 00293BA9482576A2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUGF1bCwNCg0KSSBoYXZlIGhhZCB0aGUgc2FtZSBwdXp6bGUgb25jZS4gQW5kIEkgdGhvdWdo dCBpdCBhczoNCg0KSSdkIGxpa2UgdG8gdGFsayB0aGUgc2VtYW50aWNzIG9mIHRocmVlIGRpZmZl cmVudCBjb25jZXB0IGZpcnN0bHk6DQoxLiBPL0E7DQoyLiBjb25maXJtYXRpb24gb2Ygc2Vzc2lv biBtb2RpZmljYXRpb247DQozLiBzZXNzaW9uIHVzYWdlIGluIHByYWN0aWNlLg0KDQpXaXRob3V0 IHByZWNvbmRpdGlvbiwgTy9BIG1lYW5zIDEgJiAyLCBidXQgbm90IDMuDQoNCldpdGggcHJlY29u ZGl0aW9uLCBPL0EganVzdCBtZWFucyAxLCBub3QgMiAmIDMuDQoNCkFuZCBJIHRoaW5rICJjb25m aXJtYXRpb24gb2Ygc2Vzc2lvbiBtb2RpZmljYXRpb24iIHNob3VsZCBiZSB0cmVhdGVkIGFzIA0K c2lnbmFsbGluZyBvZiBjaGFuZ2luZyBvZiBzZXNzaW9uIHN0YXRlLCB3aGlsZSBub3QgInNlc3Np b24gdXNhZ2UgaW4gDQpwcmFjdGljZSIuDQoNCkZvciBPL0Egd2l0aG91dCBwcmVjb25kaXRpb24s IGZpbmlzaCBvZiBjdXJyZW50IE8vQSBjYW4gYmUgdHJlYXRlZCBhcyANCnNpZ25hbGxpbmcgb2Yg IjIiLiBGdXJ0aGVyLCBvZmZlcmVyIG9yIGFuc3dlcmVyIGNhbiBkZWNpZGUgdG8gc2VuZCgiMyIp IA0KbmV3IHNlc3Npb24gc2VwYXJhdGVseS6hoUJ1dCBmb3IgTy9BcyB3aXRoIHByZWNvbmRpdGlv biwgdGhlcmUgaXMgbm8gc3VjaCANCmV2aWRlbnQgc2lnbmFsbGluZyBmb3IgIjIiLiBXaGlsZSB0 aGUgYW5zd2VyIHdpdGggcHJlY29uZGl0aW9uIGNhbiBub3QgYmUgDQp0cmVhdGVkIGFzIHRoZSBh Y2NlcHRhbmNlIG9mIGN1cnJlbnQgbW9kaWZpY2F0aW9uLCB0aGUgb2ZmZXJlciBzaG91bGQgbm90 IA0KdXNlIHRoZSBuZXcgc2Vzc2lvbiBmaXJzdGx5LiBTbywgaXQgaXMgcmF0aW9uYWwoYnV0IG5v dCBub3JtYXRpdmVseSANCmRlZmluZWQpIGZvciB0aGUgYW5zd2VyZXIgdG8gc3RhcnQgdG8gdXNl IHRoZSBuZXcgc2Vzc2lvbiBmaXJzdGx5Lg0KSWYgd2Ugb2JleSB0aGlzIHN1Z2dlc3Rpb24sIFVB QyhpZiBVQUMgc2VuZHMgUmUtSU5WSVRFIHdpdGggb2ZmZXIpIHNob3VsZCANCm5vdCB1c2UgbmV3 IHNlc3Npb24gZmlyc3RseS4gQW5kIHRoZSBjYXNlIGNhbiBiZSBPSy4NCldoaWxlIHRoZSBVQVMg aXMgdGhlIG9mZmVyZXIoVUFDIHNlbmRzIFJlLUlOVklURSB3aXRob3V0IG9mZmVyKSwgVUFDIGFu ZCANClVBUyBjYW4gcmF0aW9uYWxpemUgaXRzIGJlaGF2aW9yIGFjY29yZGluZyB0byB0aGlzIHN1 Z2dlc3Rpb24gdG9vLg0KDQpGb3IgaW50ZWdyYWxpdHksIHdlIHNob3VsZCB0YWxrIGFib3V0IHRo ZSBjYXNlIHdoaWNoIGhhcyBzdXNlcXVlbnQgTy9BIA0Kd2l0aCBuZXcgbW9kaWZpY2F0aW9uIGR1 cmluZyBzdXNwZW5kaW5nIHN0YXRlIG9mIHByZXZpb3VzIG1vZGlmaWNhdGlvbi4NCklmIHRoZSBh bnN3ZXJlciBhY2NlcHRzIHRoZSBuZXcgbW9kaWZpY2F0aW9uIGFuZCBzZW5kIHRoZSBhbnN3ZXIs IHRoZSBVQVMgDQpzaG91bGQgbm90IHNlbmRzIDN4eC02eHgoc29tZXRoaW5nIGhhcyBiZWVuIGNo YW5nZWQpLg0KSWYgdGhlIGFuc3dlcmVyIGNhbiBub3QgYWNjZXB0IHRoZSBuZXcgbW9kaWZpY2F0 aW9uKHN1Y2ggYXMgbmVlZGluZyB1c2VyJ3MgDQpjb25maXJtYXRpb24pLCB0aGUgYW5zd2VyZXIg c2hvdWxkIHJlamVjdCB0aGUgb2ZmZXIoaWYgdGhlIHJlYXNvbiBpcyANCm5lZWRpbmcgdXNlcidz IGNvbmZpcm1hdGlvbiwgdGhlIHByb3BlciByZXNwb25zZSBjYW4gYmUgNTA0KS4gQXMgdGhlIA0K cmVqZWN0aW9uLCB0aGUgb3JpZ2luYWwgbW9kaWZpY2F0aW9uIHdvdWxkIHByb2Nlc3MgYXMgaWYg dGhlcmUncyBubyANCnN1YnNlcXVlbnQgTy9BLg0KDQpUaGFua3MuDQoNCkdhbw0KDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6 IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJA enRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNClBh dWwgS3l6aXZhdCA8cGt5eml2YXRAY2lzY28uY29tPiANCreivP7IyzogIHNpcGNvcmUtYm91bmNl c0BpZXRmLm9yZw0KMjAxMC0wMS0wNCAyMTozMQ0KDQrK1bz+yMsNCkdvbnphbG8gQ2FtYXJpbGxv IDxHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20+LCBTSVBDT1JFIA0KPHNpcGNvcmVAaWV0 Zi5vcmc+DQqzrcvNDQoNCtb3zOINCltzaXBjb3JlXSBRdWVzdGlvbiBvbiBkcmFmdC1jYW1hcmls bG8tc2lwY29yZS1yZWludml0ZS0wMS50eHQNCg0KDQoNCg0KDQoNCkdvbnphbG8sDQoNCk92ZXIg dGhlIGhvbGlkYXlzIEkgaGFkIG9jY2FzaW9uIHRvIHJldmlldyB0aGUgYWJvdmUgZG9jdW1lbnQg YWdhaW4sIGFuZCANCkkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IHRoZSBjcml0ZXJpb24geW91IHBy b3Bvc2UgZm9yIHNlbmRpbmcgYW4gZXJyb3IgDQpyZXNwb25zZSBvciBub3Q6DQoNCiAgICBJZiBh bnkgb2YgdGhlIGNoYW5nZXMgcmVxdWVzdGVkIGluIGEgcmUtSU5WSVRFIG9yIGluIGFueSB0cmFu c2FjdGlvbg0KICAgIHdpdGhpbiBpdCBoYXZlIGFscmVhZHkgYmVlbiBleGVjdXRlZCAod2l0aCB0 aGUgZXhjZXB0aW9uIG9mIHRhcmdldA0KICAgIHJlZnJlc2hlcyksIHRoZSBVQVMgTVVTVCBhbHdh eXMgcmV0dXJuIGEgMnh4IHJlc3BvbnNlLg0KDQogICAgQSBjaGFuZ2UgdG8gdGhlIHNlc3Npb24g c3RhdGUgaXMgY29uc2lkZXJlZCB0byBoYXZlIGJlZW4gZXhlY3V0ZWQNCiAgICB3aGVuIHRoZSBu ZXcgbWVkaWEgcGFyYW1ldGVycyBhcmUgYmVpbmcgdXNlZC4gIFRoZXJlZm9yZSwgYSBjaGFuZ2Ug dG8NCiAgICBhIHN0cmVhbSBzdWJqZWN0IHRvIHByZWNvbmRpdGlvbnMgW1JGQzQwMzJdIGlzIGNv bnNpZGVyZWQgdG8gaGF2ZQ0KICAgIGJlZW4gZXhlY3V0ZWQgd2hlbiB0aGUgbmV3IG1lZGlhIHBh cmFtZXRlcnMgc3RhcnQgYmVpbmcgdXNlZDsgbm90DQogICAgd2hlbiB0aGUgcHJlY29uZGl0aW9u cyBmb3IgdGhlIHN0cmVhbSBhcmUgbWV0LiAgQ29ubmVjdGlvbg0KICAgIGVzdGFibGlzaG1lbnQg bWVzc2FnZXMgKGUuZy4sIFRDUCBTWU4pIGFuZCBjb25uZWN0aXZpdHkgY2hlY2tzIChlLmcuLA0K ICAgIHdoZW4gdXNpbmcgSUNFIFtJLUQuaWV0Zi1tbXVzaWMtaWNlXSkgYXJlIG5vdCBjb25zaWRl cmVkIG1lZGlhDQogICAgZWl0aGVyLiAgQSBVQSBjb25zaWRlcnMgdGhlIG5ldyBwYXJhbWV0ZXJz IHRvIGJlIGluIHVzZSB3aGVuIGl0IHNlbmRzDQogICAgbWVkaWEgdXNpbmcgdGhlbSwgb3Igd2hl biBtZWRpYSB0aGF0IHVzZXMgdGhlIG5ldyBwYXJhbWV0ZXJzIGlzDQogICAgcmVjZWl2ZWQsIHdo aWNoIHNob3VsZCBiZSBpbnRlcnByZXRlZCBhcyBmb2xsb3dzLiAgRnJvbSBTZWN0aW9uIDguMy4x DQogICAgb2YgUkZDIDMyNjQgW1JGQzMyNjRdOg0KDQogICAgICAgIlJlY2VpdmVkLCBpbiB0aGlz IGNhc2UsIG1lYW5zIHRoYXQgdGhlIG1lZGlhIGlzIHBhc3NlZCB0byBhIG1lZGlhDQogICAgICAg c2luay4gIFRoaXMgbWVhbnMgdGhhdCBpZiB0aGVyZSBpcyBhIHBsYXlvdXQgYnVmZmVyLCB0aGUg YWdlbnQNCiAgICAgICB3b3VsZCBjb250aW51ZSB0byBsaXN0ZW4gb24gdGhlIG9sZCBwb3J0IHVu dGlsIHRoZSBtZWRpYSBvbiB0aGUNCiAgICAgICBuZXcgcG9ydCByZWFjaGVkIHRoZSB0b3Agb2Yg dGhlIHBsYXlvdXQgYnVmZmVyLiAgQXQgdGhhdCB0aW1lLCBpdA0KICAgICAgIE1BWSBjZWFzZSBs aXN0ZW5pbmcgZm9yIG1lZGlhIG9uIHRoZSBvbGQgcG9ydC4iDQoNCkNvbnNpZGVyIHRoZSBjYXNl IHdoZXJlIHRoZSBvL2EgaGFzIGJlZW4gcGVyZm9ybWVkLCBhbmQgdGhlIFVBQyBoYXMgc2VudCAN Cm1lZGlhIGFjY29yZGluZyB0byB0aGUgbmV3IHNlc3Npb24gZGVzY3JpcHRpb24sIGJ1dCB0aGUg VUFTIGhhcyBub3QgeWV0IA0Kc2VudCBvciByZWNlaXZlZCB0aGF0IG1lZGlhIGFjY29yZGluZyB0 byB0aGUgZGVmaW5pdGlvbiBhYm92ZS4gSW4gdGhhdCANCmNhc2UsIHRoZSBVQVMgbWF5IGNob29z ZSB0byBzZW5kIGFuIGVycm9yIHJlc3BvbnNlLiBCdXQgdGhlIFVBQyBoYXMgDQphbHJlYWR5IG1h ZGUgdGhlIGNoYW5nZSB0byB0aGUgbmV3IHNlc3Npb24sIGFuZCBzbyB3aWxsIG5lZWQgdG8gc3dp dGNoIA0KYWdhaW4gdG8gdGhlIG9sZCBvbmUuIFRoaXMgaXMgdGhlIGNhc2UgeW91IGFyZSBhdHRl bXB0aW5nIHRvIGF2b2lkLCBhbmQgDQp5ZXQgaXQgaGFzIG5vdCBiZWVuIGF2b2lkZWQuIEkgZG9u J3Qgc2VlIGFuIGVhc3kgYW5zd2VyIHRvIHRoaXMgLSBvbmx5IA0KbWVzc3kgb25lcy4NCg0KICAg ICAgICAgICAgICAgICBUaGFua3MsDQogICAgICAgICAgICAgICAgIFBhdWwNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlz dA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaXBjb3JlDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBv ZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBj b25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWlu dGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVu dHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBm aWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNv bGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5 IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Ig cGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4 cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRl ci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5 IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 00293BA9482576A2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFBhdWwsPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGhhdmUgaGFkIHRoZSBzYW1l IHB1enpsZSBvbmNlLiBBbmQNCkkgdGhvdWdodCBpdCBhczo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkknZCBsaWtlIHRvIHRhbGsgdGhlIHNlbWFudGlj cyBvZiB0aHJlZQ0KZGlmZmVyZW50IGNvbmNlcHQgZmlyc3RseTo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjEuIDxiPk8vQTwvYj47PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4yLiA8Yj5jb25maXJtYXRpb24gb2Ygc2Vzc2lvbiBt b2RpZmljYXRpb248L2I+OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+My4gPGI+c2Vzc2lvbiB1c2FnZSBpbiBwcmFjdGljZTwvYj4uPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XaXRob3V0IHByZWNvbmRpdGlvbiwgTy9B IG1lYW5zIDEgJmFtcDsNCjIsIGJ1dCBub3QgMy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldpdGggcHJlY29uZGl0aW9uLCBPL0EganVzdCBtZWFucyAx LA0Kbm90IDIgJmFtcDsgMy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkFuZCBJIHRoaW5rIDxiPiZxdW90O2NvbmZpcm1hdGlvbiBvZg0Kc2Vzc2lvbiBt b2RpZmljYXRpb248L2I+JnF1b3Q7IHNob3VsZCBiZSB0cmVhdGVkIGFzIHNpZ25hbGxpbmcgb2Yg Y2hhbmdpbmcNCm9mIHNlc3Npb24gc3RhdGUsIHdoaWxlIG5vdCAmcXVvdDs8Yj5zZXNzaW9uIHVz YWdlIGluIHByYWN0aWNlPC9iPiZxdW90Oy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkZvciBPL0Egd2l0aG91dCBwcmVjb25kaXRpb24sIGZpbmlzaA0K b2YgY3VycmVudCBPL0EgY2FuIGJlIHRyZWF0ZWQgYXMgc2lnbmFsbGluZyBvZiAmcXVvdDsyJnF1 b3Q7LiBGdXJ0aGVyLA0Kb2ZmZXJlciBvciBhbnN3ZXJlciBjYW4gZGVjaWRlIHRvIHNlbmQoJnF1 b3Q7MyZxdW90OykgbmV3IHNlc3Npb24gc2VwYXJhdGVseS6hoUJ1dA0KZm9yIE8vQXMgd2l0aCBw cmVjb25kaXRpb24sIHRoZXJlIGlzIG5vIHN1Y2ggZXZpZGVudCBzaWduYWxsaW5nIGZvciAmcXVv dDsyJnF1b3Q7Lg0KV2hpbGUgdGhlIGFuc3dlciB3aXRoIHByZWNvbmRpdGlvbiBjYW4gbm90IGJl IHRyZWF0ZWQgYXMgdGhlIGFjY2VwdGFuY2UNCm9mIGN1cnJlbnQgbW9kaWZpY2F0aW9uLCB0aGUg b2ZmZXJlciBzaG91bGQgbm90IHVzZSB0aGUgbmV3IHNlc3Npb24gZmlyc3RseS4NClNvLCBpdCBp cyA8Yj5yYXRpb25hbChidXQgbm90IG5vcm1hdGl2ZWx5IGRlZmluZWQpIDwvYj5mb3IgdGhlIGFu c3dlcmVyDQp0byBzdGFydCB0byB1c2UgdGhlIG5ldyBzZXNzaW9uIGZpcnN0bHkuPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiB3ZSBvYmV5IHRoaXMgc3VnZ2Vz dGlvbiwgVUFDKGlmIFVBQw0Kc2VuZHMgUmUtSU5WSVRFIHdpdGggb2ZmZXIpIHNob3VsZCBub3Qg dXNlIG5ldyBzZXNzaW9uIGZpcnN0bHkuIEFuZCB0aGUNCmNhc2UgY2FuIGJlIE9LLjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2hpbGUgdGhlIFVBUyBpcyB0aGUg b2ZmZXJlcihVQUMgc2VuZHMNClJlLUlOVklURSB3aXRob3V0IG9mZmVyKSwgVUFDIGFuZCBVQVMg Y2FuIHJhdGlvbmFsaXplIGl0cyBiZWhhdmlvciBhY2NvcmRpbmcNCnRvIHRoaXMgc3VnZ2VzdGlv biB0b28uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5G b3IgaW50ZWdyYWxpdHksIHdlIHNob3VsZCB0YWxrIGFib3V0DQp0aGUgY2FzZSB3aGljaCBoYXMg c3VzZXF1ZW50IE8vQSB3aXRoIG5ldyBtb2RpZmljYXRpb24gZHVyaW5nIHN1c3BlbmRpbmcNCnN0 YXRlIG9mIHByZXZpb3VzIG1vZGlmaWNhdGlvbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPklmIHRoZSBhbnN3ZXJlciBhY2NlcHRzIHRoZSBuZXcgbW9kaWZpY2F0 aW9uDQphbmQgc2VuZCB0aGUgYW5zd2VyLCB0aGUgVUFTIHNob3VsZCBub3Qgc2VuZHMgM3h4LTZ4 eChzb21ldGhpbmcgaGFzIGJlZW4NCmNoYW5nZWQpLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+SWYgdGhlIGFuc3dlcmVyIGNhbiBub3QgYWNjZXB0IHRoZSBuZXcN Cm1vZGlmaWNhdGlvbihzdWNoIGFzIG5lZWRpbmcgdXNlcidzIGNvbmZpcm1hdGlvbiksIHRoZSBh bnN3ZXJlciBzaG91bGQNCnJlamVjdCB0aGUgb2ZmZXIoaWYgdGhlIHJlYXNvbiBpcyBuZWVkaW5n IHVzZXIncyBjb25maXJtYXRpb24sIHRoZSBwcm9wZXINCnJlc3BvbnNlIGNhbiBiZSA1MDQpLiBB cyB0aGUgcmVqZWN0aW9uLCB0aGUgb3JpZ2luYWwgbW9kaWZpY2F0aW9uIHdvdWxkDQpwcm9jZXNz IGFzIGlmIHRoZXJlJ3Mgbm8gc3Vic2VxdWVudCBPL0EuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6 IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWls IDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij48Yj5QYXVsIEt5eml2YXQgJmx0O3BreXppdmF0QGNpc2NvLmNvbSZndDs8L2I+DQo8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjIwMTAtMDEtMDQgMjE6MzE8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+R29uemFsbyBDYW1hcmlsbG8gJmx0O0dvbnphbG8uQ2FtYXJp bGxvQGVyaWNzc29uLmNvbSZndDssDQpTSVBDT1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0Ozwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ W3NpcGNvcmVdIFF1ZXN0aW9uIG9uIGRyYWZ0LWNhbWFyaWxsby1zaXBjb3JlLXJlaW52aXRlLTAx LnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9 Mj48dHQ+R29uemFsbyw8YnI+DQo8YnI+DQpPdmVyIHRoZSBob2xpZGF5cyBJIGhhZCBvY2Nhc2lv biB0byByZXZpZXcgdGhlIGFib3ZlIGRvY3VtZW50IGFnYWluLCBhbmQNCjxicj4NCkkgaGF2ZSBh IHF1ZXN0aW9uIGFib3V0IHRoZSBjcml0ZXJpb24geW91IHByb3Bvc2UgZm9yIHNlbmRpbmcgYW4g ZXJyb3INCjxicj4NCnJlc3BvbnNlIG9yIG5vdDo8YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwO0lm IGFueSBvZiB0aGUgY2hhbmdlcyByZXF1ZXN0ZWQgaW4gYSByZS1JTlZJVEUgb3IgaW4gYW55DQp0 cmFuc2FjdGlvbjxicj4NCiAmbmJzcDsgJm5ic3A7d2l0aGluIGl0IGhhdmUgYWxyZWFkeSBiZWVu IGV4ZWN1dGVkICh3aXRoIHRoZSBleGNlcHRpb24NCm9mIHRhcmdldDxicj4NCiAmbmJzcDsgJm5i c3A7cmVmcmVzaGVzKSwgdGhlIFVBUyBNVVNUIGFsd2F5cyByZXR1cm4gYSAyeHggcmVzcG9uc2Uu PGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDtBIGNoYW5nZSB0byB0aGUgc2Vzc2lvbiBzdGF0ZSBp cyBjb25zaWRlcmVkIHRvIGhhdmUgYmVlbg0KZXhlY3V0ZWQ8YnI+DQogJm5ic3A7ICZuYnNwO3do ZW4gdGhlIG5ldyBtZWRpYSBwYXJhbWV0ZXJzIGFyZSBiZWluZyB1c2VkLiAmbmJzcDtUaGVyZWZv cmUsDQphIGNoYW5nZSB0bzxicj4NCiAmbmJzcDsgJm5ic3A7YSBzdHJlYW0gc3ViamVjdCB0byBw cmVjb25kaXRpb25zIFtSRkM0MDMyXSBpcyBjb25zaWRlcmVkDQp0byBoYXZlPGJyPg0KICZuYnNw OyAmbmJzcDtiZWVuIGV4ZWN1dGVkIHdoZW4gdGhlIG5ldyBtZWRpYSBwYXJhbWV0ZXJzIHN0YXJ0 IGJlaW5nIHVzZWQ7DQpub3Q8YnI+DQogJm5ic3A7ICZuYnNwO3doZW4gdGhlIHByZWNvbmRpdGlv bnMgZm9yIHRoZSBzdHJlYW0gYXJlIG1ldC4gJm5ic3A7Q29ubmVjdGlvbjxicj4NCiAmbmJzcDsg Jm5ic3A7ZXN0YWJsaXNobWVudCBtZXNzYWdlcyAoZS5nLiwgVENQIFNZTikgYW5kIGNvbm5lY3Rp dml0eSBjaGVja3MNCihlLmcuLDxicj4NCiAmbmJzcDsgJm5ic3A7d2hlbiB1c2luZyBJQ0UgW0kt RC5pZXRmLW1tdXNpYy1pY2VdKSBhcmUgbm90IGNvbnNpZGVyZWQNCm1lZGlhPGJyPg0KICZuYnNw OyAmbmJzcDtlaXRoZXIuICZuYnNwO0EgVUEgY29uc2lkZXJzIHRoZSBuZXcgcGFyYW1ldGVycyB0 byBiZSBpbg0KdXNlIHdoZW4gaXQgc2VuZHM8YnI+DQogJm5ic3A7ICZuYnNwO21lZGlhIHVzaW5n IHRoZW0sIG9yIHdoZW4gbWVkaWEgdGhhdCB1c2VzIHRoZSBuZXcgcGFyYW1ldGVycw0KaXM8YnI+ DQogJm5ic3A7ICZuYnNwO3JlY2VpdmVkLCB3aGljaCBzaG91bGQgYmUgaW50ZXJwcmV0ZWQgYXMg Zm9sbG93cy4gJm5ic3A7RnJvbQ0KU2VjdGlvbiA4LjMuMTxicj4NCiAmbmJzcDsgJm5ic3A7b2Yg UkZDIDMyNjQgW1JGQzMyNjRdOjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVv dDtSZWNlaXZlZCwgaW4gdGhpcyBjYXNlLCBtZWFucyB0aGF0IHRoZSBtZWRpYQ0KaXMgcGFzc2Vk IHRvIGEgbWVkaWE8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2luay4gJm5ic3A7VGhpcyBt ZWFucyB0aGF0IGlmIHRoZXJlIGlzIGEgcGxheW91dA0KYnVmZmVyLCB0aGUgYWdlbnQ8YnI+DQog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgd291bGQgY29udGludWUgdG8gbGlzdGVuIG9uIHRoZSBvbGQg cG9ydCB1bnRpbCB0aGUNCm1lZGlhIG9uIHRoZTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBu ZXcgcG9ydCByZWFjaGVkIHRoZSB0b3Agb2YgdGhlIHBsYXlvdXQgYnVmZmVyLiAmbmJzcDtBdA0K dGhhdCB0aW1lLCBpdDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNQVkgY2Vhc2UgbGlzdGVu aW5nIGZvciBtZWRpYSBvbiB0aGUgb2xkIHBvcnQuJnF1b3Q7PGJyPg0KPGJyPg0KQ29uc2lkZXIg dGhlIGNhc2Ugd2hlcmUgdGhlIG8vYSBoYXMgYmVlbiBwZXJmb3JtZWQsIGFuZCB0aGUgVUFDIGhh cyBzZW50DQo8YnI+DQptZWRpYSBhY2NvcmRpbmcgdG8gdGhlIG5ldyBzZXNzaW9uIGRlc2NyaXB0 aW9uLCBidXQgdGhlIFVBUyBoYXMgbm90IHlldA0KPGJyPg0Kc2VudCBvciByZWNlaXZlZCB0aGF0 IG1lZGlhIGFjY29yZGluZyB0byB0aGUgZGVmaW5pdGlvbiBhYm92ZS4gSW4gdGhhdA0KPGJyPg0K Y2FzZSwgdGhlIFVBUyBtYXkgY2hvb3NlIHRvIHNlbmQgYW4gZXJyb3IgcmVzcG9uc2UuIEJ1dCB0 aGUgVUFDIGhhcyA8YnI+DQphbHJlYWR5IG1hZGUgdGhlIGNoYW5nZSB0byB0aGUgbmV3IHNlc3Np b24sIGFuZCBzbyB3aWxsIG5lZWQgdG8gc3dpdGNoDQo8YnI+DQphZ2FpbiB0byB0aGUgb2xkIG9u ZS4gVGhpcyBpcyB0aGUgY2FzZSB5b3UgYXJlIGF0dGVtcHRpbmcgdG8gYXZvaWQsIGFuZA0KPGJy Pg0KeWV0IGl0IGhhcyBub3QgYmVlbiBhdm9pZGVkLiBJIGRvbid0IHNlZSBhbiBlYXN5IGFuc3dl ciB0byB0aGlzIC0gb25seQ0KPGJyPg0KbWVzc3kgb25lcy48YnI+DQo8YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KVGhhbmtzLDxi cj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQpQYXVsPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCnNpcGNvcmVAaWV0Zi5vcmc8YnI+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8YnI+DQo8YnI+ DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5i c3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtj b250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkm bmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6 YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJz cDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJz cDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZu YnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlz Y2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZu YnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJz cDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVs eSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZp ZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNw O2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNl aXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2Um bmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJz cDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMm bmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJz cDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3By ZT4= --=_alternative 00293BA9482576A2_=-- From dwing@cisco.com Tue Jan 5 14:00:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8C753A67D1 for ; Tue, 5 Jan 2010 14:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.932 X-Spam-Level: X-Spam-Status: No, score=-9.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGK4AWVRnqHN for ; Tue, 5 Jan 2010 14:00:20 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7E8A13A67AC for ; Tue, 5 Jan 2010 14:00:20 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwEAPJEQ0urRN+J/2dsb2JhbACIKoEUtgOUWoQwBA X-IronPort-AV: E=Sophos;i="4.49,224,1262563200"; d="scan'208";a="128823131" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2010 22:00:19 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o05M0JgM019814; Tue, 5 Jan 2010 22:00:19 GMT From: "Dan Wing" To: "'Vijay K. Gurbani'" , "'Dean Willis'" References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com><4B310591.7070808@alcatel-lucent.com><4B32DD8F.7050402@softarmor.com> <4B339552.1000402@alcatel-lucent.com> Date: Tue, 5 Jan 2010 14:00:19 -0800 Message-ID: <05f001ca8e52$78a6f2f0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4B339552.1000402@alcatel-lucent.com> Thread-Index: AcqEtVj2g0qj21qWRs65K143uE8gwQJnLreg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: 'SIPCORE' Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 22:00:21 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Vijay K. Gurbani > Sent: Thursday, December 24, 2009 8:23 AM > To: Dean Willis > Cc: SIPCORE > Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: > technical issues > > Dean Willis wrote: > > The adoption rate of TLS peaked a couple of years back, and > has been > > steadily declining since? That should tell us something > important. Like, > > maybe nobody can figure out how to implement this stuff, > nobody actually > > uses it, or nobody runs SIP on a hostile network. Not sure > which is the > > case, here. > > I don't think we can draw that general an argument that after > peaking the support for TLS is slipping now. We probably need > more data about the early bakeoffs -- going back to the 11th > bakeoff, which is the first one that took place after rfc3261 > was released. > > In any case, I think the data tells us that over the 9 SIPits > during which the data has been available, the support for TLS has > hovered in [0.38 - 0.63] range, with an average of 0.47. > > Essentially, less than 1/2 of the SIPit implementations that > are brought to the event support TLS. That itself is a > telling statistic. If the SIP UA and/or its proxy (nee, its SBC) aren't configured to support TCP (because of worries regarding head-of-line blocking, worries about TCP scalability, or whatever the reason), they aren't going to be running TLS-over-TCP. As to 'why', I would bet it's because TLS costs money, TCP costs money, folks aren't running SIP over hostile networks, and it's helpful to be able to run Wireshark (or whatever) to diagnose messages instead of hoping the SIP UA and proxy/SBC vendor have built adequate debugging/troubleshooting tools into their product. -d > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Wed Jan 6 10:49:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222E33A6881; Wed, 6 Jan 2010 10:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=-4.520, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_32=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_73=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oplaVyo9jWtC; Wed, 6 Jan 2010 10:49:19 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 98C343A6805; Wed, 6 Jan 2010 10:49:18 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAGNqREutJV2Z/2dsb2JhbACDXrtAhnoIjGCBKYItWgSCbg X-IronPort-AV: E=Sophos;i="4.49,230,1262563200"; d="scan'208";a="78592366" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 06 Jan 2010 18:49:16 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o06InGMA028591; Wed, 6 Jan 2010 18:49:16 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 12:49:16 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 12:49:16 -0600 Message-ID: <4B44DB22.1080408@cisco.com> Date: Wed, 06 Jan 2010 13:49:06 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 06 Jan 2010 18:49:16.0094 (UTC) FILETIME=[F24635E0:01CA8F00] Cc: SIPCORE , sipcore-bounces@ietf.org Subject: Re: [sipcore] =?gb2312?b?tPC4tDogIFF1ZXN0aW9uIG9uIGRyYWZ0LWNhbWFyaWxs?= =?gb2312?b?by1zaXBjb3JlLXJlaW52aXRlLTAxLnR4dA==?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 18:49:20 -0000 gao.yang2@zte.com.cn wrote: > > Hi Paul, > > I have had the same puzzle once. And I thought it as: > > I'd like to talk the semantics of three different concept firstly: > 1. *O/A*; > 2. *confirmation of session modification*; > 3. *session usage in practice*. > > Without precondition, O/A means 1 & 2, but not 3. > > With precondition, O/A just means 1, not 2 & 3. > > And I think *"confirmation of session modification*" should be treated > as signalling of changing of session state, while not "*session usage in > practice*". First, I want to hear what Gonzalo has to say, since it is his draft, and he had in mind how it would work. Second, lets see if things are clear without use of preconditions before discussing how use of preconditions might change things. Thanks, Paul > For O/A without precondition, finish of current O/A can be treated as > signalling of "2". Further, offerer or answerer can decide to send("3") > new session separately.　But for O/As with precondition, there is no > such evident signalling for "2". While the answer with precondition can > not be treated as the acceptance of current modification, the offerer > should not use the new session firstly. So, it is *rational(but not > normatively defined) *for the answerer to start to use the new session > firstly. > If we obey this suggestion, UAC(if UAC sends Re-INVITE with offer) > should not use new session firstly. And the case can be OK. > While the UAS is the offerer(UAC sends Re-INVITE without offer), UAC and > UAS can rationalize its behavior according to this suggestion too. > > For integrality, we should talk about the case which has susequent O/A > with new modification during suspending state of previous modification. > If the answerer accepts the new modification and send the answer, the > UAS should not sends 3xx-6xx(something has been changed). > If the answerer can not accept the new modification(such as needing > user's confirmation), the answerer should reject the offer(if the reason > is needing user's confirmation, the proper response can be 504). As the > rejection, the original modification would process as if there's no > subsequent O/A. > > Thanks. > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > *Paul Kyzivat * > 发件人: sipcore-bounces@ietf.org > > 2010-01-04 21:31 > > > 收件人 > Gonzalo Camarillo , SIPCORE > > 抄送 > > 主题 > [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt > > > > > > > > > Gonzalo, > > Over the holidays I had occasion to review the above document again, and > I have a question about the criterion you propose for sending an error > response or not: > > If any of the changes requested in a re-INVITE or in any transaction > within it have already been executed (with the exception of target > refreshes), the UAS MUST always return a 2xx response. > > A change to the session state is considered to have been executed > when the new media parameters are being used. Therefore, a change to > a stream subject to preconditions [RFC4032] is considered to have > been executed when the new media parameters start being used; not > when the preconditions for the stream are met. Connection > establishment messages (e.g., TCP SYN) and connectivity checks (e.g., > when using ICE [I-D.ietf-mmusic-ice]) are not considered media > either. A UA considers the new parameters to be in use when it sends > media using them, or when media that uses the new parameters is > received, which should be interpreted as follows. From Section 8.3.1 > of RFC 3264 [RFC3264]: > > "Received, in this case, means that the media is passed to a media > sink. This means that if there is a playout buffer, the agent > would continue to listen on the old port until the media on the > new port reached the top of the playout buffer. At that time, it > MAY cease listening for media on the old port." > > Consider the case where the o/a has been performed, and the UAC has sent > media according to the new session description, but the UAS has not yet > sent or received that media according to the definition above. In that > case, the UAS may choose to send an error response. But the UAC has > already made the change to the new session, and so will need to switch > again to the old one. This is the case you are attempting to avoid, and > yet it has not been avoided. I don't see an easy answer to this - only > messy ones. > > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. From paulej@packetizer.com Wed Jan 6 13:18:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9213A68BB; Wed, 6 Jan 2010 13:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M44OX9HzNeC; Wed, 6 Jan 2010 13:18:41 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 146E73A685B; Wed, 6 Jan 2010 13:18:41 -0800 (PST) Received: from berlin.arid.us (rrcs-98-101-146-143.midsouth.biz.rr.com [98.101.146.143]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o06LIXuk014750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jan 2010 16:18:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1262812718; bh=ve43QFgp94HV2UafopByA9xzxOzX6wplkvcmrS0Eac4=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=XaANKBeFy9rYHw32gyUxFNU5xm9BGoVFZy8gtp4nPUuKVQsMyCpEH560KntqzmV1k gj1zG7vLoPPHlsLoIW7F9E3MZBrQacgomwVb9ZAsm8HNr6RywlLsJC5Mgtk9URNaNV H8v6z+kILR3HFbQdH0MG63YZEglSqQ4R3r/Z/34M= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o06LIWxd029763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Jan 2010 16:18:32 -0500 From: "Paul E. Jones" To: , References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <4B39AE2C.9090304@softarmor.com> <503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com> <1AA2A44A-3C89-4903-879C-9F74E459C93D@softarmor.com> <4B433B4B.1030407@digium.com> <80D99821-B111-4C94-BC68-536CB65DD15E@softarmor.com> <4B43D7C5.1050306@cisco.com> <004f01ca8eb3$7659d790$630d86b0$@com> <4B44AC4E.4020309@cisco.com> <4B44AE40.2060104@digium.com> In-Reply-To: <4B44AE40.2060104@digium.com> Date: Wed, 6 Jan 2010 16:18:26 -0500 Message-ID: <00d101ca8f15$c91915b0$5b4b4110$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqO5jI9swAuBw1ZTtuX16JNwa5nVgALZ7cg Content-Language: en-us Subject: Re: [sipcore] [dispatch] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 21:18:42 -0000 Folks, We've had a number of exchanges and some people have missed a few messages as the thread bounced around two lists. I'm sending this to both sipcore and dispatch so that people do not miss the discussion. The question before us is whether we want to publish the SIP Forum Fax Problem statement as an informational RFC or not. The purpose of the document is to highlight the problems with fax, but does not attempt to propose a solution. It is believed that fax is an essential business tool and we must address identified issues. How we address the issues is not a subject of this document, but work will continue in the SIP Forum for some time. Perhaps once the work is progressed, then some output document might get presented to the IETF and/or ITU. What the final solution looks like, of course, will not be dictated by the SIP Forum, as it's not an SDO. I believe there is benefit in publishing the document just to keep the process as open as possible and encourage participation in the solution process. Is there any disagreement to presenting this document to the RFC Editor and IESG for publication? Paul From gao.yang2@zte.com.cn Wed Jan 6 16:54:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA64C3A695F for ; Wed, 6 Jan 2010 16:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.483 X-Spam-Level: X-Spam-Status: No, score=-89.483 tagged_above=-999 required=5 tests=[AWL=1.507, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_73=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQMny874t2ct for ; Wed, 6 Jan 2010 16:54:54 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 3D07C3A6951 for ; Wed, 6 Jan 2010 16:54:53 -0800 (PST) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91101727820181; Thu, 7 Jan 2010 08:29:55 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 75400.3533455949; Thu, 7 Jan 2010 08:54:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id o070sdVt052328; Thu, 7 Jan 2010 08:54:39 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4B44DB22.1080408@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 7 Jan 2010 08:53:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-01-07 08:54:39, Serialize complete at 2010-01-07 08:54:39 Content-Type: multipart/alternative; boundary="=_alternative 0004FED9482576A4_=" X-MAIL: mse1.zte.com.cn o070sdVt052328 Cc: SIPCORE Subject: [sipcore] =?gb2312?b?ILTwuLQ6ICBRdWVzdGlvbiBvbiBkcmFmdC1jYW1hcmls?= =?gb2312?b?bG8tc2lwY29yZS1yZWludml0ZS0wMS50eHQ=?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 00:54:56 -0000 This is a multipart message in MIME format. --=_alternative 0004FED9482576A4_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 PiBnYW8ueWFuZzJAenRlLmNvbS5jbiB3cm90ZToNCj4gPiANCj4gPiBIaSBQYXVsLA0KPiA+IA0K PiA+IEkgaGF2ZSBoYWQgdGhlIHNhbWUgcHV6emxlIG9uY2UuIEFuZCBJIHRob3VnaHQgaXQgYXM6 DQo+ID4gDQo+ID4gSSdkIGxpa2UgdG8gdGFsayB0aGUgc2VtYW50aWNzIG9mIHRocmVlIGRpZmZl cmVudCBjb25jZXB0IGZpcnN0bHk6DQo+ID4gMS4gKk8vQSo7DQo+ID4gMi4gKmNvbmZpcm1hdGlv biBvZiBzZXNzaW9uIG1vZGlmaWNhdGlvbio7DQo+ID4gMy4gKnNlc3Npb24gdXNhZ2UgaW4gcHJh Y3RpY2UqLg0KPiA+IA0KPiA+IFdpdGhvdXQgcHJlY29uZGl0aW9uLCBPL0EgbWVhbnMgMSAmIDIs IGJ1dCBub3QgMy4NCj4gPiANCj4gPiBXaXRoIHByZWNvbmRpdGlvbiwgTy9BIGp1c3QgbWVhbnMg MSwgbm90IDIgJiAzLg0KPiA+IA0KPiA+IEFuZCBJIHRoaW5rICoiY29uZmlybWF0aW9uIG9mIHNl c3Npb24gbW9kaWZpY2F0aW9uKiIgc2hvdWxkIGJlIHRyZWF0ZWQgDQoNCj4gPiBhcyBzaWduYWxs aW5nIG9mIGNoYW5naW5nIG9mIHNlc3Npb24gc3RhdGUsIHdoaWxlIG5vdCAiKnNlc3Npb24gdXNh Z2UgDQppbiANCj4gPiBwcmFjdGljZSoiLg0KPiANCj4gRmlyc3QsIEkgd2FudCB0byBoZWFyIHdo YXQgR29uemFsbyBoYXMgdG8gc2F5LCBzaW5jZSBpdCBpcyBoaXMgZHJhZnQsDQo+IGFuZCBoZSBo YWQgaW4gbWluZCBob3cgaXQgd291bGQgd29yay4NCj4gDQoNClN1cmUuIEFuZCBJIGxvb2sgZm9y d2FyZCB0byBHb256YWxvJ3MgcG9pbnQgdG9vLg0KDQpUaGFuaywNCg0KR2FvDQoNCj4gU2Vjb25k LCBsZXRzIHNlZSBpZiB0aGluZ3MgYXJlIGNsZWFyIHdpdGhvdXQgdXNlIG9mIHByZWNvbmRpdGlv bnMgYmVmb3JlDQo+IGRpc2N1c3NpbmcgaG93IHVzZSBvZiBwcmVjb25kaXRpb25zIG1pZ2h0IGNo YW5nZSB0aGluZ3MuDQo+IA0KPiAgICBUaGFua3MsDQo+ICAgIFBhdWwNCj4gDQo+ID4gRm9yIE8v QSB3aXRob3V0IHByZWNvbmRpdGlvbiwgZmluaXNoIG9mIGN1cnJlbnQgTy9BIGNhbiBiZSB0cmVh dGVkIGFzIA0KPiA+IHNpZ25hbGxpbmcgb2YgIjIiLiBGdXJ0aGVyLCBvZmZlcmVyIG9yIGFuc3dl cmVyIGNhbiBkZWNpZGUgdG8gDQpzZW5kKCIzIikgDQo+ID4gbmV3IHNlc3Npb24gc2VwYXJhdGVs eS6hoUJ1dCBmb3IgTy9BcyB3aXRoIHByZWNvbmRpdGlvbiwgdGhlcmUgaXMgbm8gDQo+ID4gc3Vj aCBldmlkZW50IHNpZ25hbGxpbmcgZm9yICIyIi4gV2hpbGUgdGhlIGFuc3dlciB3aXRoIHByZWNv bmRpdGlvbiANCmNhbiANCj4gPiBub3QgYmUgdHJlYXRlZCBhcyB0aGUgYWNjZXB0YW5jZSBvZiBj dXJyZW50IG1vZGlmaWNhdGlvbiwgdGhlIG9mZmVyZXIgDQo+ID4gc2hvdWxkIG5vdCB1c2UgdGhl IG5ldyBzZXNzaW9uIGZpcnN0bHkuIFNvLCBpdCBpcyAqcmF0aW9uYWwoYnV0IG5vdCANCj4gPiBu b3JtYXRpdmVseSBkZWZpbmVkKSAqZm9yIHRoZSBhbnN3ZXJlciB0byBzdGFydCB0byB1c2UgdGhl IG5ldyBzZXNzaW9uIA0KDQo+ID4gZmlyc3RseS4NCj4gPiBJZiB3ZSBvYmV5IHRoaXMgc3VnZ2Vz dGlvbiwgVUFDKGlmIFVBQyBzZW5kcyBSZS1JTlZJVEUgd2l0aCBvZmZlcikgDQo+ID4gc2hvdWxk IG5vdCB1c2UgbmV3IHNlc3Npb24gZmlyc3RseS4gQW5kIHRoZSBjYXNlIGNhbiBiZSBPSy4NCj4g PiBXaGlsZSB0aGUgVUFTIGlzIHRoZSBvZmZlcmVyKFVBQyBzZW5kcyBSZS1JTlZJVEUgd2l0aG91 dCBvZmZlciksIFVBQyANCmFuZCANCj4gPiBVQVMgY2FuIHJhdGlvbmFsaXplIGl0cyBiZWhhdmlv ciBhY2NvcmRpbmcgdG8gdGhpcyBzdWdnZXN0aW9uIHRvby4NCj4gPiANCj4gPiBGb3IgaW50ZWdy YWxpdHksIHdlIHNob3VsZCB0YWxrIGFib3V0IHRoZSBjYXNlIHdoaWNoIGhhcyBzdXNlcXVlbnQg Ty9BIA0KDQo+ID4gd2l0aCBuZXcgbW9kaWZpY2F0aW9uIGR1cmluZyBzdXNwZW5kaW5nIHN0YXRl IG9mIHByZXZpb3VzIA0KbW9kaWZpY2F0aW9uLg0KPiA+IElmIHRoZSBhbnN3ZXJlciBhY2NlcHRz IHRoZSBuZXcgbW9kaWZpY2F0aW9uIGFuZCBzZW5kIHRoZSBhbnN3ZXIsIHRoZSANCj4gPiBVQVMg c2hvdWxkIG5vdCBzZW5kcyAzeHgtNnh4KHNvbWV0aGluZyBoYXMgYmVlbiBjaGFuZ2VkKS4NCj4g PiBJZiB0aGUgYW5zd2VyZXIgY2FuIG5vdCBhY2NlcHQgdGhlIG5ldyBtb2RpZmljYXRpb24oc3Vj aCBhcyBuZWVkaW5nIA0KPiA+IHVzZXIncyBjb25maXJtYXRpb24pLCB0aGUgYW5zd2VyZXIgc2hv dWxkIHJlamVjdCB0aGUgb2ZmZXIoaWYgdGhlIA0KcmVhc29uIA0KPiA+IGlzIG5lZWRpbmcgdXNl cidzIGNvbmZpcm1hdGlvbiwgdGhlIHByb3BlciByZXNwb25zZSBjYW4gYmUgNTA0KS4gQXMgDQp0 aGUgDQo+ID4gcmVqZWN0aW9uLCB0aGUgb3JpZ2luYWwgbW9kaWZpY2F0aW9uIHdvdWxkIHByb2Nl c3MgYXMgaWYgdGhlcmUncyBubyANCj4gPiBzdWJzZXF1ZW50IE8vQS4NCj4gPiANCj4gPiBUaGFu a3MuDQo+ID4gDQo+ID4gR2FvDQo+ID4gDQo+ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCj4gPiBaaXAgICAgOiAyMTAwMTINCj4gPiBUZWwgICAgOiA4NzIxMQ0KPiA+IFRl bDIgICA6KCs4NiktMDI1LTUyODc3MjExDQo+ID4gZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20u Y24NCj4gPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiA+IA0KDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5p emF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVu dHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUg bm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0 aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRo IGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3Jp Z2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3Nh Z2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMg YmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVt Lg0K --=_alternative 0004FED9482576A4_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQo8YnI+DQomZ3Q7IGdhby55YW5nMkB6dGUuY29t LmNuIHdyb3RlOjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSGkgUGF1bCw8YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgaGF2ZSBoYWQgdGhlIHNhbWUgcHV6emxlIG9uY2Uu IEFuZCBJIHRob3VnaHQgaXQgYXM6PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJJ2Qg bGlrZSB0byB0YWxrIHRoZSBzZW1hbnRpY3Mgb2YgdGhyZWUgZGlmZmVyZW50IGNvbmNlcHQgZmly c3RseTo8YnI+DQomZ3Q7ICZndDsgMS4gKk8vQSo7PGJyPg0KJmd0OyAmZ3Q7IDIuICpjb25maXJt YXRpb24gb2Ygc2Vzc2lvbiBtb2RpZmljYXRpb24qOzxicj4NCiZndDsgJmd0OyAzLiAqc2Vzc2lv biB1c2FnZSBpbiBwcmFjdGljZSouPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBXaXRo b3V0IHByZWNvbmRpdGlvbiwgTy9BIG1lYW5zIDEgJmFtcDsgMiwgYnV0IG5vdCAzLjxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgV2l0aCBwcmVjb25kaXRpb24sIE8vQSBqdXN0IG1lYW5z IDEsIG5vdCAyICZhbXA7IDMuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBbmQgSSB0 aGluayAqJnF1b3Q7Y29uZmlybWF0aW9uIG9mIHNlc3Npb24gbW9kaWZpY2F0aW9uKiZxdW90Ow0K c2hvdWxkIGJlIHRyZWF0ZWQgPGJyPg0KJmd0OyAmZ3Q7IGFzIHNpZ25hbGxpbmcgb2YgY2hhbmdp bmcgb2Ygc2Vzc2lvbiBzdGF0ZSwgd2hpbGUgbm90ICZxdW90OypzZXNzaW9uDQp1c2FnZSBpbiA8 YnI+DQomZ3Q7ICZndDsgcHJhY3RpY2UqJnF1b3Q7Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBGaXJz dCwgSSB3YW50IHRvIGhlYXIgd2hhdCBHb256YWxvIGhhcyB0byBzYXksIHNpbmNlIGl0IGlzIGhp cyBkcmFmdCw8YnI+DQomZ3Q7IGFuZCBoZSBoYWQgaW4gbWluZCBob3cgaXQgd291bGQgd29yay48 YnI+DQomZ3Q7IDwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+U3VyZS4g QW5kIEkgbG9vayBmb3J3YXJkIHRvIEdvbnphbG8ncyBwb2ludCB0b28uPC90dD48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5UaGFuayw8L3R0PjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTI+PHR0PkdhbzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+PGJy Pg0KJmd0OyBTZWNvbmQsIGxldHMgc2VlIGlmIHRoaW5ncyBhcmUgY2xlYXIgd2l0aG91dCB1c2Ug b2YgcHJlY29uZGl0aW9ucw0KYmVmb3JlPGJyPg0KJmd0OyBkaXNjdXNzaW5nIGhvdyB1c2Ugb2Yg cHJlY29uZGl0aW9ucyBtaWdodCBjaGFuZ2UgdGhpbmdzLjxicj4NCiZndDsgPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7VGhhbmtzLDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1BhdWw8YnI+DQomZ3Q7 IDxicj4NCiZndDsgJmd0OyBGb3IgTy9BIHdpdGhvdXQgcHJlY29uZGl0aW9uLCBmaW5pc2ggb2Yg Y3VycmVudCBPL0EgY2FuIGJlIHRyZWF0ZWQNCmFzIDxicj4NCiZndDsgJmd0OyBzaWduYWxsaW5n IG9mICZxdW90OzImcXVvdDsuIEZ1cnRoZXIsIG9mZmVyZXIgb3IgYW5zd2VyZXIgY2FuDQpkZWNp ZGUgdG8gc2VuZCgmcXVvdDszJnF1b3Q7KSA8YnI+DQomZ3Q7ICZndDsgbmV3IHNlc3Npb24gc2Vw YXJhdGVseS6hoUJ1dCBmb3IgTy9BcyB3aXRoIHByZWNvbmRpdGlvbiwgdGhlcmUNCmlzIG5vIDxi cj4NCiZndDsgJmd0OyBzdWNoIGV2aWRlbnQgc2lnbmFsbGluZyBmb3IgJnF1b3Q7MiZxdW90Oy4g V2hpbGUgdGhlIGFuc3dlciB3aXRoDQpwcmVjb25kaXRpb24gY2FuIDxicj4NCiZndDsgJmd0OyBu b3QgYmUgdHJlYXRlZCBhcyB0aGUgYWNjZXB0YW5jZSBvZiBjdXJyZW50IG1vZGlmaWNhdGlvbiwg dGhlDQpvZmZlcmVyIDxicj4NCiZndDsgJmd0OyBzaG91bGQgbm90IHVzZSB0aGUgbmV3IHNlc3Np b24gZmlyc3RseS4gU28sIGl0IGlzICpyYXRpb25hbChidXQNCm5vdCA8YnI+DQomZ3Q7ICZndDsg bm9ybWF0aXZlbHkgZGVmaW5lZCkgKmZvciB0aGUgYW5zd2VyZXIgdG8gc3RhcnQgdG8gdXNlIHRo ZSBuZXcNCnNlc3Npb24gPGJyPg0KJmd0OyAmZ3Q7IGZpcnN0bHkuPGJyPg0KJmd0OyAmZ3Q7IElm IHdlIG9iZXkgdGhpcyBzdWdnZXN0aW9uLCBVQUMoaWYgVUFDIHNlbmRzIFJlLUlOVklURSB3aXRo IG9mZmVyKQ0KPGJyPg0KJmd0OyAmZ3Q7IHNob3VsZCBub3QgdXNlIG5ldyBzZXNzaW9uIGZpcnN0 bHkuIEFuZCB0aGUgY2FzZSBjYW4gYmUgT0suPGJyPg0KJmd0OyAmZ3Q7IFdoaWxlIHRoZSBVQVMg aXMgdGhlIG9mZmVyZXIoVUFDIHNlbmRzIFJlLUlOVklURSB3aXRob3V0IG9mZmVyKSwNClVBQyBh bmQgPGJyPg0KJmd0OyAmZ3Q7IFVBUyBjYW4gcmF0aW9uYWxpemUgaXRzIGJlaGF2aW9yIGFjY29y ZGluZyB0byB0aGlzIHN1Z2dlc3Rpb24NCnRvby48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IEZvciBpbnRlZ3JhbGl0eSwgd2Ugc2hvdWxkIHRhbGsgYWJvdXQgdGhlIGNhc2Ugd2hpY2gg aGFzIHN1c2VxdWVudA0KTy9BIDxicj4NCiZndDsgJmd0OyB3aXRoIG5ldyBtb2RpZmljYXRpb24g ZHVyaW5nIHN1c3BlbmRpbmcgc3RhdGUgb2YgcHJldmlvdXMgbW9kaWZpY2F0aW9uLjxicj4NCiZn dDsgJmd0OyBJZiB0aGUgYW5zd2VyZXIgYWNjZXB0cyB0aGUgbmV3IG1vZGlmaWNhdGlvbiBhbmQg c2VuZCB0aGUgYW5zd2VyLA0KdGhlIDxicj4NCiZndDsgJmd0OyBVQVMgc2hvdWxkIG5vdCBzZW5k cyAzeHgtNnh4KHNvbWV0aGluZyBoYXMgYmVlbiBjaGFuZ2VkKS48YnI+DQomZ3Q7ICZndDsgSWYg dGhlIGFuc3dlcmVyIGNhbiBub3QgYWNjZXB0IHRoZSBuZXcgbW9kaWZpY2F0aW9uKHN1Y2ggYXMg bmVlZGluZw0KPGJyPg0KJmd0OyAmZ3Q7IHVzZXIncyBjb25maXJtYXRpb24pLCB0aGUgYW5zd2Vy ZXIgc2hvdWxkIHJlamVjdCB0aGUgb2ZmZXIoaWYNCnRoZSByZWFzb24gPGJyPg0KJmd0OyAmZ3Q7 IGlzIG5lZWRpbmcgdXNlcidzIGNvbmZpcm1hdGlvbiwgdGhlIHByb3BlciByZXNwb25zZSBjYW4g YmUgNTA0KS4NCkFzIHRoZSA8YnI+DQomZ3Q7ICZndDsgcmVqZWN0aW9uLCB0aGUgb3JpZ2luYWwg bW9kaWZpY2F0aW9uIHdvdWxkIHByb2Nlc3MgYXMgaWYgdGhlcmUncw0Kbm8gPGJyPg0KJmd0OyAm Z3Q7IHN1YnNlcXVlbnQgTy9BLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhhbmtz Ljxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgR2FvPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiZndDsg Jmd0OyBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KJmd0OyAmZ3Q7IFRlbCAmbmJzcDsg Jm5ic3A7OiA4NzIxMTxicj4NCiZndDsgJmd0OyBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3 MjExPGJyPg0KJmd0OyAmZ3Q7IGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KJmd0 OyAmZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJz cDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2Nv bnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZu YnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXph dGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNw O2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNw O2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5i c3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNj bG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVu aWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5i c3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNw O2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5 Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlk dWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7 YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2Vp dmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZu YnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNw O21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNw O3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZu YnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZu YnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNw O1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJl Pg== --=_alternative 0004FED9482576A4_=-- From john.elwell@siemens-enterprise.com Thu Jan 7 02:25:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EDAB3A682A for ; Thu, 7 Jan 2010 02:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dt0-qC4O1kEE for ; Thu, 7 Jan 2010 02:25:18 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 6B3C53A68FB for ; Thu, 7 Jan 2010 02:25:17 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-460947; Thu, 7 Jan 2010 11:25:15 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 4ABE523F0209; Thu, 7 Jan 2010 11:25:15 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 7 Jan 2010 11:25:15 +0100 From: "Elwell, John" To: Gonzalo Camarillo , SIPCORE Date: Thu, 7 Jan 2010 11:25:13 +0100 Thread-Topic: [sipcore] WGLC draft-ietf-sipcore-info-events-03.txt Thread-Index: AcqEhCRkkOVAI0ztTsmH2JGjHBGiEAKh285Q Message-ID: References: <4B20DDCF.9000409@ericsson.com> <4B2A4717.5090100@ericsson.com> <4B3342C8.8090400@ericsson.com> In-Reply-To: <4B3342C8.8090400@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] WGLC draft-ietf-sipcore-info-events-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 10:25:19 -0000 I have read the document again - apologies for being late. I consider it re= ady to go with the exception of the following minor issues: 1. The last paragraph of section 1 seems to be redundant (the same text app= ears in section 2). 2. In section 3.2.1: " An INFO request can be associated with an Info Package (see X), or associated with a legacy INFO usage (see Y)." What are "X" and "Y"? 3. In section 3.2.1: " A UA MUST NOT use the INFO method outside an invite dialog usage. UAs indicate, per-dialog basis, for which Info Packages they are willing to receive INFO requests. The set of Info Packages cannot automatically be used within other dialogs." This mixing up the contexts of sending and receiving INFO requests, and als= o strays into subject matter that is the concern of section 4. It could ben= eficially be shortened to: "A UA MUST NOT send an INFO request outside an invite dialog usage and MUST= NOT send an INFO request for an Info Package if the remote UA on that dial= og has not indicated willingness to receive that Info-Package." 4. In 3.2.2: " If a UA receives an INFO request associated with an Info Package, and the message body part associated with the Info Package contains a message body MIME type that the UA support, but which usage is not defined for the specific Info Package, it is RECOMMENDED that the UA sends a 415 (Unsupported Media Type) response. The wording isn't quite right, and in particular the received message body = part is NOT associated with the Info Package - although I guess if it has C= ontent-Disposition Info-Package it is kind of linked to the Info Package, b= ut this Content-Disposition value is not introduced until 3.3.1. I think it= should say (also fixing some other nits): "If a UA receives an INFO request associated with an Info Package and the m= essage body part with Content-Disposition 'Info-Package' (see 3.3.1) has a = MIME type that the UA supports but not in the context of that Info Package,= it is RECOMMENDED that the UA send a 415 (Unsupported Media Type) response= ." 5. In 3.3.1: "UAs MUST conform to [RFC5621] to support multipart body parts." Is this intending to say: "UAs MUST support multipart body parts in accordance with [RFC5621]" or "UAs that need to use multipart body parts MUST do so in accordance with [R= FC5621]"? I suspect the first interpretation is intended, but a reader could interpre= t it either way. 6. In 3.3.1: "NOTE: Some SIP functions that are orthogonal to INFO can insert body parts unrelated to the Info Package." I am not sure a reader would understand this. Also, for legacy usage, a bod= y part could be related to INFO (i.e., not "orthogonal") but not related to= any Info Package. A possible improvement would be: "NOTE: An INFO request can also contain other body parts that are meaningfu= l within the context of an invite dialog usage but are not specifically ass= ociated with the INFO method and the application concerned." 7. In 4.2.2: "A UA can an empty Recv-Info header field" A verb is missing here - should it be "A UA can use an empty Recv-Info head= er field"? 8. In 4.2.2: "or that that the UA wishes to only receive INFO request for one of the Info Packages." Change "request" to "requests". 9. In 7.3: "or other user plane data transport mechanisms" For consistency with 7.4.2, should "user plane" be "media plane"? 10. In 7.4.2.1: "...and there is no need for the SIP signaling intermediates routing to examine the information..." This does not make sense. I think the word "routing" should be dropped, and= perhaps change "intermediates" to "intermediaries". 11. In 7.4.3: "Another alternative is to use a totally externally signaled channel, such as HTTP [RFC2616]." I don't know what "a totally externally signaled channel" means - perhaps i= t should say "a SIP-independent mechanism". 12. In 8.1: "This section describes the syntax extensions required for the INFO method." Two problems. Firstly, the syntax extensions are not in this section (8.1),= they are in 8.2. Secondly, 8.2 also defines syntax for Recv-Info, which is not part of the I= NFO method as such. 13. In 10.1: "if applications associated with the Info Package requires it" Change "requires" to "require". 14: In 10.1: " Section 7.4 describes alternative mechanisms, which should be considered as part of the process for solving a specific use-case, when for transporting application information." "when for" does not make sense. I suspect it should say "when there is a ne= ed for". 15. In 10.3: "overlap description" - change to "overall description". 16. In 10.4: "to be identify" - change to "to identify". John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 24 December 2009 10:31 > To: SIPCORE > Subject: Re: [sipcore] WGLC draft-ietf-sipcore-info-events-03.txt >=20 > Hi, >=20 > this WGLC ends today and we have not received *any* comments. >=20 > Cheers, >=20 > Gonzalo >=20 > Gonzalo Camarillo wrote: > > Hi, > >=20 > > we are half-way through this WGLC and no comments have been=20 > received.=20 > > You need to fire up! ;o) > >=20 > > Cheers, > >=20 > > Gonzalo > >=20 > > Gonzalo Camarillo wrote: > >> Folks, > >> > >> Christer has submitted a new version of the INFO Events=20 > draft (see email=20 > >> below) that is supposed to address all the comments=20 > received so far.=20 > >> Since there have been extensive discussions on this topic=20 > since the last=20 > >> time we WGLCed this draft, we are going to WGLC it again. > >> > >> http://tools.ietf.org/html/draft-ietf-sipcore-info-events-03 > >> > >> So, please, have a look at this new version and let us=20 > know whether or=20 > >> not you also think all comments have been addressed. Of=20 > course, you are=20 > >> also welcome to submit new comments should you have some.=20 > This WGLC will=20 > >> end on December 24th. > >> > >> Thanks, > >> > >> Gonzalo > >> SIPCORE co-chair > >> > >> -------- Original Message -------- > >> Subject: [sipcore] Draft new version:=20 > draft-ietf-sipcore-info-events > >> Date: Wed, 2 Dec 2009 09:59:24 +0100 > >> From: Christer Holmberg > >> To: > >> > >> > >> > >> > >> Hi, > >> > >> I've submitted a new version of the info draft. Hopefully=20 > all comments > >> and feedback have now been addressed. > >> > >> The biggest changes are: > >> > >> - Section 4.2: The usage of the Recv-Info header has been=20 > clarified, > >> some simple rules have been added, and there were some=20 > discussions that > >> since the re-INVITE fallback issue also affects Recv-Info (if you > >> receive a Recv-Info in a 18x to a re-INVITE, and the re-INVITE then > >> fails) and that we need some words about that. The text=20 > now says that IF > >> the request contains a Recv-Info header, the response must=20 > also contain it. > >> > >> - Section 11.4: Contains new wording about the IANA process for > >> registering info packages, including the expert review etc. > >> > >> - Section 12: Additional examples have been added > >> > >> > >> Please note that I did NOT remove Recv-Info in PRACKs,=20 > since there in my > >> opinion was no concensus to do so. > >> > >> > >> The draft can also be found at: > >> > >>=20 > _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-inf > o-events-03.txt_=20 > >> > >> > >> > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >>=20 > -------------------------------------------------------------- > ---------- > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From brian@estacado.net Thu Jan 7 14:10:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29743A684A for ; Thu, 7 Jan 2010 14:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r45qWb+AUD1o for ; Thu, 7 Jan 2010 14:10:11 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id A3D193A680E for ; Thu, 7 Jan 2010 14:10:11 -0800 (PST) Received: from [192.168.1.106] (cpe-76-182-241-151.tx.res.rr.com [76.182.241.151]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o07M8U1p066057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jan 2010 16:08:35 -0600 (CST) (envelope-from brian@estacado.net) Message-Id: From: Brian Hibbard To: "DRAGE, Keith (Keith)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 7 Jan 2010 16:08:29 -0600 References: <4656101B-A8F8-4EC3-B9D7-D2B01FD824B0@estacado.net> X-Mailer: Apple Mail (2.936) Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: document scope and intent X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 22:10:12 -0000 OK, it seems there is heavy agreement that this SHOULD be informational and not standards track. Do we have agreement on that? Specifically, Cullen, are you OK with that? Do you want to weigh in on the rationale for normative-strength statements? If there are no remaining objections, I can go ahead and make the draft informational and remove section 2 and references to RFC 2119. I'll make sure we have no normative-sounding SHOULDs, MUSTs, et al. -b On Dec 11, 2009, at 8:07 AM, DRAGE, Keith (Keith) wrote: > If so, you arbitrarily decided to change it because as far as I know > it was informational during its complete lifetime in the SIP group, > and I remember no discussion in the transfer to SIPCORE that made it > standards track. Certainly my final SIP status slides (and the ones > before and the ones before that ...) also say "Candidate: > Informational". The first version that carries an "intended status" > line is the 1st sipcore version, and this is at variance with the > charter pages. > > The last SIP charter pages clearly say: > Mar 2009 Example security flows to WGLC (Informational) > Jul 2009 Example security flows to IESG (Informational) > > And the SIPCORE charter pages state: > > Oct 2009 Example security flows to IESG (Informational) > > And from my own perspective this should still be informational. If > you feel there is standards track information in here, then pull it > out and submit it as a separate draft, and then the WG can decide > whether they want to proceed with such a standards track document. > > I'd also note to all authors that if you receive private messages of > interest, then at least please let the WG chairs know that you have > had those expressions of interest. If you received any of those > messages on sec-flows during its SIP lifetime, the ex SIP WG chairs > certainly have no evidence of them ever having been received - and > that is essential information to the PROTO writeups. I assume the > SIPCORE chairs are now in the same boat, having no email evidence > because a small set of exchanges in the past on SIP and SIPCORE that > anyone is even interested in this document. > > regards > > Keith > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Cullen Jennings >> Sent: Thursday, December 10, 2009 6:14 AM >> To: Brian Hibbard >> Cc: SIPCORE; Kumiko Ono >> Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: >> document scope and intent >> >> >> On Nov 24, 2009, at 2:25 PM, Brian Hibbard wrote: >> >>> The draft states in the first line of the introduction that >> it is not normative for SIP. That raises the question as to >> whether this should be on the standards track. Should this be >> informational or BCP? >> >> I think we decided it need to be standards track when we >> added the normative statements about binary a long time ago. >> (I note that the "should" should be a "SHOULD". >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From brian@estacado.net Thu Jan 7 14:27:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715AE3A685D for ; Thu, 7 Jan 2010 14:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uX3NPKWeB5gN for ; Thu, 7 Jan 2010 14:27:43 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 87D083A684A for ; Thu, 7 Jan 2010 14:27:43 -0800 (PST) Received: from [192.168.1.106] (cpe-76-182-241-151.tx.res.rr.com [76.182.241.151]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o07MQFN7069000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jan 2010 16:26:20 -0600 (CST) (envelope-from brian@estacado.net) Message-Id: <13BA09AF-4045-44E6-831E-353973F946E5@estacado.net> From: Brian Hibbard To: Robert Sparks In-Reply-To: <87933A2E-8DE8-4EA0-8A95-F98ACFB6AFAC@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 7 Jan 2010 16:26:15 -0600 References: <4656101B-A8F8-4EC3-B9D7-D2B01FD824B0@estacado.net> <87933A2E-8DE8-4EA0-8A95-F98ACFB6AFAC@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: document scope and intent X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 22:27:44 -0000 On Dec 9, 2009, at 1:27 PM, Robert Sparks wrote: > > On Nov 24, 2009, at 3:25 PM, Brian Hibbard wrote: > >> >> == Tutorial or Reference == >> >> Is the draft intended to be a hitchhikers' guide to security for >> SIP implementers? > I don't believe so - it was a set of examples. >> >> Does the draft intend to be a training tool to educate implementers >> in PKI? > No. >> How far do we want to go in teaching developers how to generate and >> manage certificates? > Only to the point that it's needed in order to explain what's > happening in the examples. >> For example, are we trying to teach how to administer a Certificate >> Authority and want to deal with how certs are generated in the real >> world? > Very much no. Is something in the draft looking like it does that to > you now? Not the draft itself, but at least one reviewer wanted elaboration on certificate requests and some explanation on how to use the OpenSSL CA tools. I felt that was well beyond the intent of the draft, but I didn't want to squash consensus in the event that I was wrong on that. >> Or are we only concerned with the cryptography of the messages, and >> we are only providing certificates and >> >> Are we only trying to provide specific reference examples for >> helping verify implementations? > The last. >> >> If so, should we be providing test vectors instead? > I think you're focusing only on the crypto generation part of the > draft (it is the hard part you jumped in to help with), but the > examples > frame when what type of security mechanisms get used. Ah yes. I meant all of that to be constrained to the context of PKI within the draft. It didn't help that it looks like I made a copy/ paste error. Basically, the draft is not at all intended to be a PKI tutorial, but some hand-picked crypto examples, nuggets of interop wisdom, and reference certs for interop testing. >> Is the document intending to recommend how things should be done, >> how they might be done, or how they must be done? > The document provides some example flows. It is not intended to be > comprehensive. In some cases it shows the only way > to do a certain thing. In others, it chooses from a range of options. > >> >> == Document Title == >> >> Depending on the resolution of the above, we may need to consider >> changing the document's title. > I don't think we should be changing the document's scope to that > degree at this time. > I appreciate that very much. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From brian@estacado.net Thu Jan 7 15:19:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400073A6767 for ; Thu, 7 Jan 2010 15:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gQ4CNQMmuVi for ; Thu, 7 Jan 2010 15:19:14 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 617FA3A65A5 for ; Thu, 7 Jan 2010 15:19:14 -0800 (PST) Received: from [192.168.1.106] (cpe-76-182-241-151.tx.res.rr.com [76.182.241.151]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o07NHhxx077273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jan 2010 17:17:48 -0600 (CST) (envelope-from brian@estacado.net) Message-Id: <04D70E06-BEFE-45A3-A25D-3FA0076B5CA9@estacado.net> From: Brian Hibbard To: "Vijay K. Gurbani" In-Reply-To: <4B312BEE.9040804@alcatel-lucent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 7 Jan 2010 17:17:43 -0600 References: <4B312BEE.9040804@alcatel-lucent.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] Review of sipcore-sec-flows-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 23:19:16 -0000 Thanks for the input! For all the changes below I find agreeable, I will proceed with the changes unless someone halts and catches fire from objections. -b On Dec 22, 2009, at 2:28 PM, Vijay K. Gurbani wrote: > First off, sorry for the delay in getting this review out. I had > promised to send it shortly after Thanksgiving, but ... > > Second, I believe that this work is of importance to the development > community that can use an additional resource to get a TLS-capable > SIP entity tested and running. > > That said, here are the rest of my comments from my review. > > 1) S1, paragraph 2: > > OLD: > Furthermore, testing at the events is often hampered by trying > to get certificates signed by some common test root into the > appropriate format for various clients. > > NEW: > Furthermore, testing at the events is often hindered due to the > lack of a commonly trusted certificate authority to sign the > certificates used in the events. > Will do. > 2) S1, paragraph 2: The following text > > In addition, this document provides a common certificate and > private key that can be used for a Certificate Authority (CA) > to reduce the time it takes to set up a test at an > interoperability event. > > makes the reader believe that the common certificate and private > key can be used by any CA in the world. This is, of course, > not the intent. The document is providing a common certificate > and the associated private key for the express purpose of creating > a mock CA to sign the certificates for the interoperability events. > > Thus, I would suggest the following paragraph as a substitute for > the above one (please feel free to edit as needed): > > In addition, this document provides a common certificate and > private key that can be used to set up a CA --- a mock CA --- > during the SIP interoperability events. Certificate requests from > the users will be signed by the private key of the mock CA. > Will do. > 3) S1, paragraph 4, last sentence: > s/the same CA certificate/the same mock CA private key/ > Will do. > 4) S1, paragraph 5: > s/list of things implementers/list of items that implementers/ > Will do. > > 5) S1, paragraph 6: > s/A way to make/Scripts and instructions to make/ > s/is presented/are presented/ > Will do. > 6) S3.2, note that the DNS label in the certificate under the SAN > extension is wrong. It should be "DNS:example.com" and not > "DNS:com". > > Also, the example.net certificate suffers from the same problem, > it also contains "DNS:net" in the SAN instead of "DNS:example.net". > THANKS. The script that generates the certs is in somewhat in error. I will repair it and incorporate fresh binaries as infrequently as possible. The binary changes will be some of the last ones I will make before "finalizing" the draft. > 7) S3.3, the sentence "The message could be coming from a host > called atlanta.example.com, and the AOR in the user certificate would > still be the same." adds ambiguity to the text without contributing > much information. Unless there is a specific reason why the reader > needs to know that the SIP message sent over a TLS channel established > by this certificate originated from the host atlanta.example.com, I > would suggest to remove the offending sentence completely. > Will do. > 8) S4.1, paragraph 1: > s/TLSRFC/TLS RFC/ > s/set to example.net/contains example.net > Will do. > 9) S4.1, the ssldump output: should not the second endpoint be > identified as "www.example.net (5061)"? See the very first line > of the ssldump output. > It should. There is a note in the "binary content issues" email I sent regarding that. The tool is doing a reverse lookup, and alas, both domains have the same address in the test environment on my Mac. > 10) S4.2: The first paragraph says that the convention > from rfc4475 is used, however, I do not see the > element in the subsequent example. > I will go see what it takes to incorporate that into the tools that automagically prepare these messages for inclusion in the draft. > 11) S4.2, first open issue: If Contact is not allowed in a MESSAGE > and its corresponding 2xx, simply take it out, no? Taking the > Contact out does not result in any loss of generalization, nor > does it detract from the point the example is trying to make. > I'm happy with that. That Open Issue could really be two separate issues, but, if the real solution were to be that we need to INVITE instead, what we do with MESSAGE would be moot. I just wanted to be sure we have The Right Examples (TM). That said, if there's no further ado, consensus so far is that we stick with MESSAGE and clean it up. > 12) S4.2, second open issue: If you take Contact out of the 200 OK, > then you do not have this problem. The Contact in the 200 OK > contains an IP address that is the same as the one in the top-most > Via header (which is what leads to the confusion in the first > place, I believe. The To and From contain URIs with domain names.) > Will do. > 13) S4.2, third open issue: I am not sure what you are trying to > point out by referencing rfc3263 or connect-reuse here. IMHO, the > section looks fine without referencing rfc3263 or connect-reuse. > I gather more folks are happier with it in there. Feel free to fight amongst yourselves. ;) > 14) S5.1: I would advise being consistent and using > convention everywhere in this draft. As above. > > 15) S5.1, this is a nit, but to be orthogonal to S4.2, it will help > if the message body in S5.1 contained the same message as in > S4.2 (i.e., "Hello!" instead of "hello"). Not a difficult thing to change when I'm fixing the binary-generated content. But that will be later rather than sooner. > > 15) S5.3: I would advise being consistent and using > convention everywhere in this draft. As above. > > 16) S6: First open issue: Cullen has already stated that he and > Kumiko has observed these. In addition, here is a table that contains > the number of TLS implementations since SIPit 16: > > SIPit Unique Number of TLS > No. Implementations implementations Percentage > ---------------------------------------------------- > 16 57 25 44% > 18 73 30 41% > 19 90 41 45% > 20 90 42 46% > 21 70 34 49% > 22 80 50 63% > 23 50 24 48% > 24 43 22 52% > 25 42 16 38% > > Note: (1) 16th SIPit was held in April 2005, 23 SIPit was held in > October 2008. > (2) Data for 16th SIPit is form my private archive > and is not reflected in [1]. > (3) I don't have data for 17th SIPit. > (4) Rest of the table created from data at [1]. > > [1] Robert J. Sparks, SIPit Summaries, archived at > https://www.sipit.net/SIPitSummaries > > In the last 3-4 bakeoffs, there weren't any implementations of > S/MIME. In the earlier bakeoffs, there were very few implementations > of S/MIME. If you want me to compile these for a summary, I can > do so. > Actually, if you want to come up with that summary, I would happily include it in the draft. > 17) S6, second open issue: Does it matter? What is gained by further > categorizing the SIP clients into UAS, UAC, or a proxy? > These came up in another review on this list. I don't know if they had a specific issue in mind, or if they thought it would simply be more informative. > 18) S7, general comment -- some "folklore" is specified in the > domain-certs document > (http://tools.ietf.org/html/draft-ietf-sip-domain-certs-04), which > is with the IESG right now. The domain-certs document should > be cited here as well. > Good, thanks. > 18) S7, second bullet item is normatively specified in domain-certs. > Suggest that a reference to domain-certs be included here for > further reading. > Will do. > 19) S7, third open issue: I believe that IP addresses can appear in > the > SAN (rfc5280 says so.) Their handling is specified in domain-certs (I > believe they will appear as "DNS:192.168.0.1"; we need to have someone > -- from pkix? -- ascertain this. If this is the case, then their > handling is specified in S7.1 of domain-certs.) Ok. We'll need to follow up on this. > > 20) S7: For the test cases in S7, I wonder if it is worth creating > test > certificates issued by the mock CA and including these in the > draft? That way, implementers can simply download the certificates > and use them for their testing. If people think this is a good > idea, I can spend some time doing this. > I'm not sure I follow you. We have host certs already generated and attached in the draft. Are you concerned that the domains they are issued for aren't usable? If so, maybe we should just make those more easily usable and center our examples around them? > 21) S7: last open issue: I think that the case of having one or more > certificates in a path not provided or not available is a good one. > Question is should we provide a certificate signed by a subordinate CA > for testing to implementers or simply discuss this case? This is the third time someone's brought up whether we need a non-root CA. What seems best to me is to give example certs: the root CA we already have, a non-root CA signed by the root CA, and a host cert signed by that non-root CA. I think simply discussing the case should be sufficient, because, truthfully, the most difficult aspect of that case is configuring the TLS implementation library. We haven't dealt with that, and we aren't going to. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From brian@estacado.net Thu Jan 7 15:19:34 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B80E3A67E3 for ; Thu, 7 Jan 2010 15:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MT+p3BJyEeC for ; Thu, 7 Jan 2010 15:19:33 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 664BF3A6405 for ; Thu, 7 Jan 2010 15:19:33 -0800 (PST) Received: from [192.168.1.106] (cpe-76-182-241-151.tx.res.rr.com [76.182.241.151]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o07NHh00077273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jan 2010 17:18:08 -0600 (CST) (envelope-from brian@estacado.net) Message-Id: From: Brian Hibbard To: "Vijay K. Gurbani" In-Reply-To: <4B210DA9.90501@alcatel-lucent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 7 Jan 2010 17:18:08 -0600 References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B210DA9.90501@alcatel-lucent.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 23:19:34 -0000 That sounds good to me. I'll add that to Sec. 8 unless there are objections. On Dec 10, 2009, at 9:03 AM, Vijay K. Gurbani wrote: > Cullen Jennings wrote: >> On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote: >>> From second bullet: What if all you've got is an IP address? Do we >>> disallow IPAddress entries in SubjectAltName? >> Good point - IPAddress are allowed in SubjectAltName AFAIC. I imagine >> that many people did not test this case and may have problems with >> it. > > We can add it as a test case in Section 8. Something along the > lines of: > > 12. TLS : Good peer certificate (CN of Subject empty, and > subjectAltName extension contains an iPAddress stored > in the octet string in network byte order form as > specified in [RFC791].) > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From brian@estacado.net Thu Jan 7 15:19:36 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5103A68BB for ; Thu, 7 Jan 2010 15:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfLXc3ZYOVla for ; Thu, 7 Jan 2010 15:19:35 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 563583A6405 for ; Thu, 7 Jan 2010 15:19:35 -0800 (PST) Received: from [192.168.1.106] (cpe-76-182-241-151.tx.res.rr.com [76.182.241.151]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o07NHh01077273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jan 2010 17:18:12 -0600 (CST) (envelope-from brian@estacado.net) Message-Id: From: Brian Hibbard To: "Vijay K. Gurbani" In-Reply-To: <4B210B1E.3080202@alcatel-lucent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 7 Jan 2010 17:18:12 -0600 References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <72938436-8DE4-4A1C-BE69-4453421C4CC7@cisco.com> <4B210B1E.3080202@alcatel-lucent.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 23:19:36 -0000 If there are no objections, I can go ahead and insert this sans the normative MAY & SHOULD, and add a reference to connection-reuse. Thanks! -b On Dec 10, 2009, at 8:52 AM, Vijay K. Gurbani wrote: > Cullen Jennings wrote: >> On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote: >>> Add a few lines about RFC 3263. Add a few lines about how the UA >>> decides to create a new TLS session or use an existing one (but not >>> "connection-reuse" draft level of reuse complexity). Any volunteers >>> for writing this? >> I can write that if you don't fine some else to do it. How about: >> When a UA goes to send a message to example.com, the UA can see if it >> already has a TLS connection to example.com and if it does, it MAY >> send the message over this connection. A UA SHOULD have some scheme >> for reusing connections as opening a new TLS connection for every >> message results in awful performance. Implementers are encouraged to >> read { add appropriate connection reuse refs here }. > > This is exactly what connect-reuse says, except of course, in > much more detail about how the UA goes on to determine "if it > already has a TLS connection to example.com". I don't mind > putting a capsule summary of the above form in sec-flows, but > we should follow it up with a reference to connect-reuse. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dean.willis@softarmor.com Thu Jan 7 21:37:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487FF3A657C; Thu, 7 Jan 2010 21:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACyJIslQwffO; Thu, 7 Jan 2010 21:37:25 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B01873A67BE; Thu, 7 Jan 2010 21:37:25 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o085bLMV011038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Jan 2010 23:37:23 -0600 Message-Id: From: Dean Willis To: "Paul E. Jones" In-Reply-To: <00d101ca8f15$c91915b0$5b4b4110$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 7 Jan 2010 23:37:16 -0600 References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <4B39AE2C.9090304@softarmor.com> <503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com> <1AA2A44A-3C89-4903-879C-9F74E459C93D@softarmor.com> <4B433B4B.1030407@digium.com> <80D99821-B111-4C94-BC68-536CB65DD15E@softarmor.com> <4B43D7C5.1050306@cisco.com> <004f01ca8eb3$7659d790$630d86b0$@com> <4B44AC4E.4020309@cisco.com> <4B44AE40.2060104@digium.com> <00d101ca8f15$c91915b0$5b4b4110$@com> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] [dispatch] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 05:37:27 -0000 On Jan 6, 2010, at 3:18 PM, Paul E. Jones wrote: > > > Is there any disagreement to presenting this document to the RFC > Editor and > IESG for publication? > No disagreement; it seems harmless enough as a document, and useful as a reference about the problem. Were I in a position of other than (im)moral authority, I might suggest that "Area Director sponsored individual draft on the informational track" is the way to go. No working group needed, no charters, etc. Just get a gullible AD to sign up, and away you go! http://tools.ietf.org/html/draft-iesg-sponsoring-guidelines-02 -- Dean From paulej@packetizer.com Thu Jan 7 21:51:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E706A3A6868; Thu, 7 Jan 2010 21:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qeTSW7hkDSs; Thu, 7 Jan 2010 21:51:51 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id DB0E33A67A3; Thu, 7 Jan 2010 21:51:50 -0800 (PST) Received: from berlin.arid.us (rrcs-98-101-146-143.midsouth.biz.rr.com [98.101.146.143]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o085ph9X014195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jan 2010 00:51:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1262929909; bh=ABtckeAgy2tMiZKQsg18LN35W5TdZSsft6yvEnIkPGI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=aGZq4CRfSembZITza71oKUeLtOYJBVpNIKAHWuDzbJmTYZSSfUl5WCechnk5Bmo3J 6PHydvOF6UAXXAUFr5k+dTiCSA3wTgszDy30ukDKigsInPhQU13D3F1H1K1yEsaWKM NFDsJn2c7DQ6pgfQfvC3NYUKzPx/iGYsICdERSh8= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o085pgg7001531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Jan 2010 00:51:43 -0500 From: "Paul E. Jones" To: "'Dean Willis'" References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <4B39AE2C.9090304@softarmor.com> <503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com> <1AA2A44A-3C89-4903-879C-9F74E459C93D@softarmor.com> <4B433B4B.1030407@digium.com> <80D99821-B111-4C94-BC68-536CB65DD15E@softarmor.com> <4B43D7C5.1050306@cisco.com> <004f01ca8eb3$7659d790$630d86b0$@com> <4B44AC4E.4020309@cisco.com> <4B44AE40.2060104@digium.com> <00d101ca8f15$c91915b0$5b4b4110$@com> In-Reply-To: Date: Fri, 8 Jan 2010 00:51:33 -0500 Message-ID: <02c901ca9026$a26cd980$e7468c80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqQJKvbyZdka4vJRZ28wxnFrJHJgAAAdsSA Content-Language: en-us Cc: dispatch@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] [dispatch] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 05:51:52 -0000 "AD Sponsored submissions represent a significant workload to the IESG." As if Cullen does not have enough to do. Paul > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, January 08, 2010 12:37 AM > To: Paul E. Jones > Cc: dispatch@ietf.org; sipcore@ietf.org > Subject: Re: [dispatch] [sipcore] I-D Action:draft-jones-sip-forum-fax- > problem-statement-00.txt > > > On Jan 6, 2010, at 3:18 PM, Paul E. Jones wrote: > > > > > > Is there any disagreement to presenting this document to the RFC > > Editor and > > IESG for publication? > > > > No disagreement; it seems harmless enough as a document, and useful as > a reference about the problem. Were I in a position of other than > (im)moral authority, I might suggest that "Area Director sponsored > individual draft on the informational track" is the way to go. > > No working group needed, no charters, etc. Just get a gullible AD to > sign up, and away you go! > > http://tools.ietf.org/html/draft-iesg-sponsoring-guidelines-02 > > > > -- > Dean > From dean.willis@softarmor.com Thu Jan 7 22:09:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0E9D3A6869; Thu, 7 Jan 2010 22:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsvihndKC7IA; Thu, 7 Jan 2010 22:09:15 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3E88A3A691B; Thu, 7 Jan 2010 22:09:15 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0869BNa011322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 8 Jan 2010 00:09:13 -0600 Message-Id: <53E8E549-E3C0-4E5C-92A1-B5AC9B06EBC5@softarmor.com> From: Dean Willis To: "Paul E. Jones" In-Reply-To: <02c901ca9026$a26cd980$e7468c80$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 8 Jan 2010 00:09:06 -0600 References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <4B39AE2C.9090304@softarmor.com> <503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com> <1AA2A44A-3C89-4903-879C-9F74E459C93D@softarmor.com> <4B433B4B.1030407@digium.com> <80D99821-B111-4C94-BC68-536CB65DD15E@softarmor.com> <4B43D7C5.1050306@cisco.com> <004f01ca8eb3$7659d790$630d86b0$@com> <4B44AC4E.4020309@cisco.com> <4B44AE40.2060104@digium.com> <00d101ca8f15$c91915b0$5b4b4110$@com> <02c901ca9026$a26cd980$e7468c80$@com> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] [dispatch] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 06:09:17 -0000 On Jan 7, 2010, at 11:51 PM, Paul E. Jones wrote: > "AD Sponsored submissions represent a significant workload to the > IESG." > If the document is well enough drafted that it doesn't create a lot of work for the AD, then there isn't that much extra work. One can also use an external document shepherd to make sure the doc is really "IESG ready" before the AD gets deeply into it. PaulK would be good at this ;-). Besides, Cullen needs more work to do. -- Dean From paulej@packetizer.com Thu Jan 7 22:27:34 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC283A6929; Thu, 7 Jan 2010 22:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2LoNho4RGW0; Thu, 7 Jan 2010 22:27:33 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 692D23A6909; Thu, 7 Jan 2010 22:27:31 -0800 (PST) Received: from berlin.arid.us (rrcs-98-101-146-143.midsouth.biz.rr.com [98.101.146.143]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o086RN3S016477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jan 2010 01:27:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1262932049; bh=xVxqtJVTrlExsWvk+t8d+eS1zc2v6Xp+BlqppRT27uY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=re1UcjPytIiecq9eN0LVLe1Lmqa+AjqYsX6wc8YUWMZ5pb3GnLmVc/Rjf3t2i6OYf m7AB/1LzNrTdpmoasWf+ThLKdBNdsYovzJ+u/MB8/Qgxf02pjZeyAuWOqzDhBn41MD RuDZg2aIwZA/PqM9PRQzOoI67N9h6MN/hPJrujcM= Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o086RNBC001625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Jan 2010 01:27:23 -0500 From: "Paul E. Jones" To: "'Dean Willis'" References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <4B39AE2C.9090304@softarmor.com> <503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com> <1AA2A44A-3C89-4903-879C-9F74E459C93D@softarmor.com> <4B433B4B.1030407@digium.com> <80D99821-B111-4C94-BC68-536CB65DD15E@softarmor.com> <4B43D7C5.1050306@cisco.com> <004f01ca8eb3$7659d790$630d86b0$@com> <4B44AC4E.4020309@cisco.com> <4B44AE40.2060104@digium.com> <00d101ca8f15$c91915b0$5b4b4110$@com> <02c901ca9026$a26cd980$e7468c80$@com> <53E8E549-E3C0-4E5C-92A1-B5AC9B06EBC5@softarmor.com> In-Reply-To: <53E8E549-E3C0-4E5C-92A1-B5AC9B06EBC5@softarmor.com> Date: Fri, 8 Jan 2010 01:27:14 -0500 Message-ID: <02ee01ca902b$9e4e5e50$daeb1af0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqQKR5OtS3WIYYKSyqPQxFfYMmrVQAAjP2A Content-Language: en-us Cc: dispatch@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] [dispatch] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 06:27:35 -0000 Dean said: > > "AD Sponsored submissions represent a significant workload to the > > IESG." > > > > If the document is well enough drafted that it doesn't create a lot of > work for the AD, then there isn't that much extra work. > > One can also use an external document shepherd to make sure the doc is > really "IESG ready" before the AD gets deeply into it. PaulK would be > good at this ;-). > > Besides, Cullen needs more work to do. So, Paul K. and Cullen should each be made aware that you've given them an assignment. They'll thank you at the next meeting. ;-) Paul From oej@edvina.net Fri Jan 8 04:36:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98D33A690D for ; Fri, 8 Jan 2010 04:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imyKA+X+dufH for ; Fri, 8 Jan 2010 04:36:51 -0800 (PST) Received: from smtp5.webway.se (smtp5.webway.se [212.3.14.196]) by core3.amsl.com (Postfix) with ESMTP id 094083A6883 for ; Fri, 8 Jan 2010 04:36:50 -0800 (PST) Received: from smtp6.webway.se (smtp2.webway.se [87.96.134.128]) by smtp5.webway.se (Postfix) with ESMTP id 310A943EE76; Fri, 8 Jan 2010 12:36:48 +0000 (UTC) Received: from [192.168.40.12] (ns.webway.se [87.96.134.125]) by smtp6.webway.se (Postfix) with ESMTPA id 6F0C5552F6F; Fri, 8 Jan 2010 12:37:43 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: Date: Fri, 8 Jan 2010 13:36:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <01DD632E-C839-4965-BB4E-0F063D0871B0@edvina.net> References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B210DA9.90501@alcatel-lucent.com> To: Brian Hibbard X-Mailer: Apple Mail (2.1077) Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 12:36:51 -0000 8 jan 2010 kl. 00.18 skrev Brian Hibbard: > That sounds good to me. I'll add that to Sec. 8 unless there are = objections. >=20 > On Dec 10, 2009, at 9:03 AM, Vijay K. Gurbani wrote: >=20 >> Cullen Jennings wrote: >>> On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote: >>>> =46rom second bullet: What if all you've got is an IP address? Do = we >>>> disallow IPAddress entries in SubjectAltName? >>> Good point - IPAddress are allowed in SubjectAltName AFAIC. I = imagine >>> that many people did not test this case and may have problems with >>> it. >>=20 >> We can add it as a test case in Section 8. Something along the >> lines of: >>=20 >> 12. TLS : Good peer certificate (CN of Subject empty, and >> subjectAltName extension contains an iPAddress stored >> in the octet string in network byte order form as >> specified in [RFC791].) >>=20 During the tests we had at SIPit in New Hampshire we discovered that = without an IP address in the certificate, most TLS scenarious with = record-route/route headers pointing to IP addresses would fail. Either = avoiding IP addresses in record-route/route or having IP address for the = server in the cert are working solutions to this issue.=20 IP in SAN certs is propably the fast way forward, but also gives a = headache in solutions where you have multiple IP addresses in a = "clustered" environment. It just feels wrong to me to have non-DNS data = like IP address within the cert. /O= From pkyzivat@cisco.com Fri Jan 8 06:18:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9D13A6884; Fri, 8 Jan 2010 06:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.253 X-Spam-Level: X-Spam-Status: No, score=-10.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kr-k6sH8imoE; Fri, 8 Jan 2010 06:18:46 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 635E63A6862; Fri, 8 Jan 2010 06:18:46 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACvNRkutJV2b/2dsb2JhbADACJQahC8E X-IronPort-AV: E=Sophos;i="4.49,242,1262563200"; d="scan'208";a="78971218" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 08 Jan 2010 14:18:43 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o08EIhnZ000419; Fri, 8 Jan 2010 14:18:43 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 08:18:43 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 08:18:42 -0600 Message-ID: <4B473EC1.9020404@cisco.com> Date: Fri, 08 Jan 2010 09:18:41 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Paul E. Jones" References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <4B39AE2C.9090304@softarmor.com> <503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com> <1AA2A44A-3C89-4903-879C-9F74E459C93D@softarmor.com> <4B433B4B.1030407@digium.com> <80D99821-B111-4C94-BC68-536CB65DD15E@softarmor.com> <4B43D7C5.1050306@cisco.com> <004f01ca8eb3$7659d790$630d86b0$@com> <4B44AC4E.4020309@cisco.com> <4B44AE40.2060104@digium.com> <00d101ca8f15$c91915b0$5b4b4110$@com> <02c901ca9026$a26cd980$e7468c80$@com> <53E8E549-E3C0-4E5C-92A1-B5AC9B06EBC5@softarmor.com> <02ee01ca902b$9e4e5e50$daeb1af0$@com> In-Reply-To: <02ee01ca902b$9e4e5e50$daeb1af0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2010 14:18:42.0992 (UTC) FILETIME=[7B6AEB00:01CA906D] Cc: dispatch@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] [dispatch] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 14:18:47 -0000 Paul E. Jones wrote: > Dean said: >>> "AD Sponsored submissions represent a significant workload to the >>> IESG." >>> >> If the document is well enough drafted that it doesn't create a lot of >> work for the AD, then there isn't that much extra work. >> >> One can also use an external document shepherd to make sure the doc is >> really "IESG ready" before the AD gets deeply into it. PaulK would be >> good at this ;-). >> >> Besides, Cullen needs more work to do. > > So, Paul K. and Cullen should each be made aware that you've given them an > assignment. They'll thank you at the next meeting. ;-) I'll wait to see if Cullen wants me to take it. And I don't suppose I will thank dean at the next meeting because it seems I don't get to go to meetings any longer. Thanks, Paul From root@core3.amsl.com Fri Jan 8 13:00:01 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E16FD3A686B; Fri, 8 Jan 2010 13:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100108210001.E16FD3A686B@core3.amsl.com> Date: Fri, 8 Jan 2010 13:00:01 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 21:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control Author(s) : A. Niemi, et al. Filename : draft-ietf-sipcore-event-rate-control-02.txt Pages : 23 Date : 2010-01-08 This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 12, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-event-rate-control-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-08125433.I-D@ietf.org> --NextPart-- From krisztian.kiss@nokia.com Sun Jan 10 23:33:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2529A3A6899 for ; Sun, 10 Jan 2010 23:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTW82UXYzoFX for ; Sun, 10 Jan 2010 23:33:04 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id B03243A6869 for ; Sun, 10 Jan 2010 23:33:03 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0B7Wjkv019891 for ; Mon, 11 Jan 2010 09:32:58 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 09:32:45 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 09:32:40 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 11 Jan 2010 08:32:40 +0100 From: To: Date: Mon, 11 Jan 2010 08:32:38 +0100 Thread-Topic: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-02.txt Thread-Index: AcqQpZ4RVSIz+DVETpGErUFgcT+0PwBDfvog Message-ID: References: <20100108210001.E16FD3A686B@core3.amsl.com> In-Reply-To: <20100108210001.E16FD3A686B@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jan 2010 07:32:40.0840 (UTC) FILETIME=[41AEC880:01CA9290] X-Nokia-AV: Clean Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 07:33:05 -0000 As discussed in http://www.ietf.org/mail-archive/web/sipcore/current/msg017= 12.html the below updated version adopts the following proposal: - making the Event header field optional for 2xx to NOTIFY, in a general us= e case, with or without rate control; - for implementations supporting the functionality to update the previously= agreed rate control in a 2xx response to NOTIFY, it's mandatory to support= the inclusion of the Event header field. The authors think this version is ready for WGLC. Cheers, Krisztian -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of ext Internet-Drafts@ietf.org Sent: Friday, January 08, 2010 13:00 To: i-d-announce@ietf.org Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working G= roup of the IETF. Title : Session Initiation Protocol (SIP) Event Notification Ext= ension for Notification Rate Control Author(s) : A. Niemi, et al. Filename : draft-ietf-sipcore-event-rate-control-02.txt Pages : 23 Date : 2010-01-08 This document specifies mechanisms for adjusting the rate of Session Initia= tion Protocol (SIP) event notifications. These mechanisms can be applied i= n subscriptions to all SIP event packages. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provi= sions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Forc= e (IETF), its areas, and its working groups. Note that other groups may al= so distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and m= ay be updated, replaced, or obsoleted by other documents at any time. It i= s inappropriate to use Internet-Drafts as reference material or to cite the= m 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 July 12, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document au= thors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Re= lating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication= of this document. Please review these documents carefully, as they descri= be your rights and restrictions with respect to this document. Code Compon= ents extracted from this document must include Simplified BSD License text = as described in Section 4.e of the Trust Legal Provisions and are provided = without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-0= 2.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. From michael@voip.co.uk Mon Jan 11 02:46:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953883A6918 for ; Mon, 11 Jan 2010 02:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.118 X-Spam-Level: X-Spam-Status: No, score=-4.118 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNcpaoVLxSRU for ; Mon, 11 Jan 2010 02:46:19 -0800 (PST) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by core3.amsl.com (Postfix) with SMTP id 93C7D3A690E for ; Mon, 11 Jan 2010 02:46:19 -0800 (PST) Received: from source ([209.85.216.196]) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKS0sBeSbdQ55LLDT4ouYp6M9q+ZEX+ak4@postini.com; Mon, 11 Jan 2010 02:46:17 PST Received: by mail-px0-f196.google.com with SMTP id 34so12679787pxi.8 for ; Mon, 11 Jan 2010 02:46:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.89.15 with SMTP id r15mr204643rvl.252.1263206777049; Mon, 11 Jan 2010 02:46:17 -0800 (PST) In-Reply-To: References: <20100108210001.E16FD3A686B@core3.amsl.com> Date: Mon, 11 Jan 2010 10:46:16 +0000 Message-ID: From: Michael Procter To: sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 10:46:41 -0000 I have one comment left on this draft, which Sal asked me to raise on-list. Section 6.3 defines how a notifier will pace notifications to ensure they meet with the 'average-interval' specified by the subscriber. I have two problems with defining this. Firstly I don't think we need to define exactly how the average interval must be achieved, and secondly even if I did, I don't think the formula specified is particularly good for various scenarios. If a subscriber has specific timing requirements that it wishes to be met, it can advertise them with min-interval and max-interval. The average-interval should be viewed as no more than a hint for the notifier. Consequently, the notifier should have freedom to achieve an average rate in the way it considers most effective, provided it meets the constraints of min-interval and max-interval. I would prefer that the mechanism for achieving a particular average interval was left to the notifier's discretion and not specified in this document. I would be content if the given formula was described as one way to achieve this and that an implementation may choose a different approach if preferred. Best regards, Michael From adam@nostrum.com Tue Jan 12 08:57:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A121228C0F5 for ; Tue, 12 Jan 2010 08:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0Ap9AB33tFg for ; Tue, 12 Jan 2010 08:57:16 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 76CDA28B56A for ; Tue, 12 Jan 2010 08:57:15 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0CGv8A2020257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2010 10:57:08 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B4CA9E4.3040204@nostrum.com> Date: Tue, 12 Jan 2010 10:57:08 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: SIPCORE Content-Type: multipart/alternative; boundary="------------090209020902070501010008" Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: Robert Sparks Subject: [sipcore] Implementations of draft-ietf-sipcore-199-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 16:57:17 -0000 This is a multi-part message in MIME format. --------------090209020902070501010008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as chair] In order to provide useful information to the IESG in their evaluation of draft-ietf-sipcore-199-02, we would like to get an idea of the level of expected deployment. Please indicate, either publicly on this list or privately to me, if you either: * Currently implement draft-ietf-sipcore-199-02 (or an earlier version of the document), or * Plan to implement draft-ietf-sipcore-199-02 Information sent directly to me will be treated as confidential, and reported to the IESG anonymously (that is, without naming the individual or company). Thanks. /a --------------090209020902070501010008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as chair]

In order to provide useful information to the IESG in their evaluation of draft-ietf-sipcore-199-02, we would like to get an idea of the level of expected deployment. Please indicate, either publicly on this list or privately to me, if you either:

  • Currently implement draft-ietf-sipcore-199-02 (or an earlier version of the document), or
  • Plan to implement draft-ietf-sipcore-199-02

Information sent directly to me will be treated as confidential, and reported to the IESG anonymously (that is, without naming the individual or company). Thanks.

/a
--------------090209020902070501010008-- From rjsparks@nostrum.com Tue Jan 12 09:00:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EF228C107 for ; Tue, 12 Jan 2010 09:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9TgeiLq5VdJ for ; Tue, 12 Jan 2010 09:00:36 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B7CA53A6A60 for ; Tue, 12 Jan 2010 09:00:35 -0800 (PST) Received: from [192.168.2.2] (pool-173-71-49-137.dllstx.fios.verizon.net [173.71.49.137]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0CH0V47020587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 12 Jan 2010 11:00:31 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <05834F8F-DECC-46BC-B621-1EDB2DBC7F48@nostrum.com> From: Robert Sparks To: SIPCORE In-Reply-To: <20091209210002.348C93A6980@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 12 Jan 2010 11:00:30 -0600 References: <20091209210002.348C93A6980@core3.amsl.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 173.71.49.137 is authenticated by a trusted mechanism) Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-199-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 17:00:37 -0000 There are some nits in this version (spelling and long lines), but we can fix those after IETF LC. I'll be issuing the LC request for it shortly. Please consider this an early LC comment: I still find this line objectionable: "When the P-Early-Media header [RFC5009] is used, a UA MAY trigger different actions depending on whether the header has been used for the terminated dialog." I've commented before that this statement is insufficient to inform an implementer at all. I really don't understand why it's here. The other text doesn't preclude different actions if this header is present or not, so it's not relaxing a restriction elsewhere in the document. I think you have the same specification (and less potential confusion) if you delete the sentence. RjS On Dec 9, 2009, at 3:00 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol Core > Working Group of the IETF. > > > Title : Response Code for Indication of Terminated Dialog > Author(s) : C. Holmberg > Filename : draft-ietf-sipcore-199-02.txt > Pages : 16 > Date : 2009-12-09 > > This specification defines a new SIP response code, 199 Early Dialog > Terminated, which a SIP forking proxy and a UAS can use to indicate > upstream towards the UAC that an early dialog has been terminated, > before a final response is sent towards the UAC. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and 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 June 12, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-199-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Tue Jan 12 09:55:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F319E3A6ABE for ; Tue, 12 Jan 2010 09:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdjkmBXZp6xa for ; Tue, 12 Jan 2010 09:55:14 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id EDD383A6ABD for ; Tue, 12 Jan 2010 09:55:13 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-d0-4b4cb77d1690 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id FA.94.04178.D77BC4B4; Tue, 12 Jan 2010 18:55:10 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 12 Jan 2010 18:55:09 +0100 From: Christer Holmberg To: Adam Roach , SIPCORE Date: Tue, 12 Jan 2010 18:50:32 +0100 Thread-Topic: [sipcore] Implementations of draft-ietf-sipcore-199-02 Thread-Index: AcqTqE0XRs2wOz5YSPWYvenpdSI1owAB2/nk Message-ID: References: <4B4CA9E4.3040204@nostrum.com> In-Reply-To: <4B4CA9E4.3040204@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Robert Sparks Subject: Re: [sipcore] Implementations of draft-ietf-sipcore-199-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 17:55:15 -0000 Hi, At least 3GPP has adopted 199 for IMS, and support is mandatory for UAs (th= ose which support the INVITE method) and S-CSCFs. In addition, it can be us= ed by application servers providing anouncement services using the "forking= model" (a dedicated early dialog is established between the UA and AS). Exactly when it will be implemented and deployed by various vendors and ope= rators I can't say, but at least from my personal experience there is inter= est for it. Regards, Christer ________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Adam= Roach [adam@nostrum.com] Sent: Tuesday, January 12, 2010 6:57 PM To: SIPCORE Cc: Robert Sparks Subject: [sipcore] Implementations of draft-ietf-sipcore-199-02 [as chair] In order to provide useful information to the IESG in their evaluation of d= raft-ietf-sipcore-199-02, we would like to get an idea of the level of expe= cted deployment. Please indicate, either publicly on this list or privately= to me, if you either: * Currently implement draft-ietf-sipcore-199-02 (or an earlier version o= f the document), or * Plan to implement draft-ietf-sipcore-199-02 Information sent directly to me will be treated as confidential, and report= ed to the IESG anonymously (that is, without naming the individual or compa= ny). Thanks. /a From christer.holmberg@ericsson.com Tue Jan 12 10:06:07 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE3E3A68D1 for ; Tue, 12 Jan 2010 10:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2C+pxHPzTV9 for ; Tue, 12 Jan 2010 10:06:05 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 55E0D3A6821 for ; Tue, 12 Jan 2010 10:06:03 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-8c-4b4cba078632 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id E9.85.04178.70ABC4B4; Tue, 12 Jan 2010 19:05:59 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 12 Jan 2010 19:05:59 +0100 From: Christer Holmberg To: Robert Sparks , SIPCORE Date: Tue, 12 Jan 2010 19:04:45 +0100 Thread-Topic: [sipcore] I-D Action:draft-ietf-sipcore-199-02.txt Thread-Index: AcqTqM1ezW7WWjjWSc6deS/uDo4d+QACOviF Message-ID: References: <20091209210002.348C93A6980@core3.amsl.com>, <05834F8F-DECC-46BC-B621-1EDB2DBC7F48@nostrum.com> In-Reply-To: <05834F8F-DECC-46BC-B621-1EDB2DBC7F48@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-199-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 18:06:07 -0000 Hi, >There are some nits in this version (spelling and long lines), but we >can fix those after IETF LC. >I'll be issuing the LC request for it shortly. > >Please consider this an early LC comment: >I still find this line objectionable: > >"When the P-Early-Media header [RFC5009] is used, a UA MAY trigger >different actions depending on whether the header has been used for the te= rminated >dialog." > >I've commented before that this statement is insufficient to inform an >implementer at all. I really don't understand why it's here. The other tex= t doesn't >preclude different actions if this header is present or not, so it's not r= elaxing a restriction >elsewhere in the document. >I think you have the same specification (and less potential confusion) >if you delete the sentence. I agree. I'll remove it. Thanks for the comment! Regards, Christer On Dec 9, 2009, at 3:00 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol Core > Working Group of the IETF. > > > Title : Response Code for Indication of Terminated Dialog > Author(s) : C. Holmberg > Filename : draft-ietf-sipcore-199-02.txt > Pages : 16 > Date : 2009-12-09 > > This specification defines a new SIP response code, 199 Early Dialog > Terminated, which a SIP forking proxy and a UAS can use to indicate > upstream towards the UAC that an early dialog has been terminated, > before a final response is sent towards the UAC. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and 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 June 12, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-199-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From christer.holmberg@ericsson.com Tue Jan 12 12:45:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5553A68A0 for ; Tue, 12 Jan 2010 12:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.142 X-Spam-Level: X-Spam-Status: No, score=-6.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN-mCu6Dm-z9 for ; Tue, 12 Jan 2010 12:45:16 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 15ABD3A68C1 for ; Tue, 12 Jan 2010 12:45:15 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-22-4b4cdf57fda5 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 0F.EE.04178.75FDC4B4; Tue, 12 Jan 2010 21:45:11 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 12 Jan 2010 21:45:11 +0100 From: Christer Holmberg To: "'Elwell, John'" , Gonzalo Camarillo , SIPCORE Date: Tue, 12 Jan 2010 21:45:10 +0100 Thread-Topic: [sipcore] WGLC draft-ietf-sipcore-info-events-03.txt Thread-Index: AcqEhCRkkOVAI0ztTsmH2JGjHBGiEAKh285QASzVBFA= Message-ID: References: <4B20DDCF.9000409@ericsson.com> <4B2A4717.5090100@ericsson.com> <4B3342C8.8090400@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] WGLC draft-ietf-sipcore-info-events-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 20:45:17 -0000 Hi John,=20 ---------------- >1. The last paragraph of section 1 seems to be redundant (the same text ap= pears in section 2). Personally I think it is useful to have the text in both places, but I can = remove it from section 1 if nobody objects. ---------------- >2. In section 3.2.1: >" An INFO request can be associated with an Info Package (see X), or > associated with a legacy INFO usage (see Y)." >What are "X" and "Y"? X =3D Reference to section 4. Y =3D Reference to section 9. I'll fix that. ---------------- >3. In section 3.2.1: >" A UA MUST NOT use the INFO method outside an invite dialog usage. > UAs indicate, per-dialog basis, for which Info Packages they are > willing to receive INFO requests. The set of Info Packages cannot > automatically be used within other dialogs." >This mixing up the contexts of sending and receiving INFO requests, and al= so strays into subject matter that is the concern of section 4. It could be= neficially be shortened to: > >"A UA MUST NOT send an INFO request outside an invite dialog usage and MUS= T NOT send an INFO request for an Info Package if the remote UA on that dia= log has not indicated willingness to receive that=20 >Info-Package." Looks good. I'll fix that. ---------------- >4. In 3.2.2: >" If a UA receives an INFO request associated with an Info Package, and > the message body part associated with the Info Package contains a > message body MIME type that the UA support, but which usage is not > defined for the specific Info Package, it is RECOMMENDED that the UA > sends a 415 (Unsupported Media Type) response. >The wording isn't quite right, and in particular the received message body= part is NOT associated with the Info Package - although I guess if it has = Content-Disposition Info-Package it is kind of linked=20 >to the Info Package, but this Content-Disposition value is not introduced = until 3.3.1. I think it should say (also fixing some other nits): > >"If a UA receives an INFO request associated with an Info Package and the = message body part with Content-Disposition 'Info-Package' (see 3.3.1) has a= MIME type that the UA supports but not in the context=20 >of that Info Package, it is RECOMMENDED that the UA send a 415 (Unsupporte= d Media Type) response." Yes. I'll fix that. ---------------- >5. In 3.3.1: >"UAs MUST conform to [RFC5621] to support multipart body parts." >Is this intending to say: >"UAs MUST support multipart body parts in accordance with [RFC5621]" >or >"UAs that need to use multipart body parts MUST do so in accordance with [= RFC5621]"? >I suspect the first interpretation is intended, but a reader could interpr= et it either way. Yes, the first interpretation is correct. I'll fix it according to the text= you suggest. ---------------- >6. In 3.3.1: >"NOTE: Some SIP functions that are orthogonal to INFO can insert body part= s unrelated to the Info Package." >I am not sure a reader would understand this. Also, for legacy usage, a bo= dy part could be related to INFO (i.e., not "orthogonal") but not related t= o any Info Package. A possible improvement would be: > >"NOTE: An INFO request can also contain other body parts that are meaningf= ul within the context of an invite dialog usage but are not specifically as= sociated with the INFO method and the application=20 >concerned." I think the text was provided by Paul, but I think the text you suggest is = more clear, so I'll fix it according to that. I doubt Paul will mind :) ---------------- >7. In 4.2.2: >"A UA can an empty Recv-Info header field" >A verb is missing here - should it be "A UA can use an empty Recv-Info hea= der field"? Yes. I'll fix that. ---------------- >8. In 4.2.2: >"or that that the UA wishes to only receive INFO request for one of the In= fo Packages." >Change "request" to "requests". I'll fix that. ---------------- >9. In 7.3: >"or other user plane data transport mechanisms" > >For consistency with 7.4.2, should "user plane" be "media plane"? Yes. I'll fix that. ---------------- >10. In 7.4.2.1: >"...and there is no need for the SIP signaling intermediates routing to ex= amine the information..." >This does not make sense. I think the word "routing" should be dropped, an= d perhaps change "intermediates" to "intermediaries". Yes. I'll use "intermediaries". ---------------- >11. In 7.4.3: >"Another alternative is to use a totally externally signaled channel, such= as HTTP [RFC2616]." >I don't know what "a totally externally signaled channel" means - perhaps = it should say "a SIP-independent mechanism". Yes. I'll fix that. ---------------- >12. In 8.1: >"This section describes the syntax extensions required for the INFO method= ." >Two problems. Firstly, the syntax extensions are not in this section (8.1)= , they are in 8.2. Yes, but chapter 8.1 gives a generic description of chapter 8. >Secondly, 8.2 also defines syntax for Recv-Info, which is not part of the = INFO method as such. I can add "...and the Recv-Info header field" to the sentence above. ---------------- >13. In 10.1: >"if applications associated with the Info Package requires it" >Change "requires" to "require". I'll fix that. ---------------- >14: In 10.1: >" Section 7.4 describes alternative mechanisms, which should be > considered as part of the process for solving a specific use-case, > when for transporting application information." >"when for" does not make sense. I suspect it should say "when there is a n= eed for". Yes. I'll fix that. ---------------- >15. In 10.3: >"overlap description" - change to "overall description". I'll fix that. ---------------- >16. In 10.4: >"to be identify" - change to "to identify". I'll fix that. ---------------- Thank You very much for the comments! In addition, I've been asked to do the following fixes (thanks to Arun Arun= achalam for providing them): ---------------- 17. In 3.2.1: Change: "The construction of the INFO request is the same as any other request with= in an existing invite dialog usage." ...to: "The construction of the INFO request is the same as any other non-target r= efresh request within an existing invite dialog usage as described in Secti= on 12.2 of RFC 3261." If nobody objects, I'll do that change. ---------------- 18. In 5.1: Change: "Proxy-Authenticate 401 m Proxy-Authenticate 407 o" ..to: "Proxy-Authenticate 401 o Proxy-Authenticate 407 m" If nobody objects, I'll do that change. ---------------- 19. In 12.1.2: "The UAS sends a 200 (OK) response back to the UAC, where the UAS indicates that it is willing to receive INFO requests for Info Packages R." Modify to "Packages R, T". If nobody objects, I'll do that change. ---------------- 20. In 6.1: >Can a proxy add / modify / delete the Recv-Info or Info-package? > > From my understanding of the draft, the answer is no since these header= s are typically > processed by the endpoints. It will be helpful to add the "proxy" colum= n and set the=20 > value to "blank" (similar to Accept header in Section 20.1 of RFC 3261)= . If nobody objects, I'll do that change. ---------------- 21. Proxy processing of INFO requests >It will be helpful to explicitly mention the proxy behavior of INFO reques= ts i.e. add content >similar to SUBSCRIBE request handling in Section 3.1.5 of RFC 3265 Since INFO is a mid-dialog request, there is no need to talk about record-r= outing. The only text I can think of is: "Proxies need no additional behavior beyond that described in RFC3261 to su= pport INFO." I can add a new section (3.2.3) if people think it's needed. ---------------- Regards, Christer From Martin.Thomson@andrew.com Tue Jan 12 14:58:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 926523A6877 for ; Tue, 12 Jan 2010 14:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNJ+mpdylhB4 for ; Tue, 12 Jan 2010 14:58:22 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 6AAD43A6878 for ; Tue, 12 Jan 2010 14:58:22 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:5278 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S8331768Ab0ALW6T (ORCPT ); Tue, 12 Jan 2010 16:58:19 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 12 Jan 2010 16:58:19 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 13 Jan 2010 06:58:17 +0800 From: "Thomson, Martin" To: "krisztian.kiss@nokia.com" , "sipcore@ietf.org" Date: Wed, 13 Jan 2010 06:59:19 +0800 Thread-Topic: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-02.txt Thread-Index: AcqQpZ4RVSIz+DVETpGErUFgcT+0PwBDfvogAIlXhiA= Message-ID: <8B0A9FCBB9832F43971E38010638454F032E44CB7B@SISPE7MB1.commscope.com> References: <20100108210001.E16FD3A686B@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 22:58:23 -0000 VGhlIGRvY3VtZW50IGlzIGZpdCB0byBnbyB0byB0aGUgSUVTRywgd2l0aCB0d28gbWlub3IgZXhj ZXB0aW9ucy4NCg0KU2VjdGlvbiA2LjM6DQogICAgICBbT1BFTiBJU1NVRV0gSXMgdGhlIHBlcmlv ZCB2YWx1ZSBzb21ldGhpbmcgd2Ugc2hvdWxkIGJlIGFibGUgdG8NCiAgICAgIHR1bmUsIG9yIHdl IGNhbiBzaW1wbHkgc3BlY2lmeSBhIHJlYXNvbmFibGUgcGVyaW9kPw0KDQpTaG91bGQgdGhpcyBp c3N1ZSBiZSByZW1vdmVkIG5vdz8NCg0KU2VjdGlvbiA4LjM6IE9MRDoNCiAgIHJlc3BvbnNlIHRv IGEgTk9USUZZIHJlcXVlc3QuICBJbXBsZW1lbnRhdGlvbnMgc3VwcG9ydGluZyB0aGUNCiAgIGZ1 bmN0aW9uYWxpdHkgdG8gdXBkYXRlIHRoZSBwcmV2aW91c2x5IGFncmVlZCBtaW5pbXVtLCBtYXhp bXVtIG9yDQogICBhdmVyYWdlIHJhdGUgb2Ygbm90aWZpY2F0aW9ucyBpbiBhIDIwMC1jbGFzcyBy ZXNwb25zZSB0byB0aGUgTk9USUZZDQogICByZXF1ZXN0IE1VU1Qgc3VwcG9ydCB0aGUgaW5jbHVz aW9uIG9mIHRoZSBFdmVudCBoZWFkZXIgZmllbGQuDQpORVc6DQogICByZXNwb25zZSB0byBhIE5P VElGWSByZXF1ZXN0LiAgQSBVQSB0aGF0IHdpc2hlcyB0byB1cGRhdGUgdGhlIHZhbHVlDQogICBm b3IgbWluaW11bSwgbWF4aW11bSBvciBhdmVyYWdlIHJhdGUgb2Ygbm90aWZpY2F0aW9ucyBjYW4g ZG8gc28gYnkNCiAgIGluY2x1ZGluZyBhbGwgZGVzaXJlZCB2YWx1ZXMgZm9yIHRoZSByYXRlIGNv bnRyb2wgcGFyYW1ldGVycyBpbiBhbiANCiAgIEV2ZW50IGhlYWRlciBpbiB0aGUgMjAwLWNsYXNz IHJlc3BvbnNlIHRvIGEgTk9USUZZIHJlcXVlc3QuDQoNClRoZSBjaGFuZ2VkIHRleHQgZGlkbid0 IGluY2x1ZGUgdGhlIG1vc3QgaW1wb3J0YW50IGFzcGVjdCBvZiB0aGlzIHRleHQgLSB3aGljaCBp cyB0aGF0IHRoZSBfcGFyYW1ldGVyc18gYXJlIGluY2x1ZGVkLiAgTm90ZSB0aGF0IHRoZXJlIGlz IG5vIG5vcm1hdGl2ZSByZXF1aXJlbWVudCBpbiBteSByZXBsYWNlbWVudCAtIGludGVyb3BlcmFi aWxpdHkgaXMgbm90IGhhcm1lZCBieSB0aGUgb21pc3Npb24gb2YgdGhlIGhlYWRlciwgb3IgZXZl biB0aGUgcGFyYW1ldGVycy4NCg0KLS1NYXJ0aW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJv dW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBrcmlzenRpYW4ua2lzc0Bub2tpYS5jb20N Cj4gU2VudDogTW9uZGF5LCAxMSBKYW51YXJ5IDIwMTAgNjozMyBQTQ0KPiBUbzogc2lwY29yZUBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1z aXBjb3JlLWV2ZW50LXJhdGUtDQo+IGNvbnRyb2wtMDIudHh0DQo+IA0KPiBBcyBkaXNjdXNzZWQg aW4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLQ0KPiBhcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJl bnQvbXNnMDE3MTIuaHRtbCB0aGUgYmVsb3cgdXBkYXRlZCB2ZXJzaW9uDQo+IGFkb3B0cyB0aGUg Zm9sbG93aW5nIHByb3Bvc2FsOg0KPiAtIG1ha2luZyB0aGUgRXZlbnQgaGVhZGVyIGZpZWxkIG9w dGlvbmFsIGZvciAyeHggdG8gTk9USUZZLCBpbiBhDQo+IGdlbmVyYWwgdXNlIGNhc2UsIHdpdGgg b3Igd2l0aG91dCByYXRlIGNvbnRyb2w7DQo+IC0gZm9yIGltcGxlbWVudGF0aW9ucyBzdXBwb3J0 aW5nIHRoZSBmdW5jdGlvbmFsaXR5IHRvIHVwZGF0ZSB0aGUNCj4gcHJldmlvdXNseSBhZ3JlZWQg cmF0ZSBjb250cm9sIGluIGEgMnh4IHJlc3BvbnNlIHRvIE5PVElGWSwgaXQncw0KPiBtYW5kYXRv cnkgdG8gc3VwcG9ydCB0aGUgaW5jbHVzaW9uIG9mIHRoZSBFdmVudCBoZWFkZXIgZmllbGQuDQo+ IA0KPiBUaGUgYXV0aG9ycyB0aGluayB0aGlzIHZlcnNpb24gaXMgcmVhZHkgZm9yIFdHTEMuDQo+ IA0KPiBDaGVlcnMsDQo+IEtyaXN6dGlhbg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwY29yZS1ib3Vu Y2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgZXh0IEludGVybmV0LURyYWZ0c0BpZXRmLm9y Zw0KPiBTZW50OiBGcmlkYXksIEphbnVhcnkgMDgsIDIwMTAgMTM6MDANCj4gVG86IGktZC1hbm5v dW5jZUBpZXRmLm9yZw0KPiBDYzogc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbc2lwY29y ZV0gSS1EIEFjdGlvbjpkcmFmdC1pZXRmLXNpcGNvcmUtZXZlbnQtcmF0ZS1jb250cm9sLQ0KPiAw Mi50eHQNCj4gDQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBv bi1saW5lIEludGVybmV0LURyYWZ0cw0KPiBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBh IHdvcmsgaXRlbSBvZiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIENvcmUNCj4gV29y a2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4gDQo+IA0KPiAJVGl0bGUgICAgICAgICAgIDogU2Vz c2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIEV2ZW50DQo+IE5vdGlmaWNhdGlvbiBFeHRl bnNpb24gZm9yIE5vdGlmaWNhdGlvbiBSYXRlIENvbnRyb2wNCj4gCUF1dGhvcihzKSAgICAgICA6 IEEuIE5pZW1pLCBldCBhbC4NCj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtc2lwY29y ZS1ldmVudC1yYXRlLWNvbnRyb2wtMDIudHh0DQo+IAlQYWdlcyAgICAgICAgICAgOiAyMw0KPiAJ RGF0ZSAgICAgICAgICAgIDogMjAxMC0wMS0wOA0KPiANCj4gVGhpcyBkb2N1bWVudCBzcGVjaWZp ZXMgbWVjaGFuaXNtcyBmb3IgYWRqdXN0aW5nIHRoZSByYXRlIG9mIFNlc3Npb24NCj4gSW5pdGlh dGlvbiBQcm90b2NvbCAoU0lQKSBldmVudCBub3RpZmljYXRpb25zLiAgVGhlc2UgbWVjaGFuaXNt cyBjYW4gYmUNCj4gYXBwbGllZCBpbiBzdWJzY3JpcHRpb25zIHRvIGFsbCBTSVAgZXZlbnQgcGFj a2FnZXMuDQo+IA0KPiBTdGF0dXMgb2YgdGhpcyBNZW1vDQo+IA0KPiBUaGlzIEludGVybmV0LURy YWZ0IGlzIHN1Ym1pdHRlZCB0byBJRVRGIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUNCj4g cHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4NCj4gDQo+IEludGVybmV0LURyYWZ0cyBh cmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sNCj4g Rm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRo YXQgb3RoZXINCj4gZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMg YXMgSW50ZXJuZXQtIERyYWZ0cy4NCj4gDQo+IEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9j dW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KPiBhbmQgbWF5IGJlIHVw ZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0K PiB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJl ZmVyZW5jZSBtYXRlcmlhbA0KPiBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBp biBwcm9ncmVzcy4iDQo+IA0KPiBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBj YW4gYmUgYWNjZXNzZWQgYXQNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFj dHMudHh0Lg0KPiANCj4gVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9y aWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KPiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s Lg0KPiANCj4gVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKdWx5IDEyLCAyMDEw Lg0KPiANCj4gQ29weXJpZ2h0IE5vdGljZQ0KPiANCj4gQ29weXJpZ2h0IChjKSAyMDEwIElFVEYg VHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDQo+IGRvY3VtZW50IGF1dGhv cnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLg0KPiANCj4gVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0 IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbA0KPiBQcm92aXNpb25zIFJlbGF0 aW5nIHRvIElFVEYgRG9jdW1lbnRzDQo+IChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNl LWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZg0KPiBwdWJsaWNhdGlvbiBvZiB0aGlzIGRv Y3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMgY2FyZWZ1bGx5LA0KPiBhcyB0 aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0IHRv IHRoaXMNCj4gZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBk b2N1bWVudCBtdXN0IGluY2x1ZGUNCj4gU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZiB0aGUgVHJ1c3QNCj4gTGVnYWwgUHJvdmlzaW9ucyBh bmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMgZGVzY3JpYmVkIGluIHRoZQ0KPiBC U0QgTGljZW5zZS4NCj4gDQo+IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPiBo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNpcGNvcmUtZXZl bnQtcmF0ZS0NCj4gY29udHJvbC0wMi50eHQNCj4gDQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy8NCj4gDQo+IEJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxl IGEgTUlNRSBjb21wbGlhbnQgbWFpbCByZWFkZXINCj4gaW1wbGVtZW50YXRpb24gdG8gYXV0b21h dGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGUNCj4gSW50ZXJuZXQtRHJh ZnQuDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo= From gao.yang2@zte.com.cn Tue Jan 12 18:18:07 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95113A68BD for ; Tue, 12 Jan 2010 18:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.136 X-Spam-Level: X-Spam-Status: No, score=-91.136 tagged_above=-999 required=5 tests=[AWL=1.653, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-BTQf2qpaqF for ; Tue, 12 Jan 2010 18:18:06 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 18FA93A6778 for ; Tue, 12 Jan 2010 18:18:04 -0800 (PST) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91101727820181; Wed, 13 Jan 2010 09:52:20 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 75400.5581017173; Wed, 13 Jan 2010 10:17:57 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o0D2Hpua036471; Wed, 13 Jan 2010 10:17:51 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4B4CA9E4.3040204@nostrum.com> To: Adam Roach MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 13 Jan 2010 10:16:46 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-01-13 10:17:49, Serialize complete at 2010-01-13 10:17:49 Content-Type: multipart/alternative; boundary="=_alternative 000C9CA5482576AA_=" X-MAIL: mse2.zte.com.cn o0D2Hpua036471 Cc: Robert Sparks , SIPCORE Subject: [sipcore] =?gb2312?b?tPC4tDogIEltcGxlbWVudGF0aW9ucyBvZiBkcmFmdC1p?= =?gb2312?b?ZXRmLXNpcGNvcmUtMTk5LTAy?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 02:18:07 -0000 This is a multipart message in MIME format. --=_alternative 000C9CA5482576AA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 V2lyZWxlc3MgYWNjZXNzIHVzdWFsbHkgbmVlZCByZWFzb3VyY2UgcmVzZXJ2YXRpb24gbWVjaGFu aXNtIHRvIGd1YXJhbnRlZSANClFvUy4gSW4gdGhpcyBraW5kIG9mIGFjY2VzcyBlbnZpcm9tZW50 LCBpdCBpcyBtZWFuaW5nZnVsIHRvIHRlcm1pbmF0ZSANCnVudXNlZnVsIGRpYWxvZyBhbmQgaXRz IHJlc2VydmVkIHJlYXNvdXJjZS4NCg0KQW5kIHdoZW4gd2UgZGlkIHRoZSBlbmhhbmNlbWVudCBv ZiBvdXIgZXF1aXBtZW50J3MgZm9ya2luZyBjYXBhYmlsaXR5LCB3ZSANCmNvbnNpZGVyZWQgdGhl IHBsYW5uaW5nIG9mIDE5OS4gU28sIHdlIGFyZSBpbiB0aGUgdHJhY2sgb2YgIlBsYW4gdG8gDQpp bXBsZW1lbnQgZHJhZnQtaWV0Zi1zaXBjb3JlLTE5OS0wMiIuDQoNCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDogODcyMTENCiBU ZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNu DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KQWRhbSBSb2FjaCA8 YWRhbUBub3N0cnVtLmNvbT4gDQq3orz+yMs6ICBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCjIw MTAtMDEtMTMgMDA6NTcNCg0KytW8/sjLDQpTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0Ks63L zQ0KUm9iZXJ0IFNwYXJrcyA8UmpTQG5vc3RydW0uY29tPg0K1vfM4g0KW3NpcGNvcmVdIEltcGxl bWVudGF0aW9ucyBvZiBkcmFmdC1pZXRmLXNpcGNvcmUtMTk5LTAyDQoNCg0KDQoNCg0KDQpbYXMg Y2hhaXJdDQoNCkluIG9yZGVyIHRvIHByb3ZpZGUgdXNlZnVsIGluZm9ybWF0aW9uIHRvIHRoZSBJ RVNHIGluIHRoZWlyIGV2YWx1YXRpb24gb2YgDQpkcmFmdC1pZXRmLXNpcGNvcmUtMTk5LTAyLCB3 ZSB3b3VsZCBsaWtlIHRvIGdldCBhbiBpZGVhIG9mIHRoZSBsZXZlbCBvZiANCmV4cGVjdGVkIGRl cGxveW1lbnQuIFBsZWFzZSBpbmRpY2F0ZSwgZWl0aGVyIHB1YmxpY2x5IG9uIHRoaXMgbGlzdCBv ciANCnByaXZhdGVseSB0byBtZSwgaWYgeW91IGVpdGhlcjoNCg0KQ3VycmVudGx5IGltcGxlbWVu dCBkcmFmdC1pZXRmLXNpcGNvcmUtMTk5LTAyIChvciBhbiBlYXJsaWVyIHZlcnNpb24gb2YgDQp0 aGUgZG9jdW1lbnQpLCBvcg0KUGxhbiB0byBpbXBsZW1lbnQgZHJhZnQtaWV0Zi1zaXBjb3JlLTE5 OS0wMg0KDQpJbmZvcm1hdGlvbiBzZW50IGRpcmVjdGx5IHRvIG1lIHdpbGwgYmUgdHJlYXRlZCBh cyBjb25maWRlbnRpYWwsIGFuZCANCnJlcG9ydGVkIHRvIHRoZSBJRVNHIGFub255bW91c2x5ICh0 aGF0IGlzLCB3aXRob3V0IG5hbWluZyB0aGUgaW5kaXZpZHVhbCANCm9yIGNvbXBhbnkpLiBUaGFu a3MuDQoNCi9hX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlz IHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwg Y29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJl IG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBk aXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRo aXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRp YWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVz c2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRo ZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2 aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 000C9CA5482576AA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldpcmVsZXNzIGFjY2VzcyB1c3Vh bGx5IG5lZWQgcmVhc291cmNlDQpyZXNlcnZhdGlvbiBtZWNoYW5pc20gdG8gZ3VhcmFudGVlIFFv Uy4gSW4gdGhpcyBraW5kIG9mIGFjY2VzcyBlbnZpcm9tZW50LA0KaXQgaXMgbWVhbmluZ2Z1bCB0 byB0ZXJtaW5hdGUgdW51c2VmdWwgZGlhbG9nIGFuZCBpdHMgcmVzZXJ2ZWQgcmVhc291cmNlLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QW5kIHdoZW4g d2UgZGlkIHRoZSBlbmhhbmNlbWVudCBvZiBvdXINCmVxdWlwbWVudCdzIGZvcmtpbmcgY2FwYWJp bGl0eSwgd2UgY29uc2lkZXJlZCB0aGUgcGxhbm5pbmcgb2YgMTk5LiBTbywNCndlIGFyZSBpbiB0 aGUgdHJhY2sgb2YgJnF1b3Q7UGxhbiB0byBpbXBsZW1lbnQgZHJhZnQtaWV0Zi1zaXBjb3JlLTE5 OS0wMiZxdW90Oy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsg Jm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIg Jm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5j b20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxi cj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg d2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5BZGFtIFJvYWNoICZs dDthZGFtQG5vc3RydW0uY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2Zv bnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC0wMS0xMyAwMDo1Nzwv Zm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5T SVBDT1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63L zTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Um9iZXJ0 IFNwYXJrcyAmbHQ7UmpTQG5vc3RydW0uY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W3NpcGNv cmVdIEltcGxlbWVudGF0aW9ucyBvZiBkcmFmdC1pZXRmLXNpcGNvcmUtMTk5LTAyPC9mb250Pjwv dGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxl Pg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPlthcyBjaGFpcl08 YnI+DQo8YnI+DQpJbiBvcmRlciB0byBwcm92aWRlIHVzZWZ1bCBpbmZvcm1hdGlvbiB0byB0aGUg SUVTRyBpbiB0aGVpciBldmFsdWF0aW9uDQpvZiBkcmFmdC1pZXRmLXNpcGNvcmUtMTk5LTAyLCB3 ZSB3b3VsZCBsaWtlIHRvIGdldCBhbiBpZGVhIG9mIHRoZSBsZXZlbA0Kb2YgZXhwZWN0ZWQgZGVw bG95bWVudC4gUGxlYXNlIGluZGljYXRlLCBlaXRoZXIgcHVibGljbHkgb24gdGhpcyBsaXN0IG9y DQpwcml2YXRlbHkgdG8gbWUsIGlmIHlvdSBlaXRoZXI6PGJyPg0KPC9mb250Pg0KPHVsPg0KPGxp Pjxmb250IHNpemU9Mz5DdXJyZW50bHkgaW1wbGVtZW50IGRyYWZ0LWlldGYtc2lwY29yZS0xOTkt MDIgKG9yIGFuIGVhcmxpZXINCnZlcnNpb24gb2YgdGhlIGRvY3VtZW50KSwgb3I8L2ZvbnQ+DQo8 bGk+PGZvbnQgc2l6ZT0zPlBsYW4gdG8gaW1wbGVtZW50IGRyYWZ0LWlldGYtc2lwY29yZS0xOTkt MDI8L2ZvbnQ+PC91bD48Zm9udCBzaXplPTM+PGJyPg0KSW5mb3JtYXRpb24gc2VudCBkaXJlY3Rs eSB0byBtZSB3aWxsIGJlIHRyZWF0ZWQgYXMgY29uZmlkZW50aWFsLCBhbmQgcmVwb3J0ZWQNCnRv IHRoZSBJRVNHIGFub255bW91c2x5ICh0aGF0IGlzLCB3aXRob3V0IG5hbWluZyB0aGUgaW5kaXZp ZHVhbCBvciBjb21wYW55KS4NClRoYW5rcy48YnI+DQo8YnI+DQovYTwvZm9udD48Zm9udCBzaXpl PTI+PHR0Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQpzaXBjb3JlQGlldGYub3JnPGJyPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPGJyPg0KPC90dD48L2ZvbnQ+ DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5i c3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7 aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkm bmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1Ro aXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFs LiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2Js aWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDth cmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhl Jm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtm aWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29u ZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJz cDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZu YnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRy ZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlz Jm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5i c3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJz cDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21l c3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNw O3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5 Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 000C9CA5482576AA_=-- From gao.yang2@zte.com.cn Tue Jan 12 18:39:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98FD13A68E1 for ; Tue, 12 Jan 2010 18:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.088 X-Spam-Level: X-Spam-Status: No, score=-91.088 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FSoziydzHyV for ; Tue, 12 Jan 2010 18:39:47 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 4C0D93A6778 for ; Tue, 12 Jan 2010 18:39:45 -0800 (PST) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91101727820181; Wed, 13 Jan 2010 10:14:06 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 75400.7190980736; Wed, 13 Jan 2010 10:39:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o0D2dcUw051649; Wed, 13 Jan 2010 10:39:38 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: Christer Holmberg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 13 Jan 2010 10:38:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-01-13 10:39:36, Serialize complete at 2010-01-13 10:39:36 Content-Type: multipart/alternative; boundary="=_alternative 000E9B24482576AA_=" X-MAIL: mse2.zte.com.cn o0D2dcUw051649 Cc: Robert Sparks , SIPCORE Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBJbXBsZW1lbnRhdGlvbnMgb2YgZHJh?= =?gb2312?b?ZnQtaWV0Zi1zaXBjb3JlLTE5OS0wMg==?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 02:39:48 -0000 This is a multipart message in MIME format. --=_alternative 000E9B24482576AA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SXQgaXMgcmVhbGx5IG1lYW5pbmcgZm9yIFVBcyhVRXMpIGluIHdpcmxlc3MgYWNjZXNzKHN1Y2gg YXMgVU1UUykgdG8gDQpzdXBwb3J0IDE5OS4gSU1PLCBpdCBpcyBub3Qgc28gY3JpdGljYWwgZm9y IFVBcyB1c2luZyBjYXBibGUgYWNjZXNzIHRvIHVzZSANCjE5OSBhcyB0aGUgb25lcyB1c2luZyB3 aXJlbGVzcyBhY2Nlc3MuDQoNCkFuZCBmdXJ0aGVyLCBjb25zaWRlcmluZyBJTVMsIHdoZW4gUC1D U0NGIHN1cHBvcnQgMTk5LCBpdCBjYW4gdGVybWluYXRlIA0KdGhlIHJlc2VydmVkIHJlc291cmNl IGJ5IFBDQyBmcm9tIG5ldHdvcmsgd2hlbiBpdCByZWNlaXZlcyAxOTksIG5vIG1hdHRlciANClVB cyhvZiB0ZXJtaW5hbHMpIHN1cHBvcnQgMTk5IG9yIG5vdC4gQnkgbXlzZWxmLCB0aGVyZSdzIG5v IG5lZWQgdG8gc2V0IA0KIjE5OSIgYXMgbWFuZGF0b3J5IGZvciBhbGwgVUFzIGluIDNHUFAoQmVj YXVzZSBJIHRoaW5rIHRoZSBleGNsdXNpdmUgcnVsZSANCmlzIG5vdCBwcm9wZXIvZmFpciBmb3Ig VUUgdW4tc3VwcG9ydGluZyAxOTkpLg0KDQpCdXQgbm8gbWF0dGVyIGhvdyAzR1BQIGRlZmluZXMs IEkgc3RpbGwgdGhpbmsgMTk5IGlzIG5lZWRmdWwgZm9yIHdpcmxlc3MgDQphY2Nlc3MuIA0KDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRl bCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8u eWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0K DQoNCkNocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IA0K t6K8/sjLOiAgc2lwY29yZS1ib3VuY2VzQGlldGYub3JnDQoyMDEwLTAxLTEzIDAxOjUwDQoNCsrV vP7Iyw0KQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbT4sIFNJUENPUkUgPHNpcGNvcmVAaWV0 Zi5vcmc+DQqzrcvNDQpSb2JlcnQgU3BhcmtzIDxSalNAbm9zdHJ1bS5jb20+DQrW98ziDQpSZTog W3NpcGNvcmVdIEltcGxlbWVudGF0aW9ucyBvZiBkcmFmdC1pZXRmLXNpcGNvcmUtMTk5LTAyDQoN Cg0KDQoNCg0KDQpIaSwNCg0KQXQgbGVhc3QgM0dQUCBoYXMgYWRvcHRlZCAxOTkgZm9yIElNUywg YW5kIHN1cHBvcnQgaXMgbWFuZGF0b3J5IGZvciBVQXMgDQoodGhvc2Ugd2hpY2ggc3VwcG9ydCB0 aGUgSU5WSVRFIG1ldGhvZCkgYW5kIFMtQ1NDRnMuIEluIGFkZGl0aW9uLCBpdCBjYW4gDQpiZSB1 c2VkIGJ5IGFwcGxpY2F0aW9uIHNlcnZlcnMgcHJvdmlkaW5nIGFub3VuY2VtZW50IHNlcnZpY2Vz IHVzaW5nIHRoZSANCiJmb3JraW5nIG1vZGVsIiAoYSBkZWRpY2F0ZWQgZWFybHkgZGlhbG9nIGlz IGVzdGFibGlzaGVkIGJldHdlZW4gdGhlIFVBIA0KYW5kIEFTKS4NCg0KRXhhY3RseSB3aGVuIGl0 IHdpbGwgYmUgaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkIGJ5IHZhcmlvdXMgdmVuZG9ycyBhbmQg DQpvcGVyYXRvcnMgSSBjYW4ndCBzYXksIGJ1dCBhdCBsZWFzdCBmcm9tIG15IHBlcnNvbmFsIGV4 cGVyaWVuY2UgdGhlcmUgaXMgDQppbnRlcmVzdCBmb3IgaXQuDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogc2lwY29y ZS1ib3VuY2VzQGlldGYub3JnIFtzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiANCkFkYW0gUm9hY2ggW2FkYW1Abm9zdHJ1bS5jb21dDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5 IDEyLCAyMDEwIDY6NTcgUE0NClRvOiBTSVBDT1JFDQpDYzogUm9iZXJ0IFNwYXJrcw0KU3ViamVj dDogW3NpcGNvcmVdIEltcGxlbWVudGF0aW9ucyBvZiBkcmFmdC1pZXRmLXNpcGNvcmUtMTk5LTAy DQoNClthcyBjaGFpcl0NCg0KSW4gb3JkZXIgdG8gcHJvdmlkZSB1c2VmdWwgaW5mb3JtYXRpb24g dG8gdGhlIElFU0cgaW4gdGhlaXIgZXZhbHVhdGlvbiBvZiANCmRyYWZ0LWlldGYtc2lwY29yZS0x OTktMDIsIHdlIHdvdWxkIGxpa2UgdG8gZ2V0IGFuIGlkZWEgb2YgdGhlIGxldmVsIG9mIA0KZXhw ZWN0ZWQgZGVwbG95bWVudC4gUGxlYXNlIGluZGljYXRlLCBlaXRoZXIgcHVibGljbHkgb24gdGhp cyBsaXN0IG9yIA0KcHJpdmF0ZWx5IHRvIG1lLCBpZiB5b3UgZWl0aGVyOg0KDQoNCiAqICAgQ3Vy cmVudGx5IGltcGxlbWVudCBkcmFmdC1pZXRmLXNpcGNvcmUtMTk5LTAyIChvciBhbiBlYXJsaWVy IHZlcnNpb24gDQpvZiB0aGUgZG9jdW1lbnQpLCBvcg0KICogICBQbGFuIHRvIGltcGxlbWVudCBk cmFmdC1pZXRmLXNpcGNvcmUtMTk5LTAyDQoNCkluZm9ybWF0aW9uIHNlbnQgZGlyZWN0bHkgdG8g bWUgd2lsbCBiZSB0cmVhdGVkIGFzIGNvbmZpZGVudGlhbCwgYW5kIA0KcmVwb3J0ZWQgdG8gdGhl IElFU0cgYW5vbnltb3VzbHkgKHRoYXQgaXMsIHdpdGhvdXQgbmFtaW5nIHRoZSBpbmRpdmlkdWFs IA0Kb3IgY29tcGFueSkuIFRoYW5rcy4NCg0KL2ENCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCg0K DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mg b3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJl Y2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFu ZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21t dW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRl ZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlz IG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2Fn ZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0g c3lzdGVtLg0K --=_alternative 000E9B24482576AA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkl0IGlzIHJlYWxseSBtZWFuaW5n IGZvciBVQXMoVUVzKSBpbg0Kd2lybGVzcyBhY2Nlc3Moc3VjaCBhcyBVTVRTKSB0byBzdXBwb3J0 IDE5OS4gSU1PLCBpdCBpcyBub3Qgc28gY3JpdGljYWwNCmZvciBVQXMgdXNpbmcgY2FwYmxlIGFj Y2VzcyB0byB1c2UgMTk5IGFzIHRoZSBvbmVzIHVzaW5nIHdpcmVsZXNzIGFjY2Vzcy48L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFuZCBmdXJ0aGVyLCBj b25zaWRlcmluZyBJTVMsIHdoZW4gUC1DU0NGDQpzdXBwb3J0IDE5OSwgaXQgY2FuIHRlcm1pbmF0 ZSB0aGUgcmVzZXJ2ZWQgcmVzb3VyY2UgYnkgUENDIGZyb20gbmV0d29yaw0Kd2hlbiBpdCByZWNl aXZlcyAxOTksIG5vIG1hdHRlciBVQXMob2YgdGVybWluYWxzKSBzdXBwb3J0IDE5OSBvciBub3Qu IEJ5DQpteXNlbGYsIHRoZXJlJ3Mgbm8gbmVlZCB0byBzZXQgJnF1b3Q7MTk5JnF1b3Q7IGFzIG1h bmRhdG9yeSBmb3IgYWxsIFVBcw0KaW4gM0dQUChCZWNhdXNlIEkgdGhpbmsgdGhlIGV4Y2x1c2l2 ZSBydWxlIGlzIG5vdCBwcm9wZXIvZmFpciBmb3IgVUUgdW4tc3VwcG9ydGluZw0KMTk5KS48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJ1dCBubyBtYXR0 ZXIgaG93IDNHUFAgZGVmaW5lcywgSSBzdGlsbA0KdGhpbmsgMTk5IGlzIG5lZWRmdWwgZm9yIHdp cmxlc3MgYWNjZXNzLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJz cDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRl bDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0 ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4N Cjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5DaHJpc3RlciBI b2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0OzwvYj4NCjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+MjAxMC0wMS0xMyAwMTo1MDwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj5BZGFtIFJvYWNoICZsdDthZGFtQG5vc3RydW0uY29tJmd0 OywNClNJUENPUkUgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5S b2JlcnQgU3BhcmtzICZsdDtSalNAbm9zdHJ1bS5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5S ZTogW3NpcGNvcmVdIEltcGxlbWVudGF0aW9ucyBvZiBkcmFmdC1pZXRmLXNpcGNvcmUtMTk5LTAy PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0 ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0 dD5IaSw8YnI+DQo8YnI+DQpBdCBsZWFzdCAzR1BQIGhhcyBhZG9wdGVkIDE5OSBmb3IgSU1TLCBh bmQgc3VwcG9ydCBpcyBtYW5kYXRvcnkgZm9yIFVBcw0KKHRob3NlIHdoaWNoIHN1cHBvcnQgdGhl IElOVklURSBtZXRob2QpIGFuZCBTLUNTQ0ZzLiBJbiBhZGRpdGlvbiwgaXQgY2FuDQpiZSB1c2Vk IGJ5IGFwcGxpY2F0aW9uIHNlcnZlcnMgcHJvdmlkaW5nIGFub3VuY2VtZW50IHNlcnZpY2VzIHVz aW5nIHRoZQ0KJnF1b3Q7Zm9ya2luZyBtb2RlbCZxdW90OyAoYSBkZWRpY2F0ZWQgZWFybHkgZGlh bG9nIGlzIGVzdGFibGlzaGVkIGJldHdlZW4NCnRoZSBVQSBhbmQgQVMpLjxicj4NCjxicj4NCkV4 YWN0bHkgd2hlbiBpdCB3aWxsIGJlIGltcGxlbWVudGVkIGFuZCBkZXBsb3llZCBieSB2YXJpb3Vz IHZlbmRvcnMgYW5kDQpvcGVyYXRvcnMgSSBjYW4ndCBzYXksIGJ1dCBhdCBsZWFzdCBmcm9tIG15 IHBlcnNvbmFsIGV4cGVyaWVuY2UgdGhlcmUgaXMNCmludGVyZXN0IGZvciBpdC48YnI+DQo8YnI+ DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpGcm9tOiBzaXBjb3JlLWJvdW5jZXNA aWV0Zi5vcmcgW3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQpBZGFtIFJv YWNoIFthZGFtQG5vc3RydW0uY29tXTxicj4NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTIsIDIw MTAgNjo1NyBQTTxicj4NClRvOiBTSVBDT1JFPGJyPg0KQ2M6IFJvYmVydCBTcGFya3M8YnI+DQpT dWJqZWN0OiBbc2lwY29yZV0gSW1wbGVtZW50YXRpb25zIG9mIGRyYWZ0LWlldGYtc2lwY29yZS0x OTktMDI8YnI+DQo8YnI+DQpbYXMgY2hhaXJdPGJyPg0KPGJyPg0KSW4gb3JkZXIgdG8gcHJvdmlk ZSB1c2VmdWwgaW5mb3JtYXRpb24gdG8gdGhlIElFU0cgaW4gdGhlaXIgZXZhbHVhdGlvbg0Kb2Yg ZHJhZnQtaWV0Zi1zaXBjb3JlLTE5OS0wMiwgd2Ugd291bGQgbGlrZSB0byBnZXQgYW4gaWRlYSBv ZiB0aGUgbGV2ZWwNCm9mIGV4cGVjdGVkIGRlcGxveW1lbnQuIFBsZWFzZSBpbmRpY2F0ZSwgZWl0 aGVyIHB1YmxpY2x5IG9uIHRoaXMgbGlzdCBvcg0KcHJpdmF0ZWx5IHRvIG1lLCBpZiB5b3UgZWl0 aGVyOjxicj4NCjxicj4NCjxicj4NCiAqICZuYnNwOyBDdXJyZW50bHkgaW1wbGVtZW50IGRyYWZ0 LWlldGYtc2lwY29yZS0xOTktMDIgKG9yIGFuIGVhcmxpZXINCnZlcnNpb24gb2YgdGhlIGRvY3Vt ZW50KSwgb3I8YnI+DQogKiAmbmJzcDsgUGxhbiB0byBpbXBsZW1lbnQgZHJhZnQtaWV0Zi1zaXBj b3JlLTE5OS0wMjxicj4NCjxicj4NCkluZm9ybWF0aW9uIHNlbnQgZGlyZWN0bHkgdG8gbWUgd2ls bCBiZSB0cmVhdGVkIGFzIGNvbmZpZGVudGlhbCwgYW5kIHJlcG9ydGVkDQp0byB0aGUgSUVTRyBh bm9ueW1vdXNseSAodGhhdCBpcywgd2l0aG91dCBuYW1pbmcgdGhlIGluZGl2aWR1YWwgb3IgY29t cGFueSkuDQpUaGFua3MuPGJyPg0KPGJyPg0KL2E8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0K c2lwY29yZUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwY29yZTxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF Jm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJz cDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwm bmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtz ZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7 bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFp bnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0 dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2Ym bmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZu YnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZu YnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNw O2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNw O3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91 Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJz cDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3Im bmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtl eHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhv c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5i c3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7 dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3Bh bSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 000E9B24482576AA_=-- From gonzalo.camarillo@ericsson.com Wed Jan 13 01:13:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272E43A6864 for ; Wed, 13 Jan 2010 01:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.989 X-Spam-Level: X-Spam-Status: No, score=-105.989 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OevELqXowpQ for ; Wed, 13 Jan 2010 01:12:58 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 3E31E3A6827 for ; Wed, 13 Jan 2010 01:12:57 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-59-4b4d8e9631be Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id AE.C0.04178.69E8D4B4; Wed, 13 Jan 2010 10:12:54 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 10:12:53 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 10:12:53 +0100 Message-ID: <4B4D8E95.9@ericsson.com> Date: Wed, 13 Jan 2010 11:12:53 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Paul Kyzivat References: <4B41EDC9.6050204@cisco.com> In-Reply-To: <4B41EDC9.6050204@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2010 09:12:53.0657 (UTC) FILETIME=[966D5890:01CA9430] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 09:13:01 -0000 Hi Paul, yes, that section of the draft includes a 'TODO' part because it does not provide an acceptable solution yet. What we need to decide, as you suggest in your email, is the point where the new session parameters are considered to be in use. Without preconditions, this should be easy. When the new offer/answer completes, the new parameters are in use. With preconditions, it is a bit more complex. The new parameters should be considered to be in use when the preconditions are met. The issue here is that, in some cases, it is the UAS the one that figures out when the preconditions are met and starts sending media using the new parameters, sometimes without issuing any SIP signalling. I wrote a draft a while ago describing this issue and explaining how the UAS can use SIP to signal the fact that the new parameters are now in use: http://www.watersprings.org/pub/id/draft-camarillo-sipping-precons-00.txt Using SIP signalling instead of having the UAC discover that the new parameters are in use at the media level is useful when the stream does not carry media continuously. Therefore, I would propose to consider that the new parameters are in use when the following happens: o an offer/answer without preconditions for the stream completes successfully, or o an offer/answer where all the preconditions for the stream are met completes successfully, or o media is received using the new parameters Additionally, we may want to resurrect the draft above about preconditions so that the issue is described in more detail. However, last time I asked people were not that interested in the draft. If we want to resurrect it now, I would be OK with doing so. Thanks, Gonzalo Paul Kyzivat wrote: > Gonzalo, > > Over the holidays I had occasion to review the above document again, and > I have a question about the criterion you propose for sending an error > response or not: > > If any of the changes requested in a re-INVITE or in any transaction > within it have already been executed (with the exception of target > refreshes), the UAS MUST always return a 2xx response. > > A change to the session state is considered to have been executed > when the new media parameters are being used. Therefore, a change to > a stream subject to preconditions [RFC4032] is considered to have > been executed when the new media parameters start being used; not > when the preconditions for the stream are met. Connection > establishment messages (e.g., TCP SYN) and connectivity checks (e.g., > when using ICE [I-D.ietf-mmusic-ice]) are not considered media > either. A UA considers the new parameters to be in use when it sends > media using them, or when media that uses the new parameters is > received, which should be interpreted as follows. From Section 8.3.1 > of RFC 3264 [RFC3264]: > > "Received, in this case, means that the media is passed to a media > sink. This means that if there is a playout buffer, the agent > would continue to listen on the old port until the media on the > new port reached the top of the playout buffer. At that time, it > MAY cease listening for media on the old port." > > Consider the case where the o/a has been performed, and the UAC has sent > media according to the new session description, but the UAS has not yet > sent or received that media according to the definition above. In that > case, the UAS may choose to send an error response. But the UAC has > already made the change to the new session, and so will need to switch > again to the old one. This is the case you are attempting to avoid, and > yet it has not been avoided. I don't see an easy answer to this - only > messy ones. > > Thanks, > Paul > From kpfleming@digium.com Wed Jan 13 05:54:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E17393A69CF for ; Wed, 13 Jan 2010 05:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dc45YumgYD-H for ; Wed, 13 Jan 2010 05:54:05 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id D0BEA3A69E7 for ; Wed, 13 Jan 2010 05:54:05 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1NV3fc-0007gf-Oj; Wed, 13 Jan 2010 07:54:00 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id AD970D8531; Wed, 13 Jan 2010 07:54:06 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUrIlb35baIw; Wed, 13 Jan 2010 07:54:02 -0600 (CST) Received: from [172.19.1.105] (173-24-207-110.client.mchsi.com [173.24.207.110]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 9FDC9D8530; Wed, 13 Jan 2010 07:54:02 -0600 (CST) Message-ID: <4B4DD073.2060706@digium.com> Date: Wed, 13 Jan 2010 07:53:55 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4B41EDC9.6050204@cisco.com> <4B4D8E95.9@ericsson.com> In-Reply-To: <4B4D8E95.9@ericsson.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 13:54:07 -0000 Gonzalo Camarillo wrote: > Therefore, I would propose to consider that the new parameters are in > use when the following happens: > > o an offer/answer without preconditions for the stream completes > successfully, or > o an offer/answer where all the preconditions for the stream are met > completes successfully, or > o media is received using the new parameters I've never been a fan of implicit behavior, so this gets my vote. I'd even vote for not allowing the endpoints to use the new parameters at all until the offer/answer is complete, but I can understand the motivation for allowing it. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpfleming@digium.com Check us out at www.digium.com & www.asterisk.org From pkyzivat@cisco.com Wed Jan 13 06:01:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F5D3A69F2 for ; Wed, 13 Jan 2010 06:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[AWL=-0.760, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2HnEC4LVneZ for ; Wed, 13 Jan 2010 06:01:24 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D221F3A6813 for ; Wed, 13 Jan 2010 06:01:23 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHhhTUutJV2b/2dsb2JhbADBS5RXhDAE X-IronPort-AV: E=Sophos;i="4.49,268,1262563200"; d="scan'208";a="79967623" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 13 Jan 2010 14:01:20 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o0DE1KQi015213; Wed, 13 Jan 2010 14:01:20 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 08:01:20 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 08:01:19 -0600 Message-ID: <4B4DD22F.8060309@cisco.com> Date: Wed, 13 Jan 2010 09:01:19 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B20DDCF.9000409@ericsson.com> <4B2A4717.5090100@ericsson.com> <4B3342C8.8090400@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2010 14:01:20.0005 (UTC) FILETIME=[E1D07B50:01CA9458] Cc: SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC draft-ietf-sipcore-info-events-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 14:01:25 -0000 Christer Holmberg wrote: >> 6. In 3.3.1: >> "NOTE: Some SIP functions that are orthogonal to INFO can insert body parts unrelated to the Info Package." >> I am not sure a reader would understand this. Also, for legacy usage, a body part could be related to INFO (i.e., not "orthogonal") but not related to any Info Package. A possible improvement would be: >> >> "NOTE: An INFO request can also contain other body parts that are meaningful within the context of an invite dialog usage but are not specifically associated with the INFO method and the application >> concerned." > > I think the text was provided by Paul, but I think the text you suggest is more clear, so I'll fix it according to that. I doubt Paul will mind :) No, I don't object. Thanks, Paul From pkyzivat@cisco.com Wed Jan 13 06:45:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36D263A67DA for ; Wed, 13 Jan 2010 06:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.346 X-Spam-Level: X-Spam-Status: No, score=-10.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkKS8-SHYJcn for ; Wed, 13 Jan 2010 06:45:35 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B32DD3A6403 for ; Wed, 13 Jan 2010 06:45:34 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA5rTUutJV2Y/2dsb2JhbADCHpRahDAE X-IronPort-AV: E=Sophos;i="4.49,268,1262563200"; d="scan'208";a="287811701" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-1.cisco.com with ESMTP; 13 Jan 2010 14:45:32 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o0DEjVKN007565; Wed, 13 Jan 2010 14:45:31 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 08:45:32 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 08:45:31 -0600 Message-ID: <4B4DDC8A.6070701@cisco.com> Date: Wed, 13 Jan 2010 09:45:30 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4B41EDC9.6050204@cisco.com> <4B4D8E95.9@ericsson.com> In-Reply-To: <4B4D8E95.9@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2010 14:45:31.0381 (UTC) FILETIME=[0E285A50:01CA945F] Cc: SIPCORE Subject: Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 14:45:37 -0000 inline Gonzalo Camarillo wrote: > Hi Paul, > > yes, that section of the draft includes a 'TODO' part because it does > not provide an acceptable solution yet. What we need to decide, as you > suggest in your email, is the point where the new session parameters are > considered to be in use. > > Without preconditions, this should be easy. When the new offer/answer > completes, the new parameters are in use. Hmm. That seems inconsistent with current text: either. A UA considers the new parameters to be in use when it sends media using them, or when media that uses the new parameters is received, which should be interpreted as follows. From Section 8.3.1 of RFC 3264 [RFC3264]: "Received, in this case, means that the media is passed to a media sink. This means that if there is a playout buffer, the agent would continue to listen on the old port until the media on the new port reached the top of the playout buffer. At that time, it MAY cease listening for media on the old port." The above seems to imply that "in use" will happen later than the completion of the o/a exchange - potentially quite a bit later if there was already data in the playout buffer before the o/a exchange. > With preconditions, it is a bit more complex. The new parameters should > be considered to be in use when the preconditions are met. The issue > here is that, in some cases, it is the UAS the one that figures out when > the preconditions are met and starts sending media using the new > parameters, sometimes without issuing any SIP signalling. I wrote a > draft a while ago describing this issue and explaining how the UAS can > use SIP to signal the fact that the new parameters are now in use: > > http://www.watersprings.org/pub/id/draft-camarillo-sipping-precons-00.txt > > Using SIP signalling instead of having the UAC discover that the new > parameters are in use at the media level is useful when the stream does > not carry media continuously. > > Therefore, I would propose to consider that the new parameters are in > use when the following happens: > > o an offer/answer without preconditions for the stream completes > successfully, or > o an offer/answer where all the preconditions for the stream are met > completes successfully, or > o media is received using the new parameters That might help, but I don't think it totally solves the problem of the two sides having different ideas of whether the parameters are in use. The o/a exchange is presumably done for the offerer when it receives the answer. But when is the o/a exchange done for the answerer? Is it when it first sends the answer, or when it gets some signaling indication that the answer was received? To be safe, in the absence of preconditions, it seems that the answerer should consider the new o/a parameters to be in use as soon as the answer has been *sent*. Also, if the UAS for the reinvite has sent an offer (in something other than a 2xx for the reinvite) and has not yet received the answer to that offer, it must not send a failure response to the reinvite, because it doesn't yet know if that o/a is complete in the eyes of the answerer. (Exception: it can send an error response that terminates the complete call/dialog, such as a 408.) > Additionally, we may want to resurrect the draft above about > preconditions so that the issue is described in more detail. However, > last time I asked people were not that interested in the draft. If we > want to resurrect it now, I would be OK with doing so. I don't know about that draft, but it seems we need *something* to clarify the behavior in that case. Thanks, Paul > Thanks, > > Gonzalo > > > Paul Kyzivat wrote: >> Gonzalo, >> >> Over the holidays I had occasion to review the above document again, >> and I have a question about the criterion you propose for sending an >> error response or not: >> >> If any of the changes requested in a re-INVITE or in any transaction >> within it have already been executed (with the exception of target >> refreshes), the UAS MUST always return a 2xx response. >> >> A change to the session state is considered to have been executed >> when the new media parameters are being used. Therefore, a change to >> a stream subject to preconditions [RFC4032] is considered to have >> been executed when the new media parameters start being used; not >> when the preconditions for the stream are met. Connection >> establishment messages (e.g., TCP SYN) and connectivity checks (e.g., >> when using ICE [I-D.ietf-mmusic-ice]) are not considered media >> either. A UA considers the new parameters to be in use when it sends >> media using them, or when media that uses the new parameters is >> received, which should be interpreted as follows. From Section 8.3.1 >> of RFC 3264 [RFC3264]: >> >> "Received, in this case, means that the media is passed to a media >> sink. This means that if there is a playout buffer, the agent >> would continue to listen on the old port until the media on the >> new port reached the top of the playout buffer. At that time, it >> MAY cease listening for media on the old port." >> >> Consider the case where the o/a has been performed, and the UAC has >> sent media according to the new session description, but the UAS has >> not yet sent or received that media according to the definition above. >> In that case, the UAS may choose to send an error response. But the >> UAC has already made the change to the new session, and so will need >> to switch again to the old one. This is the case you are attempting to >> avoid, and yet it has not been avoided. I don't see an easy answer to >> this - only messy ones. >> >> Thanks, >> Paul >> > > From gonzalo.camarillo@ericsson.com Wed Jan 13 07:46:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF1C53A681D for ; Wed, 13 Jan 2010 07:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.032 X-Spam-Level: X-Spam-Status: No, score=-106.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaNDJHulsIim for ; Wed, 13 Jan 2010 07:46:25 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 969FD3A67A7 for ; Wed, 13 Jan 2010 07:46:25 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-11-4b4deacd1e46 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id A0.53.04178.DCAED4B4; Wed, 13 Jan 2010 16:46:21 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 16:46:21 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 16:46:21 +0100 Message-ID: <4B4DEACD.2030801@ericsson.com> Date: Wed, 13 Jan 2010 17:46:21 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Paul Kyzivat References: <4B41EDC9.6050204@cisco.com> <4B4D8E95.9@ericsson.com> <4B4DDC8A.6070701@cisco.com> In-Reply-To: <4B4DDC8A.6070701@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2010 15:46:21.0401 (UTC) FILETIME=[8DBD3490:01CA9467] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 15:46:26 -0000 Hi Paul, thanks for your answers. More comments inline: >> Without preconditions, this should be easy. When the new offer/answer >> completes, the new parameters are in use. > > Hmm. That seems inconsistent with current text: [snip] > The above seems to imply that "in use" will happen later than the > completion of the o/a exchange - potentially quite a bit later if there > was already data in the playout buffer before the o/a exchange. yes, what I was proposing was to replace the current text with the rule I was proposing above. > That might help, but I don't think it totally solves the problem of the > two sides having different ideas of whether the parameters are in use. > > The o/a exchange is presumably done for the offerer when it receives the > answer. But when is the o/a exchange done for the answerer? Is it when > it first sends the answer, or when it gets some signaling indication > that the answer was received? To be safe, in the absence of > preconditions, it seems that the answerer should consider the new o/a > parameters to be in use as soon as the answer has been *sent*. yes, that is also what I had in mind. > Also, if the UAS for the reinvite has sent an offer (in something other > than a 2xx for the reinvite) and has not yet received the answer to that > offer, it must not send a failure response to the reinvite, because it > doesn't yet know if that o/a is complete in the eyes of the answerer. > (Exception: it can send an error response that terminates the complete > call/dialog, such as a 408.) this is just one of the race conditions we need to tackle (the draft has a second TODO section about that). I am working on defining procedures to avoid this and other race or glare situations. >> Additionally, we may want to resurrect the draft above about >> preconditions so that the issue is described in more detail. However, >> last time I asked people were not that interested in the draft. If we >> want to resurrect it now, I would be OK with doing so. > > I don't know about that draft, but it seems we need *something* to > clarify the behavior in that case. I will add explanations in this draft... if we are happy with them, we do not need the other draft. Otherwise, we could think about it. Thanks, Gonzalo From wwwrun@core3.amsl.com Wed Jan 13 07:57:46 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 79FF53A67D3; Wed, 13 Jan 2010 07:57:46 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100113155746.79FF53A67D3@core3.amsl.com> Date: Wed, 13 Jan 2010 07:57:46 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] Last Call: draft-ietf-sipcore-199 (Response Code for Indication of Terminated Dialog) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 15:57:46 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'Response Code for Indication of Terminated Dialog ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-01-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sipcore-199-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18520&rfc_flag=0 From brett@broadsoft.com Wed Jan 13 14:30:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1AA43A67FB for ; Wed, 13 Jan 2010 14:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMR-4g8KTp1r for ; Wed, 13 Jan 2010 14:30:08 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id D6BA23A67F8 for ; Wed, 13 Jan 2010 14:30:08 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 13 Jan 2010 14:30:06 -0800 From: Brett Tate To: SIPCORE Date: Wed, 13 Jan 2010 14:29:41 -0800 Thread-Topic: rfc3261: sip-uri user parameter Thread-Index: AcqUn+ZpEIdQ4HxwS7Cq66yNz89bag== Message-ID: <747A6506A991724FB09B129B79D5FEB6145F96714A@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] rfc3261: sip-uri user parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 22:30:09 -0000 Since we were unable to reach agreement on sip-implementors, I thought that= I'd try sip-core. https://lists.cs.columbia.edu/pipermail/sip-implementors/2010-January/02413= 1.html What does adding user=3Dphone to sip-uri mean? 1) Whatever the owner of sip-uri's host wants it to mean; it isn't restrict= ed to being a telephone-subscriber. Thus okay to add user=3Dphone when use= rinfo portion of sip-uri is "anonymous@", not present, and etcetera. 2) The userinfo portion of sip-uri contains telephone-subscriber (defined w= ithin rfc3966/rfc2806). 3) Another meaning. Thanks, Brett From pkyzivat@cisco.com Wed Jan 13 14:49:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43753A67F8 for ; Wed, 13 Jan 2010 14:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.056 X-Spam-Level: X-Spam-Status: No, score=-10.056 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQfpXCsoii75 for ; Wed, 13 Jan 2010 14:49:04 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1EB313A67C1 for ; Wed, 13 Jan 2010 14:49:03 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHDcTUtAZnwN/2dsb2JhbADDCZUChDAEhW8 X-IronPort-AV: E=Sophos;i="4.49,270,1262563200"; d="scan'208";a="80059485" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Jan 2010 22:49:00 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.174]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0DMmiTr016295; Wed, 13 Jan 2010 22:49:00 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 16:48:27 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 16:48:26 -0600 Message-ID: <4B4E4DE6.6050707@cisco.com> Date: Wed, 13 Jan 2010 17:49:10 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brett Tate References: <747A6506A991724FB09B129B79D5FEB6145F96714A@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB6145F96714A@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2010 22:48:27.0041 (UTC) FILETIME=[84FF3110:01CA94A2] Cc: SIPCORE Subject: Re: [sipcore] rfc3261: sip-uri user parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 22:49:15 -0000 Brett Tate wrote: > Since we were unable to reach agreement on sip-implementors, I thought that I'd try sip-core. > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2010-January/024131.html > > > What does adding user=phone to sip-uri mean? > > 1) Whatever the owner of sip-uri's host wants it to mean; it isn't restricted to being a telephone-subscriber. Thus okay to add user=phone when userinfo portion of sip-uri is "anonymous@", not present, and etcetera. > 2) The userinfo portion of sip-uri contains telephone-subscriber (defined within rfc3966/rfc2806). > > 3) Another meaning. There are two questions lurking here: - what normative requirements are there on the use of user=phone? - what *should* user=phone mean? IMO there is currently nothing of consequence that is required. IMO there *ought* to be a requirement that: if user=phone is present, then the user part MUST conform to the syntax of telephone-subscriber. Thanks, Paul From christer.holmberg@ericsson.com Wed Jan 13 23:55:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0983A694C for ; Wed, 13 Jan 2010 23:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgBy24UK+HER for ; Wed, 13 Jan 2010 23:55:47 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id EE68E3A6950 for ; Wed, 13 Jan 2010 23:55:46 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-89-4b4ecdfebdba Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 56.5F.04178.EFDCE4B4; Thu, 14 Jan 2010 08:55:43 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 14 Jan 2010 08:55:42 +0100 From: Christer Holmberg To: SIPCORE , Gonzalo Camarillo , Adam Roach Date: Thu, 14 Jan 2010 08:55:41 +0100 Thread-Topic: Draft new version: draft-ietf-sipcore-info-events-04 [was: [sipcore] WGLC draft-ietf-sipcore-info-events-03.txt] Thread-Index: AcqEhCRkkOVAI0ztTsmH2JGjHBGiEAKh285QASzVBFAAS+Fo0A== Message-ID: References: <4B20DDCF.9000409@ericsson.com> <4B2A4717.5090100@ericsson.com> <4B3342C8.8090400@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: draft-ietf-sipcore-info-events-04 [was: WGLC draft-ietf-sipcore-info-events-03.txt] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 07:55:48 -0000 Hi, I've submitted a new version (-04) of info-events, based on some additional= WGLC comments. Most changes are editorial, but a new short section, 3.2.3 (SIP Proxies), h= as been added. The document can also be found at: http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-04.tx= t Regards, Christer From root@core3.amsl.com Thu Jan 14 00:00:01 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CB2253A694D; Thu, 14 Jan 2010 00:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100114080001.CB2253A694D@core3.amsl.com> Date: Thu, 14 Jan 2010 00:00:01 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-info-events-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 08:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) INFO Method and Package Framework Author(s) : C. Holmberg, et al. Filename : draft-ietf-sipcore-info-events-04.txt Pages : 39 Date : 2010-01-13 This document defines a new method, INFO, for the Session Initiation Protocol (SIP) [RFC3261], and an Info Package mechanism. The document obsoletes [RFC2976]. For backward compatibility the document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in [RFC2976], referred to as "legacy INFO Usage" in this document. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The terminology in this document conforms to the Internet Security Glossary [RFC4949]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 18, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-info-events-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-13235505.I-D@ietf.org> --NextPart-- From gonzalo.camarillo@ericsson.com Thu Jan 14 00:33:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78373A688F for ; Thu, 14 Jan 2010 00:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.063 X-Spam-Level: X-Spam-Status: No, score=-106.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3B6KAnqldOdp for ; Thu, 14 Jan 2010 00:33:55 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id DA5A93A68F5 for ; Thu, 14 Jan 2010 00:33:54 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-f2-4b4ed6ee7817 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 78.58.04178.EE6DE4B4; Thu, 14 Jan 2010 09:33:50 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 09:33:50 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 09:33:50 +0100 Message-ID: <4B4ED6EE.5060101@ericsson.com> Date: Thu, 14 Jan 2010 10:33:50 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE References: <4B41EDC9.6050204@cisco.com> <4B4D8E95.9@ericsson.com> <4B4DDC8A.6070701@cisco.com> <4B4DEACD.2030801@ericsson.com> In-Reply-To: <4B4DEACD.2030801@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2010 08:33:50.0226 (UTC) FILETIME=[4C0BE720:01CA94F4] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 08:33:57 -0000 Hi, I have put together a new version of the draft: http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre01a.txt Let me know if you have some comments before I submit it. Regarding the decision about when a given change in the session state has been executed when preconditions are used, I have added a paragraph that summarizes our discussions and the following draft: http://www.watersprings.org/pub/id/draft-camarillo-sipping-precons-00.txt Please, read Section 5. Sections 7 and 15 contain new rules to avoid glare situations and race conditions. These rules avoid nasty call flows that were able to get the UAs out of synch. Some time ago, we discussed whether or not unreliable provisional responses could refresh the remote target. There are several problems with unreliable responses updating remote targets. First, we would need to define even more rules to avoid glare situations and race conditions. Second, SIP does not provide any ordering for unreliable provisional responses. Responses arriving out of order at the UAC could easily get both UAs out of synch. Therefore, only reliable responses can refresh remote targets, as was specified in RFC 3261 anyway. We also discussed the applicability of the target refresh rules to initial INVITEs. The rules in the draft cover them as well so I do not think we need to add anything else to that end. Thanks, Gonzalo From gonzalo.camarillo@ericsson.com Thu Jan 14 03:29:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019913A68F0 for ; Thu, 14 Jan 2010 03:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.105 X-Spam-Level: X-Spam-Status: No, score=-106.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o332L99wQDCF for ; Thu, 14 Jan 2010 03:29:05 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C761E3A68D4 for ; Thu, 14 Jan 2010 03:29:04 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-3a-4b4efffcdc6e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 88.C7.04178.CFFFE4B4; Thu, 14 Jan 2010 12:29:00 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 12:28:59 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 12:29:00 +0100 Message-ID: <4B4EFFF9.1030705@ericsson.com> Date: Thu, 14 Jan 2010 13:28:57 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2010 11:29:00.0051 (UTC) FILETIME=[C463EE30:01CA950C] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 11:29:06 -0000 Hi, we intend to request the publication of this draft next week. If there is no further comments on the draft, we will ask the authors to fix the references problems reported by the ID nits tool below and we will be requesting the publication of that revision. http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-sipcore-info-events-04.txt Thanks, Gonzalo SIPCORE co-chair From gonzalo.camarillo@ericsson.com Thu Jan 14 03:33:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92DE3A68DD for ; Thu, 14 Jan 2010 03:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.119 X-Spam-Level: X-Spam-Status: No, score=-106.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvqTtRIStOvd for ; Thu, 14 Jan 2010 03:33:55 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C4C9A3A68D4 for ; Thu, 14 Jan 2010 03:33:54 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-08-4b4f011e89c0 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id F3.19.04178.E110F4B4; Thu, 14 Jan 2010 12:33:50 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 12:33:50 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 12:33:50 +0100 Message-ID: <4B4F011E.5060304@ericsson.com> Date: Thu, 14 Jan 2010 13:33:50 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2010 11:33:50.0267 (UTC) FILETIME=[715F60B0:01CA950D] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] WGLC of draft-ietf-sipcore-invfix-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 11:33:56 -0000 Folks, we would like to WGLC the following draft: http://tools.ietf.org/id/draft-ietf-sipcore-invfix-00.txt This WGLC will end on January 31st. Please, send your comments to this list. Thanks, Gonzalo SIPCORE co-chair From gonzalo.camarillo@ericsson.com Thu Jan 14 03:38:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F013A68F0 for ; Thu, 14 Jan 2010 03:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.131 X-Spam-Level: X-Spam-Status: No, score=-106.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0P0k13XNkMZ for ; Thu, 14 Jan 2010 03:38:28 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E03073A68DD for ; Thu, 14 Jan 2010 03:38:27 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-a9-4b4f022f6810 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 94.3A.04178.F220F4B4; Thu, 14 Jan 2010 12:38:24 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 12:38:23 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 12:38:23 +0100 Message-ID: <4B4F022F.30502@ericsson.com> Date: Thu, 14 Jan 2010 13:38:23 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "krisztian.kiss@nokia.com" References: <20100108210001.E16FD3A686B@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2010 11:38:23.0361 (UTC) FILETIME=[14263710:01CA950E] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 11:38:29 -0000 Hi, > The authors think this version is ready for WGLC. you have received a few comments on this list. Additionally, we have requested feedback from the Geopriv WG: http://www.ietf.org/mail-archive/web/geopriv/current/msg08252.html Regarding the WGLC, we will be able to start it when the WGLC on the invfix draft is over. We are talking about February. Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Thu Jan 14 03:54:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D7B3A68A8; Thu, 14 Jan 2010 03:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.141 X-Spam-Level: X-Spam-Status: No, score=-106.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRjBJ-LN2PQK; Thu, 14 Jan 2010 03:54:26 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E9C093A683D; Thu, 14 Jan 2010 03:54:25 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-02-4b4f05de8cc9 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 88.2F.04178.ED50F4B4; Thu, 14 Jan 2010 12:54:07 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 12:52:41 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 12:52:41 +0100 Message-ID: <4B4F0589.6090202@ericsson.com> Date: Thu, 14 Jan 2010 13:52:41 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Paul E. Jones" , Richard Shockey References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <4B39AE2C.9090304@softarmor.com> <503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com> <1AA2A44A-3C89-4903-879C-9F74E459C93D@softarmor.com> <4B433B4B.1030407@digium.com> <80D99821-B111-4C94-BC68-536CB65DD15E@softarmor.com> <4B43D7C5.1050306@cisco.com> <004f01ca8eb3$7659d790$630d86b0$@com> <4B44AC4E.4020309@cisco.com> <4B44AE40.2060104@digium.com> <00d101ca8f15$c91915b0$5b4b4110$@com> In-Reply-To: <00d101ca8f15$c91915b0$5b4b4110$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2010 11:52:41.0080 (UTC) FILETIME=[1363BF80:01CA9510] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] [dispatch] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 11:54:27 -0000 Hi, > We've had a number of exchanges and some people have missed a few messages > as the thread bounced around two lists. I'm sending this to both sipcore > and dispatch so that people do not miss the discussion. that is why we do not want people to cross-post to multiple lists and that is also why Dean, showing great wisdom (as usual ;o) ), removed one of the lists from the cc: when following up. Things can get confusing between lists and people subscribed to both get a lot of duplicate messages. In the future, please stick to only one list. Thanks, Gonzalo DISPATCH and SIPCORE co-chair From john.elwell@siemens-enterprise.com Thu Jan 14 05:40:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC613A635F for ; Thu, 14 Jan 2010 05:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qrj2hDMsgU9J for ; Thu, 14 Jan 2010 05:40:50 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 14A773A67FB for ; Thu, 14 Jan 2010 05:40:49 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-538595; Thu, 14 Jan 2010 14:40:45 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id DE62F1EB8293; Thu, 14 Jan 2010 14:40:45 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 14 Jan 2010 14:40:45 +0100 From: "Elwell, John" To: Gonzalo Camarillo , SIPCORE Date: Thu, 14 Jan 2010 14:40:44 +0100 Thread-Topic: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events Thread-Index: AcqVDMxlx646glEXRSW/EMEPD0h1TQAEky3w Message-ID: References: <4B4EFFF9.1030705@ericsson.com> In-Reply-To: <4B4EFFF9.1030705@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 13:40:51 -0000 I have no further comments. John=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 14 January 2010 11:29 > To: SIPCORE > Subject: [sipcore] Requesting the publication of the=20 > draft-ietf-sipcore-info-events >=20 > Hi, >=20 > we intend to request the publication of this draft next week.=20 > If there=20 > is no further comments on the draft, we will ask the authors=20 > to fix the=20 > references problems reported by the ID nits tool below and we will be=20 > requesting the publication of that revision. >=20 > http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draf > t-ietf-sipcore-info-events-04.txt >=20 > Thanks, >=20 > Gonzalo > SIPCORE co-chair > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Thu Jan 14 07:33:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 682C93A6403 for ; Thu, 14 Jan 2010 07:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.354 X-Spam-Level: X-Spam-Status: No, score=-10.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2s-y-rtHu10S for ; Thu, 14 Jan 2010 07:33:42 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1EE443A6782 for ; Thu, 14 Jan 2010 07:33:42 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAL/HTktAZnwM/2dsb2JhbADEHpR5hDAE X-IronPort-AV: E=Sophos;i="4.49,275,1262563200"; d="scan'208";a="80091982" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 14 Jan 2010 15:33:38 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.175]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0EFXcGj011885 for ; Thu, 14 Jan 2010 15:33:38 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 09:33:38 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 09:33:38 -0600 Message-ID: <4B4F3952.7060703@cisco.com> Date: Thu, 14 Jan 2010 10:33:38 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE References: <20100114080001.CB2253A694D@core3.amsl.com> In-Reply-To: <20100114080001.CB2253A694D@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2010 15:33:38.0290 (UTC) FILETIME=[F14D7520:01CA952E] Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-info-events-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 15:33:43 -0000 I just reviewed the latest version of this document. I must say it is looking pretty good now! I only have relatively minor comments: Abstract: NIT: "This document defines a new method, INFO, ..." Such statements never age well, and that is especially the case for a revision document. How about just "This document defines a method, INFO, ..."? (This correction should also be made to section 1 -Introduction, and section 2 - Applicability.) Section 3.3.1: When a UA supports a specific Info-Package, the UA also support all message body MIME types associated with that Info-Package. However, in accordance with [RFC3261] the UA still indicates the supported MIME types using the Accept header. Is there supposed to be something normative here? As stated there isn't. Perhaps: When a UA supports a specific Info-Package, the UA MUST also support message body MIME types in accord with that Info-Package. However, in accordance with [RFC3261] the UA still indicates the supported MIME types using the Accept header. (I said "in accord" rather than "all" in the above because some info package specifications might define mime type alternatives in a way that doesn't require all to be supported.) Section 3.4: If specific applications need additional mechanisms for order of delivery, those mechanisms, and related procedures, are specified as part of the associated Info Package, and possible sequence numbers etc must be defined as application data. The non-normative "must" seems awkward. How about: If specific applications need additional mechanisms for order of delivery, those mechanisms, and related procedures, are specified as part of the associated Info Package. (E.g. the use of sequence numbers within the application data.) Section 4.4.2: Nit: "Recv-Info" is misspelled as "Revc-Info" at least once. The following: Once a UA has sent a set of Info Packages, the set is valid until the UA sends a new set, or an empty Recv-Info header field. could be construed to mean INFO messages have been sent containing certain Info Packages. How about: Once a UA has sent a message with a Recv-Info header field containing a set of Info Packages, the set is valid until the UA sends a new Recv-Info header field containing a new, or empty set. Section 4.2.3: NOTE: Similar to SDP answers, the receiver can include the same Recv- Info header field value in multiple responses (18x/2xx) for the same INVITE/re-INVITE transaction, but the receiver is not allowed to include a Recv-Info header field value which is different from a value that the receiver has already included in a response for the same transaction. I think "the receiver is not allowed" is intended to be normative. But the language isn't normative. If it is indeed intended to be normative this needs to be rewritten. Section 6.1: Why is Info-Package permitted in 469? Is the expectation that the UAS will copy the Info-Package header (but not the body) from the request into the response? If so, then there ought to be some text somewhere that says that. But why bother? It would be more useful to include the Recv-Info header in the 469 response. (That would require added specification, since it is currently forbidden to do so.) There is trouble with the formatting of the paragraph following the table: The support and usage of the Info-Package and Recv-Info header fields is not applicalbe to UAs that only support legacy INFO usages. * Not applicalbe to INFO requests and responses associated with legacy INFO usages. ** Mandatory in at least one reliable 18x/2xx response, if sent, to the INVITE request, if the associated INVITE request contained a Recv-Info header field. *** Mandatory if the associated request contained a Recv-Info header field. Should presumably be: The support and usage of the Info-Package and Recv-Info header fields is not applicable to UAs that only support legacy INFO usages. * Not applicable to INFO requests and responses associated with legacy INFO usages. ** Mandatory in at least one reliable 18x/2xx response, if sent, to the INVITE request, if the associated INVITE request contained a Recv-Info header field. *** Mandatory if the associated request contained a Recv-Info header field. Section 7.4.1.3: NIT: s/ser/user/ Section 8.2: There is a preferred method for defining extensions now: Method =/ INFOm Also, the following is missing but needed: message-header =/ (Info-Package / Recv-Info) CRLF However these changes will require referencing RFC 5234 Section 10.4: The cross reference to section 10.5 is wrong. And I'm not certain what the correct value is - perhaps 11.4??? Thanks, Paul From adam@nostrum.com Thu Jan 14 11:57:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD643A699A for ; Thu, 14 Jan 2010 11:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSUVYVhVJPnj for ; Thu, 14 Jan 2010 11:57:08 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id AA3013A6872 for ; Thu, 14 Jan 2010 11:57:04 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0EJuxSa033479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jan 2010 13:56:59 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B4F770B.1090909@nostrum.com> Date: Thu, 14 Jan 2010 13:56:59 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Paul Kyzivat References: <20100114080001.CB2253A694D@core3.amsl.com> <4B4F3952.7060703@cisco.com> In-Reply-To: <4B4F3952.7060703@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-info-events-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 19:57:08 -0000 On 1/14/10 09:33, Jan 14, Paul Kyzivat wrote: > Method =/ INFOm This is more important than it may seem at first, so I want to put particular emphasis on it. Christer: please fix this issue before we pubreq the document. /a From pkyzivat@cisco.com Thu Jan 14 12:21:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11C43A69D1 for ; Thu, 14 Jan 2010 12:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.363 X-Spam-Level: X-Spam-Status: No, score=-10.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvSOpnSdDaQ5 for ; Thu, 14 Jan 2010 12:21:10 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 211FF3A69C8 for ; Thu, 14 Jan 2010 12:21:10 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAMLT0urR7Hu/2dsb2JhbADDMZR7hDAE X-IronPort-AV: E=Sophos;i="4.49,277,1262563200"; d="scan'208";a="288415098" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 14 Jan 2010 20:21:07 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0EKL6qN006629; Thu, 14 Jan 2010 20:21:07 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 14:21:06 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 14:21:06 -0600 Message-ID: <4B4F7CB1.50406@cisco.com> Date: Thu, 14 Jan 2010 15:21:05 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <20100114080001.CB2253A694D@core3.amsl.com> <4B4F3952.7060703@cisco.com> <4B4F770B.1090909@nostrum.com> In-Reply-To: <4B4F770B.1090909@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2010 20:21:06.0438 (UTC) FILETIME=[19FFFA60:01CA9557] Cc: SIPCORE Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-info-events-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 20:21:11 -0000 Adam Roach wrote: > On 1/14/10 09:33, Jan 14, Paul Kyzivat wrote: >> Method =/ INFOm > > This is more important than it may seem at first, so I want to put > particular emphasis on it. > > Christer: please fix this issue before we pubreq the document. The other one of those I called out: message-header =/ (Info-Package / Recv-Info) CRLF is even *more* important, because it wasn't there in any form. Thanks, Paul From rjsparks@nostrum.com Thu Jan 14 13:09:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F4B3A69FC for ; Thu, 14 Jan 2010 13:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPYCXvWdaBED for ; Thu, 14 Jan 2010 13:09:29 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E58F03A69CF for ; Thu, 14 Jan 2010 13:09:25 -0800 (PST) Received: from [192.168.2.2] (pool-173-71-49-137.dllstx.fios.verizon.net [173.71.49.137]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0EL9Ick039155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Jan 2010 15:09:19 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> From: Robert Sparks To: Gonzalo Camarillo In-Reply-To: <4B4EFFF9.1030705@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 14 Jan 2010 15:09:18 -0600 References: <4B4EFFF9.1030705@ericsson.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 173.71.49.137 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 21:09:30 -0000 I just skimmed -04 and see a few of things to pay attention to. 1) The IANA considerations section is confusing. If I remember the conversation correctly, the group settled on "Specification Required". That's what the document should say. 2) I agree with Paul's BNF observation (I tried to point to that in my review of -01) 3) The document still requires putting Recv-INFO in an OPTIONS request. I continue to believe this is useless and should be removed. I think my other concerns have been addressed, but I haven't checked the minor/nit ones closely. Has anyone other than the authors reviewed the tables? RjS On Jan 14, 2010, at 5:28 AM, Gonzalo Camarillo wrote: > Hi, > > we intend to request the publication of this draft next week. If > there is no further comments on the draft, we will ask the authors > to fix the references problems reported by the ID nits tool below > and we will be requesting the publication of that revision. > > http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-sipcore-info-events-04.txt > > Thanks, > > Gonzalo > SIPCORE co-chair > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Thu Jan 14 13:14:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922383A69FF for ; Thu, 14 Jan 2010 13:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.38 X-Spam-Level: X-Spam-Status: No, score=-10.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyIPMtDC4-v7 for ; Thu, 14 Jan 2010 13:14:22 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C4AC728C0E2 for ; Thu, 14 Jan 2010 13:14:17 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG4XT0tAZnwN/2dsb2JhbADDaJR+hDAE X-IronPort-AV: E=Sophos;i="4.49,277,1262563200"; d="scan'208";a="80158073" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 14 Jan 2010 21:14:10 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.175]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0ELE7Bd015414; Thu, 14 Jan 2010 21:14:10 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 15:13:24 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 15:13:24 -0600 Message-ID: <4B4F88F3.7070409@cisco.com> Date: Thu, 14 Jan 2010 16:13:23 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Robert Sparks References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> In-Reply-To: <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2010 21:13:24.0770 (UTC) FILETIME=[68977020:01CA955E] Cc: SIPCORE Subject: Re: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 21:14:24 -0000 Robert Sparks wrote: > Has anyone other than the authors reviewed the tables? Casually - enough to notice the issue I pointed out. From pkyzivat@cisco.com Thu Jan 14 16:44:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1858C3A6886 for ; Thu, 14 Jan 2010 16:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.395 X-Spam-Level: X-Spam-Status: No, score=-10.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQGZauXW6+eL for ; Thu, 14 Jan 2010 16:44:57 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C1F033A67AA for ; Thu, 14 Jan 2010 16:44:55 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANJJT0urRN+J/2dsb2JhbADDQJUIhDAE X-IronPort-AV: E=Sophos;i="4.49,278,1262563200"; d="scan'208";a="74595294" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 15 Jan 2010 00:44:53 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0F0iqfH007212; Fri, 15 Jan 2010 00:44:53 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 18:44:53 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 18:44:52 -0600 Message-ID: <4B4FBA84.2040005@cisco.com> Date: Thu, 14 Jan 2010 19:44:52 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Robert Sparks References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> In-Reply-To: <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2010 00:44:52.0446 (UTC) FILETIME=[F30927E0:01CA957B] Cc: SIPCORE Subject: Re: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 00:44:58 -0000 Robert Sparks wrote: > 3) The document still requires putting Recv-INFO in an OPTIONS request. > I continue to believe this is useless and should be removed. I agree, but the problem is bigger than this draft. The whole concept that OPTIONS will tell you the capabilities of the UA is pretty broken - it assumes those are stable over time and are context free, which is often not the case. There are almost never any guarantees that the info you receive from OPTIONS will still be true if you try to act on it. The concept that the response code from OPTIONS should be the same as you would get were you to send an INVITE is even more broken. It doesn't work at all well for UAs that don't support INVITE. The definition of OPTIONS needs some serious rework. Thanks, Paul From root@core3.amsl.com Thu Jan 14 19:30:02 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EF6AF3A682E; Thu, 14 Jan 2010 19:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100115033001.EF6AF3A682E@core3.amsl.com> Date: Thu, 14 Jan 2010 19:30:01 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-subnot-etags-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 03:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification Author(s) : A. Niemi, D. Willis Filename : draft-ietf-sipcore-subnot-etags-04.txt Pages : 25 Date : 2010-01-14 The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 19, 2010.Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-subnot-etags-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-subnot-etags-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-14192805.I-D@ietf.org> --NextPart-- From gonzalo.camarillo@ericsson.com Thu Jan 14 23:58:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FE13A6922 for ; Thu, 14 Jan 2010 23:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.168 X-Spam-Level: X-Spam-Status: No, score=-106.168 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-JtHmm1P7Jz for ; Thu, 14 Jan 2010 23:58:15 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 7B2283A690A for ; Thu, 14 Jan 2010 23:58:11 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-ff-4b50200f059f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id B6.B2.04178.F00205B4; Fri, 15 Jan 2010 08:58:07 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 08:58:07 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 08:58:06 +0100 Message-ID: <4B50200B.9020806@ericsson.com> Date: Fri, 15 Jan 2010 09:58:03 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Paul Kyzivat References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> <4B4FBA84.2040005@cisco.com> In-Reply-To: <4B4FBA84.2040005@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2010 07:58:06.0798 (UTC) FILETIME=[78E07EE0:01CA95B8] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 07:58:15 -0000 Hi Paul, > I agree, but the problem is bigger than this draft. > > The whole concept that OPTIONS will tell you the capabilities of the UA > is pretty broken - it assumes those are stable over time and are context > free, which is often not the case. There are almost never any guarantees > that the info you receive from OPTIONS will still be true if you try to > act on it. > > The concept that the response code from OPTIONS should be the same as > you would get were you to send an INVITE is even more broken. It doesn't > work at all well for UAs that don't support INVITE. > > The definition of OPTIONS needs some serious rework. yes, this has come up several times in the past. When people try to use OPTIONS to provide a meaningful service, they fairly soon notice how broken it is. At some point, it could be interesting to gather a few requirements and try to fix it somehow. Cheers, Gonzalo From christer.holmberg@ericsson.com Fri Jan 15 00:12:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A469B3A68AA for ; Fri, 15 Jan 2010 00:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmvtCXO9zHJe for ; Fri, 15 Jan 2010 00:12:46 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 1F8C43A686E for ; Fri, 15 Jan 2010 00:12:45 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-32-4b502379b2cd Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 15.46.04178.973205B4; Fri, 15 Jan 2010 09:12:41 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 15 Jan 2010 09:12:41 +0100 From: Christer Holmberg To: Gonzalo Camarillo , Paul Kyzivat Date: Fri, 15 Jan 2010 09:12:40 +0100 Thread-Topic: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) Thread-Index: AcqVuH8Hv2gSfgfpQVSSRF4OB6yUiQAAev6Q Message-ID: References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> <4B4FBA84.2040005@cisco.com> <4B50200B.9020806@ericsson.com> In-Reply-To: <4B50200B.9020806@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 08:12:47 -0000 =20 Hi, So, what do I do? Change mandatory to optional? Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 15. tammikuuta 2010 9:58 > To: Paul Kyzivat > Cc: SIPCORE > Subject: [sipcore] OPTIONS requests WAS (Re: Requesting the=20 > publication of the draft-ietf-sipcore-info-events) >=20 > Hi Paul, >=20 > > I agree, but the problem is bigger than this draft. > >=20 > > The whole concept that OPTIONS will tell you the=20 > capabilities of the=20 > > UA is pretty broken - it assumes those are stable over time and are=20 > > context free, which is often not the case. There are almost=20 > never any=20 > > guarantees that the info you receive from OPTIONS will=20 > still be true=20 > > if you try to act on it. > >=20 > > The concept that the response code from OPTIONS should be=20 > the same as=20 > > you would get were you to send an INVITE is even more broken. It=20 > > doesn't work at all well for UAs that don't support INVITE. > >=20 > > The definition of OPTIONS needs some serious rework. >=20 > yes, this has come up several times in the past. When people=20 > try to use OPTIONS to provide a meaningful service, they=20 > fairly soon notice how broken it is. At some point, it could=20 > be interesting to gather a few requirements and try to fix it somehow. >=20 > Cheers, >=20 > Gonzalo >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From gonzalo.camarillo@ericsson.com Fri Jan 15 00:32:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03BB03A692A for ; Fri, 15 Jan 2010 00:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.116 X-Spam-Level: X-Spam-Status: No, score=-106.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1b2R1T7sJ8D for ; Fri, 15 Jan 2010 00:32:36 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id EC65C3A6934 for ; Fri, 15 Jan 2010 00:32:35 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-e9-4b50281f3477 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 1C.DA.04178.F18205B4; Fri, 15 Jan 2010 09:32:31 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 09:32:30 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 09:32:30 +0100 Message-ID: <4B50281E.1070901@ericsson.com> Date: Fri, 15 Jan 2010 10:32:30 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> <4B4FBA84.2040005@cisco.com> <4B50200B.9020806@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2010 08:32:30.0381 (UTC) FILETIME=[46DE45D0:01CA95BD] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 08:32:40 -0000 Hi Christer, the reason I had changed the subject of the thread was to keep discussions on the info events draft and on the possibility to work on fixing OPTIONS separate ;o) People appreciate having the right subjects on the right threads when they have to go back to the archives to look for something. Cheers, Gonzalo Christer Holmberg wrote: > > Hi, > > So, what do I do? Change mandatory to optional? > > Regards, > > Christer > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> Sent: 15. tammikuuta 2010 9:58 >> To: Paul Kyzivat >> Cc: SIPCORE >> Subject: [sipcore] OPTIONS requests WAS (Re: Requesting the >> publication of the draft-ietf-sipcore-info-events) >> >> Hi Paul, >> >>> I agree, but the problem is bigger than this draft. >>> >>> The whole concept that OPTIONS will tell you the >> capabilities of the >>> UA is pretty broken - it assumes those are stable over time and are >>> context free, which is often not the case. There are almost >> never any >>> guarantees that the info you receive from OPTIONS will >> still be true >>> if you try to act on it. >>> >>> The concept that the response code from OPTIONS should be >> the same as >>> you would get were you to send an INVITE is even more broken. It >>> doesn't work at all well for UAs that don't support INVITE. >>> >>> The definition of OPTIONS needs some serious rework. >> yes, this has come up several times in the past. When people >> try to use OPTIONS to provide a meaningful service, they >> fairly soon notice how broken it is. At some point, it could >> be interesting to gather a few requirements and try to fix it somehow. >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Fri Jan 15 00:39:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B693A695E for ; Fri, 15 Jan 2010 00:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.13 X-Spam-Level: X-Spam-Status: No, score=-6.13 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcNN7qvbLAq3 for ; Fri, 15 Jan 2010 00:39:08 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id D30DB3A694A for ; Fri, 15 Jan 2010 00:39:07 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-f9-4b5029a7e4db Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id EA.8C.04178.7A9205B4; Fri, 15 Jan 2010 09:39:03 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 15 Jan 2010 09:39:03 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Fri, 15 Jan 2010 09:39:03 +0100 From: Christer Holmberg To: Gonzalo Camarillo Date: Fri, 15 Jan 2010 09:39:02 +0100 Thread-Topic: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) Thread-Index: AcqVvUb1Vex4olwzSvCa5rYWdkHPMgAANJDA Message-ID: References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> <4B4FBA84.2040005@cisco.com> <4B50200B.9020806@ericsson.com> <4B50281E.1070901@ericsson.com> In-Reply-To: <4B50281E.1070901@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 08:39:09 -0000 Sorry. I thought you changed the subject in order to discuss the specific O= PTIONS comments given for the info draft. Regards, Christer=20 > -----Original Message----- > From: Gonzalo Camarillo=20 > Sent: 15. tammikuuta 2010 10:33 > To: Christer Holmberg > Cc: Paul Kyzivat; SIPCORE > Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting=20 > the publication of the draft-ietf-sipcore-info-events) >=20 > Hi Christer, >=20 > the reason I had changed the subject of the thread was to=20 > keep discussions on the info events draft and on the=20 > possibility to work on fixing OPTIONS separate ;o) >=20 > People appreciate having the right subjects on the right=20 > threads when they have to go back to the archives to look for=20 > something. >=20 > Cheers, >=20 > Gonzalo >=20 > Christer Holmberg wrote: > > =20 > > Hi, > >=20 > > So, what do I do? Change mandatory to optional? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > >> Sent: 15. tammikuuta 2010 9:58 > >> To: Paul Kyzivat > >> Cc: SIPCORE > >> Subject: [sipcore] OPTIONS requests WAS (Re: Requesting the=20 > >> publication of the draft-ietf-sipcore-info-events) > >> > >> Hi Paul, > >> > >>> I agree, but the problem is bigger than this draft. > >>> > >>> The whole concept that OPTIONS will tell you the > >> capabilities of the > >>> UA is pretty broken - it assumes those are stable over=20 > time and are=20 > >>> context free, which is often not the case. There are almost > >> never any > >>> guarantees that the info you receive from OPTIONS will > >> still be true > >>> if you try to act on it. > >>> > >>> The concept that the response code from OPTIONS should be > >> the same as > >>> you would get were you to send an INVITE is even more broken. It=20 > >>> doesn't work at all well for UAs that don't support INVITE. > >>> > >>> The definition of OPTIONS needs some serious rework. > >> yes, this has come up several times in the past. When=20 > people try to=20 > >> use OPTIONS to provide a meaningful service, they fairly=20 > soon notice=20 > >> how broken it is. At some point, it could be interesting=20 > to gather a=20 > >> few requirements and try to fix it somehow. > >> > >> Cheers, > >> > >> Gonzalo > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > = From john.elwell@siemens-enterprise.com Fri Jan 15 02:17:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291E93A694A for ; Fri, 15 Jan 2010 02:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onG5b1fbZqGm for ; Fri, 15 Jan 2010 02:17:51 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id DAB7B3A6944 for ; Fri, 15 Jan 2010 02:17:50 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-550064; Fri, 15 Jan 2010 11:17:47 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id EE5B01EB82A7; Fri, 15 Jan 2010 11:17:46 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 15 Jan 2010 11:17:46 +0100 From: "Elwell, John" To: Christer Holmberg , Gonzalo Camarillo Date: Fri, 15 Jan 2010 11:17:45 +0100 Thread-Topic: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) Thread-Index: AcqVvUb1Vex4olwzSvCa5rYWdkHPMgAANJDAAANffaA= Message-ID: References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> <4B4FBA84.2040005@cisco.com> <4B50200B.9020806@ericsson.com> <4B50281E.1070901@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 10:17:52 -0000 There is not a lot of point in adding to something that is already broken, = so I tend to agree with Robert. I had not commented on this in the past, bu= t I never saw a lot of use for Recv-Info in OPTIONS (I just saw it as harml= ess), but given the concerns voiced by Robert and Paul I would avoid adding= to the known problem. John=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 15 January 2010 08:39 > To: Gonzalo Camarillo > Cc: SIPCORE > Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting=20 > the publication of the draft-ietf-sipcore-info-events) >=20 >=20 > Sorry. I thought you changed the subject in order to discuss=20 > the specific OPTIONS comments given for the info draft. >=20 > Regards, >=20 > Christer=20 >=20 > > -----Original Message----- > > From: Gonzalo Camarillo=20 > > Sent: 15. tammikuuta 2010 10:33 > > To: Christer Holmberg > > Cc: Paul Kyzivat; SIPCORE > > Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting=20 > > the publication of the draft-ietf-sipcore-info-events) > >=20 > > Hi Christer, > >=20 > > the reason I had changed the subject of the thread was to=20 > > keep discussions on the info events draft and on the=20 > > possibility to work on fixing OPTIONS separate ;o) > >=20 > > People appreciate having the right subjects on the right=20 > > threads when they have to go back to the archives to look for=20 > > something. > >=20 > > Cheers, > >=20 > > Gonzalo > >=20 > > Christer Holmberg wrote: > > > =20 > > > Hi, > > >=20 > > > So, what do I do? Change mandatory to optional? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >> -----Original Message----- > > >> From: sipcore-bounces@ietf.org > > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > > >> Sent: 15. tammikuuta 2010 9:58 > > >> To: Paul Kyzivat > > >> Cc: SIPCORE > > >> Subject: [sipcore] OPTIONS requests WAS (Re: Requesting the=20 > > >> publication of the draft-ietf-sipcore-info-events) > > >> > > >> Hi Paul, > > >> > > >>> I agree, but the problem is bigger than this draft. > > >>> > > >>> The whole concept that OPTIONS will tell you the > > >> capabilities of the > > >>> UA is pretty broken - it assumes those are stable over=20 > > time and are=20 > > >>> context free, which is often not the case. There are almost > > >> never any > > >>> guarantees that the info you receive from OPTIONS will > > >> still be true > > >>> if you try to act on it. > > >>> > > >>> The concept that the response code from OPTIONS should be > > >> the same as > > >>> you would get were you to send an INVITE is even more=20 > broken. It=20 > > >>> doesn't work at all well for UAs that don't support INVITE. > > >>> > > >>> The definition of OPTIONS needs some serious rework. > > >> yes, this has come up several times in the past. When=20 > > people try to=20 > > >> use OPTIONS to provide a meaningful service, they fairly=20 > > soon notice=20 > > >> how broken it is. At some point, it could be interesting=20 > > to gather a=20 > > >> few requirements and try to fix it somehow. > > >> > > >> Cheers, > > >> > > >> Gonzalo > > >> > > >> _______________________________________________ > > >> sipcore mailing list > > >> sipcore@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sipcore > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Fri Jan 15 04:17:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52FE33A6960 for ; Fri, 15 Jan 2010 04:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.136 X-Spam-Level: X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TE9H3aouMQmo for ; Fri, 15 Jan 2010 04:17:53 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 4B7EC3A67B3 for ; Fri, 15 Jan 2010 04:17:53 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-11-4b505cecaa16 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 39.06.04178.CEC505B4; Fri, 15 Jan 2010 13:17:49 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 15 Jan 2010 13:17:48 +0100 From: Christer Holmberg To: Paul Kyzivat , SIPCORE Date: Fri, 15 Jan 2010 13:17:47 +0100 Thread-Topic: [sipcore] I-D Action:draft-ietf-sipcore-info-events-04.txt - Paul's comments Thread-Index: AcqVLvYiW3OWACteRfuuhn7QlqrcywAklOPA Message-ID: References: <20100114080001.CB2253A694D@core3.amsl.com> <4B4F3952.7060703@cisco.com> In-Reply-To: <4B4F3952.7060703@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-info-events-04.txt - Paul's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 12:17:55 -0000 Hi,=20 >Abstract: >=20 >NIT: "This document defines a new method, INFO, ..." >Such statements never age well, and that is especially the=20 >case for a revision document. How about just "This document=20 >defines a method, INFO, ..."? (This correction should also be=20 >made to section 1 -Introduction, and section 2 - Applicability.) Fixed. ----------------- =20 >Section 3.3.1: >=20 > When a UA supports a specific Info-Package, the UA also=20 > support all message body MIME types associated with that=20 > Info-Package. However, in accordance with [RFC3261] the UA=20 > still indicates the supported MIME types using the Accept header. >=20 > Is there supposed to be something normative here? As stated=20 > there isn't.=20 > Perhaps: >=20 > When a UA supports a specific Info-Package, the UA MUST=20 > also support message body MIME types in accord with that Info-Package. > However, in accordance with [RFC3261] the UA still indicates the > supported MIME types using the Accept header. >=20 > (I said "in accord" rather than "all" in the above because=20 > some info package specifications might define mime type=20 > alternatives in a way that doesn't require all to be supported.) In principle the change looks good, but could "in accord" be something whic= h non-english people have troubles to understand? Could we say "in accordance with that Info-Package"? ----------------- =20 >Section 3.4: >=20 > If specific applications need additional mechanisms for order of > delivery, those mechanisms, and related procedures, are=20 > specified as part of the associated Info Package, and possible sequence n= umbers > etc must be defined as application data. >=20 > The non-normative "must" seems awkward. How about: >=20 > If specific applications need additional mechanisms for order of > delivery, those mechanisms, and related procedures, are specified as > part of the associated Info Package. (E.g. the use of sequence > numbers within the application data.) Fixed. ----------------- >Section 4.4.2: >=20 >Nit: "Recv-Info" is misspelled as "Revc-Info" at least once. Fixed. ----------------- >The following: >=20 > Once a UA has sent a set of Info Packages, the set is=20 > valid until the UA sends a new set, or an empty Recv-Info header field. >=20 > could be construed to mean INFO messages have been sent=20 > containing certain Info Packages. How about: >=20 > Once a UA has sent a message with a Recv-Info header=20 > field containing a set of Info Packages, the set is=20 > valid until the UA sends a new Recv-Info header field=20 > containing a new, or empty set. Fixed. "Once a UA has sent a message with a Recv-Info header field containing a se= t=20 of Info Packages, the set is valid until the UA sends a new Recv-Info=20 header field containing a new, or empty, set of Info Packages." ----------------- >Section 4.2.3: >=20 > NOTE: Similar to SDP answers, the receiver can include=20 > the same Recv-Info header field value in multiple responses (18x/2xx)=20 > for the same INVITE/re-INVITE transaction, but the receiver is not allowe= d to > include a Recv-Info header field value which is different from a > value that the receiver has already included in a response for the > same transaction. >=20 > I think "the receiver is not allowed" is intended to be=20 > normative. But the language isn't normative. If it is indeed=20 > intended to be normative this needs to be rewritten. >=20 > Section 6.1: >=20 > Why is Info-Package permitted in 469? Is the expectation that=20 > the UAS will copy the Info-Package header (but not the body)=20 > from the request into the response? If so, then there ought=20 > to be some text somewhere that says that. But why bother? It=20 > would be more useful to include the Recv-Info header in the=20 > 469 response. (That would require added specification, since=20 > it is currently forbidden to do so.) I agree that Recv-Info makes more sense. I guess we could add the following clarification text to section 3.2.2: "If a UA receives an INFO request associated with an Info Package that the UA has not indicated willingness to receive, the UA MUST send a 469 (Bad INFO Package) response (see Section 11.6), which contains a R= ecv-Info Header field with Info Packages for which the UA is willing to receive INFO requests. The UA MUST NOT use the response to update the set of Info Packages, but simply to indicate the current set. In the terminology of Multiple Dialog Usages [RFC5057], this represents a Transaction Only failure, and does not terminate the invite dialog usage." ----------------- >There is trouble with the formatting of the paragraph=20 >following the table: >=20 >The support and usage of the Info-Package and Recv-Info=20 >header fields is not applicalbe to UAs that only support legacy INFO=20 >usages. * Not applicalbe to INFO requests and responses associated with=20 >legacy INFO usages. ** Mandatory in at least one reliable 18x/2xx response= , if >sent, to the INVITE request, if the associated INVITE request >contained a Recv-Info header field. *** Mandatory if the associated >request contained a Recv-Info header field. >=20 >Should presumably be: >=20 > The support and usage of the Info-Package and Recv-Info header fields > is not applicable to UAs that only support legacy INFO usages. >=20 > * Not applicable to INFO requests and responses associated with > legacy INFO usages. >=20 > ** Mandatory in at least one reliable 18x/2xx response, if > sent, to the INVITE request, if the associated INVITE request > contained a Recv-Info header field. >=20 > *** Mandatory if the associated request contained a Recv-Info header > field. Fixed. ----------------- =20 >Section 7.4.1.3: NIT: s/ser/user/ Fixed. ----------------- >Section 8.2: >=20 >There is a preferred method for defining extensions now: >=20 > Method =3D/ INFOm >=20 >Also, the following is missing but needed: >=20 > message-header =3D/ (Info-Package / Recv-Info) CRLF >=20 >However these changes will require referencing RFC 5234 I added a refernce to 5243 in the normative reference section. Where do you want a reference in the text? Somewhere in section 8.1? The text currently says: "This section describes the syntax extensions required for the INFO method, and for the Info-Package and Recv-Info header fields. The previous sections describe the semantics. Note the formal syntax definitions described in this document use the ABNF format used in [RFC3261] and contain references to elements defined therein." 3261 refers to 2234 for ABNF, but maybe that doesn't matter. Maybe we could say something like: "This section describes the syntax extensions to the ABNF format defined in= [RFC3261] required for the INFO method, and for the Info-Package and Recv-Info header fields. The previous = sections describe the semantics.=20 The ABNF defined in this specification is conformant to [RFC5234]." ----------------- >Section 10.4: >=20 >The cross reference to section 10.5 is wrong. And I'm not=20 >certain what the correct value is - perhaps 11.4??? It seems like some old text, that should have gone as part of some restruct= uring. I suggest to remove the paragraph. ----------------- Regards, Christer= From christer.holmberg@ericsson.com Fri Jan 15 04:27:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1C73A6960 for ; Fri, 15 Jan 2010 04:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.14 X-Spam-Level: X-Spam-Status: No, score=-6.14 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv+rIh3l6JnW for ; Fri, 15 Jan 2010 04:27:39 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id D1E2F3A69CA for ; Fri, 15 Jan 2010 04:27:38 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-28-4b505f363800 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id EB.78.04178.63F505B4; Fri, 15 Jan 2010 13:27:34 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 15 Jan 2010 13:27:33 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Fri, 15 Jan 2010 13:27:33 +0100 From: Christer Holmberg To: Robert Sparks , Gonzalo Camarillo Date: Fri, 15 Jan 2010 13:27:32 +0100 Thread-Topic: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments Thread-Index: AcqVXd3i/cyvYsaKTwCyuRtxbYFyDgAf1Tgg Message-ID: References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> In-Reply-To: <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 12:27:40 -0000 =20 Hi, >I just skimmed -04 and see a few of things to pay attention to. >=20 >1) The IANA considerations section is confusing. If I=20 >remember the conversation correctly, the group settled on=20 >"Specification Required". That's what the document should say. Section 11.4, which describes the content of the registrary, contains a bul= let which says: "o Reference: A reference to a specification which describes the Info Pack= age." --------------- >2) I agree with Paul's BNF observation (I tried to point to=20 >that in my review of -01) Please se my reply to Paul. --------------- >3) The document still requires putting Recv-INFO in an=20 >OPTIONS request. I have changed it to optional, and modified the text in section 4.4 to: "...the UA MAY include Recv-Info header field in the message..." Or, is that still too much? Do you want to remove section 4.4? Regards, Christer From john.elwell@siemens-enterprise.com Fri Jan 15 05:27:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FFE63A68A3 for ; Fri, 15 Jan 2010 05:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLNgcRXOG2uO for ; Fri, 15 Jan 2010 05:27:34 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 1573A3A672F for ; Fri, 15 Jan 2010 05:27:33 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-553490; Fri, 15 Jan 2010 14:27:30 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 01F3E23F0278; Fri, 15 Jan 2010 14:27:30 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 15 Jan 2010 14:27:29 +0100 From: "Elwell, John" To: Christer Holmberg , Robert Sparks , Gonzalo Camarillo Date: Fri, 15 Jan 2010 14:27:29 +0100 Thread-Topic: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments Thread-Index: AcqVXd3i/cyvYsaKTwCyuRtxbYFyDgAf1TggAAJHTRA= Message-ID: References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE Subject: Re: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 13:27:35 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 15 January 2010 12:28 > To: Robert Sparks; Gonzalo Camarillo > Cc: SIPCORE > Subject: Re: [sipcore] Requesting the publication of the=20 > draft-ietf-sipcore-info-events - Robert's comments >=20 > =20 > Hi, >=20 > >I just skimmed -04 and see a few of things to pay attention to. > >=20 > >1) The IANA considerations section is confusing. If I=20 > >remember the conversation correctly, the group settled on=20 > >"Specification Required". That's what the document should say. >=20 > Section 11.4, which describes the content of the registrary,=20 > contains a bullet which says: >=20 > "o Reference: A reference to a specification which describes=20 > the Info Package." >=20 > --------------- >=20 > >2) I agree with Paul's BNF observation (I tried to point to=20 > >that in my review of -01) >=20 > Please se my reply to Paul. >=20 > --------------- >=20 > >3) The document still requires putting Recv-INFO in an=20 > >OPTIONS request. >=20 > I have changed it to optional, and modified the text in=20 > section 4.4 to: >=20 > "...the UA MAY include Recv-Info header field in the message..." >=20 > Or, is that still too much? Do you want to remove section 4.4? [JRE] Well, if you do choose to include it, what does it mean to the recipi= ent? Isn't it simpler to remove it altogether? John >=20 > Regards, >=20 > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Fri Jan 15 06:16:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2A1228C0D6 for ; Fri, 15 Jan 2010 06:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.398 X-Spam-Level: X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1HzlNzN5EhE for ; Fri, 15 Jan 2010 06:16:32 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D1A2C3A6AA4 for ; Fri, 15 Jan 2010 06:16:32 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADMHUEutJV2Y/2dsb2JhbADEUJR5hDEE X-IronPort-AV: E=Sophos;i="4.49,282,1262563200"; d="scan'208";a="467380543" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 15 Jan 2010 14:16:29 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o0FEGTn1009871; Fri, 15 Jan 2010 14:16:29 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 08:16:29 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 08:16:29 -0600 Message-ID: <4B5078BC.6020606@cisco.com> Date: Fri, 15 Jan 2010 09:16:28 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> <4B4FBA84.2040005@cisco.com> <4B50200B.9020806@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2010 14:16:29.0155 (UTC) FILETIME=[54894330:01CA95ED] Cc: SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 14:16:33 -0000 Christer Holmberg wrote: > > Hi, > > So, what do I do? Change mandatory to optional? Works for me. Paul > Regards, > > Christer > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> Sent: 15. tammikuuta 2010 9:58 >> To: Paul Kyzivat >> Cc: SIPCORE >> Subject: [sipcore] OPTIONS requests WAS (Re: Requesting the >> publication of the draft-ietf-sipcore-info-events) >> >> Hi Paul, >> >>> I agree, but the problem is bigger than this draft. >>> >>> The whole concept that OPTIONS will tell you the >> capabilities of the >>> UA is pretty broken - it assumes those are stable over time and are >>> context free, which is often not the case. There are almost >> never any >>> guarantees that the info you receive from OPTIONS will >> still be true >>> if you try to act on it. >>> >>> The concept that the response code from OPTIONS should be >> the same as >>> you would get were you to send an INVITE is even more broken. It >>> doesn't work at all well for UAs that don't support INVITE. >>> >>> The definition of OPTIONS needs some serious rework. >> yes, this has come up several times in the past. When people >> try to use OPTIONS to provide a meaningful service, they >> fairly soon notice how broken it is. At some point, it could >> be interesting to gather a few requirements and try to fix it somehow. >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From christer.holmberg@ericsson.com Fri Jan 15 06:19:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AAC33A6AA4 for ; Fri, 15 Jan 2010 06:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.137 X-Spam-Level: X-Spam-Status: No, score=-6.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ6dRxBA9gJW for ; Fri, 15 Jan 2010 06:19:51 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 01EA63A6A9E for ; Fri, 15 Jan 2010 06:19:50 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-13-4b5079821d88 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id C1.B0.04178.289705B4; Fri, 15 Jan 2010 15:19:46 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 15 Jan 2010 15:19:45 +0100 From: Christer Holmberg To: "Elwell, John" , Robert Sparks , Gonzalo Camarillo Date: Fri, 15 Jan 2010 15:19:44 +0100 Thread-Topic: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments Thread-Index: AcqVXd3i/cyvYsaKTwCyuRtxbYFyDgAf1TggAAJHTRAAAb+/4A== Message-ID: References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 14:19:52 -0000 Hi,=20 =20 >>>3)The document still requires putting Recv-INFO in an OPTIONS=20 >>>request. >>=20 >>I have changed it to optional, and modified the text in section 4.4=20 >>to: >>=20 >>"...the UA MAY include Recv-Info header field in the message..." >>=20 >>Or, is that still too much? Do you want to remove section 4.4? >[JRE] Well, if you do choose to include it, what does it mean=20 >to the recipient? Isn't it simpler to remove it altogether? I can do that.=20 I would like to keep the "o" in table 6.1, though, in order to not disallow= it, when we in future have "fixed" OPTIONS. Regards, Christer = From rjsparks@nostrum.com Fri Jan 15 07:07:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A3E93A6ACE for ; Fri, 15 Jan 2010 07:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdBQhu8v9R-T for ; Fri, 15 Jan 2010 07:07:34 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 1180E3A690B for ; Fri, 15 Jan 2010 07:07:33 -0800 (PST) Received: from [192.168.2.2] (pool-173-71-49-137.dllstx.fios.verizon.net [173.71.49.137]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0FF7QNv024674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Jan 2010 09:07:27 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <36779DD5-7C2A-4610-A0E8-A032DF581305@nostrum.com> From: Robert Sparks To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 15 Jan 2010 09:07:26 -0600 References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 173.71.49.137 is authenticated by a trusted mechanism) Cc: SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 15:07:35 -0000 On Jan 15, 2010, at 8:19 AM, Christer Holmberg wrote: > > Hi, > >>>> 3)The document still requires putting Recv-INFO in an OPTIONS >>>> request. >>> >>> I have changed it to optional, and modified the text in section 4.4 >>> to: >>> >>> "...the UA MAY include Recv-Info header field in the message..." >>> >>> Or, is that still too much? Do you want to remove section 4.4? That's my preference. I have had conversations with others that think having the value appear in a response might be reasonable. The group should express some consensus here. Again, I think the section should be deleted. >> [JRE] Well, if you do choose to include it, what does it mean >> to the recipient? Isn't it simpler to remove it altogether? > > I can do that. > > I would like to keep the "o" in table 6.1, though, in order to not > disallow it, when we in future have "fixed" OPTIONS. If the group decides to remove the section, that's an inappropriate thing to do. There is already text in the base spec that talks about how elements should be robust and ignore headers showing up where they shouldn't. Having a "-" in this table would not constrain future specs from making it allowed. That same "fixed" OPTIONS can modify the table when it's appropriate for the message to appear. > > Regards, > > Christer From pkyzivat@cisco.com Fri Jan 15 07:14:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54563A6A2C for ; Fri, 15 Jan 2010 07:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.41 X-Spam-Level: X-Spam-Status: No, score=-10.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xZEOytRNZc1 for ; Fri, 15 Jan 2010 07:13:59 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E97D63A6A15 for ; Fri, 15 Jan 2010 07:13:56 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE0VUEutJV2d/2dsb2JhbADEMZUDhDEE X-IronPort-AV: E=Sophos;i="4.49,282,1262563200"; d="scan'208";a="467405558" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-6.cisco.com with ESMTP; 15 Jan 2010 15:13:54 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o0FFDrtb017991; Fri, 15 Jan 2010 15:13:53 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 09:13:53 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 09:13:53 -0600 Message-ID: <4B508630.4050004@cisco.com> Date: Fri, 15 Jan 2010 10:13:52 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <20100114080001.CB2253A694D@core3.amsl.com> <4B4F3952.7060703@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2010 15:13:53.0318 (UTC) FILETIME=[596AD460:01CA95F5] Cc: SIPCORE Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-info-events-04.txt - Paul's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 15:14:15 -0000 Trimming to things that are worthy of further discussion... Christer Holmberg wrote: >> Section 3.3.1: >> >> When a UA supports a specific Info-Package, the UA also >> support all message body MIME types associated with that >> Info-Package. However, in accordance with [RFC3261] the UA >> still indicates the supported MIME types using the Accept header. >> >> Is there supposed to be something normative here? As stated >> there isn't. >> Perhaps: >> >> When a UA supports a specific Info-Package, the UA MUST >> also support message body MIME types in accord with that Info-Package. >> However, in accordance with [RFC3261] the UA still indicates the >> supported MIME types using the Accept header. >> >> (I said "in accord" rather than "all" in the above because >> some info package specifications might define mime type >> alternatives in a way that doesn't require all to be supported.) > > In principle the change looks good, but could "in accord" be something which non-english people have troubles to understand? You are a better judge of that than I am, since I only speak English. :-) > Could we say "in accordance with that Info-Package"? That seems fine, better than what I proposed. > ----------------- > >> Section 4.2.3: >> >> NOTE: Similar to SDP answers, the receiver can include >> the same Recv-Info header field value in multiple responses (18x/2xx) >> for the same INVITE/re-INVITE transaction, but the receiver is not allowed to >> include a Recv-Info header field value which is different from a >> value that the receiver has already included in a response for the >> same transaction. >> >> I think "the receiver is not allowed" is intended to be >> normative. But the language isn't normative. If it is indeed >> intended to be normative this needs to be rewritten. You didn't comment on the above. Do you agree that this ought to be normative? >> Section 6.1: >> >> Why is Info-Package permitted in 469? Is the expectation that >> the UAS will copy the Info-Package header (but not the body) >> from the request into the response? If so, then there ought >> to be some text somewhere that says that. But why bother? It >> would be more useful to include the Recv-Info header in the >> 469 response. (That would require added specification, since >> it is currently forbidden to do so.) > > I agree that Recv-Info makes more sense. > > I guess we could add the following clarification text to section 3.2.2: > > "If a UA receives an INFO request associated with an Info Package that > the UA has not indicated willingness to receive, the UA MUST send a > 469 (Bad INFO Package) response (see Section 11.6), which contains a Recv-Info > Header field with Info Packages for which the UA is willing to receive > INFO requests. The UA MUST NOT use the response to update the set of Info > Packages, but simply to indicate the current set. In the > terminology of Multiple Dialog Usages [RFC5057], this represents a > Transaction Only failure, and does not terminate the invite dialog > usage." That seems reasonable to me. But then you also need to update the table in 6.1 to show that Recv-Info is permitted in 469 responses. > ----------------- > >> Section 8.2: >> >> There is a preferred method for defining extensions now: >> >> Method =/ INFOm >> >> Also, the following is missing but needed: >> >> message-header =/ (Info-Package / Recv-Info) CRLF >> >> However these changes will require referencing RFC 5234 > > I added a refernce to 5243 in the normative reference section. > > Where do you want a reference in the text? Somewhere in section 8.1? > > The text currently says: > > "This section describes the syntax extensions required for the INFO > method, and for the Info-Package and Recv-Info header fields. The > previous sections describe the semantics. Note the formal syntax > definitions described in this document use the ABNF format used in > [RFC3261] and contain references to elements defined therein." > > 3261 refers to 2234 for ABNF, but maybe that doesn't matter. > > Maybe we could say something like: > > "This section describes the syntax extensions to the ABNF format defined in [RFC3261] required for the INFO > method, and for the Info-Package and Recv-Info header fields. The previous sections describe the semantics. > The ABNF defined in this specification is conformant to [RFC5234]." Almost. I suggest: "This section describes the syntax extensions to the ABNF syntax defined in [RFC3261] required for the INFO method, and adds definitions for the Info-Package and Recv-Info header fields. The previous sections describe the semantics. The ABNF defined in this specification is conformant to [RFC5234]." > ----------------- > >> Section 10.4: >> >> The cross reference to section 10.5 is wrong. And I'm not >> certain what the correct value is - perhaps 11.4??? > > It seems like some old text, that should have gone as part of some restructuring. > > I suggest to remove the paragraph. ok. Thanks, Paul From pkyzivat@cisco.com Fri Jan 15 07:31:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D334B3A6AF4 for ; Fri, 15 Jan 2010 07:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.415 X-Spam-Level: X-Spam-Status: No, score=-10.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lceoPUH8MEs for ; Fri, 15 Jan 2010 07:31:26 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id DF75F3A6856 for ; Fri, 15 Jan 2010 07:31:26 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAD4ZUEurRN+K/2dsb2JhbADEFJUDhDEE X-IronPort-AV: E=Sophos;i="4.49,282,1262563200"; d="scan'208";a="74906423" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 15 Jan 2010 15:31:24 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0FFVNxc004203; Fri, 15 Jan 2010 15:31:23 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 09:31:23 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 09:31:23 -0600 Message-ID: <4B508A4A.9020009@cisco.com> Date: Fri, 15 Jan 2010 10:31:22 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Robert Sparks References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> <36779DD5-7C2A-4610-A0E8-A032DF581305@nostrum.com> In-Reply-To: <36779DD5-7C2A-4610-A0E8-A032DF581305@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2010 15:31:23.0569 (UTC) FILETIME=[CB6A6A10:01CA95F7] Cc: SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 15:31:27 -0000 I previously indicated I was ok with making this optional in OPTIONS. But I'm ok with excluding it from OPTIONS too. Regardless, in practice I'm going to recommend that implementors ignore it in the response to OPTIONS. Paul Robert Sparks wrote: > > On Jan 15, 2010, at 8:19 AM, Christer Holmberg wrote: > >> >> Hi, >> >>>>> 3)The document still requires putting Recv-INFO in an OPTIONS >>>>> request. >>>> >>>> I have changed it to optional, and modified the text in section 4.4 >>>> to: >>>> >>>> "...the UA MAY include Recv-Info header field in the message..." >>>> >>>> Or, is that still too much? Do you want to remove section 4.4? > > That's my preference. I have had conversations with others that > think having the value appear in a response might be reasonable. > The group should express some consensus here. > Again, I think the section should be deleted. > >>> [JRE] Well, if you do choose to include it, what does it mean >>> to the recipient? Isn't it simpler to remove it altogether? >> >> I can do that. >> >> I would like to keep the "o" in table 6.1, though, in order to not >> disallow it, when we in future have "fixed" OPTIONS. > > If the group decides to remove the section, that's an inappropriate > thing to do. > There is already text in the base spec that talks about how elements > should be robust and ignore headers showing > up where they shouldn't. Having a "-" in this table would not constrain > future specs from making it allowed. > That same "fixed" OPTIONS can modify the table when it's appropriate for > the message to appear. > >> >> Regards, >> >> Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From rjsparks@nostrum.com Fri Jan 15 07:37:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0273A6856 for ; Fri, 15 Jan 2010 07:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEg9oMTIHgJ7 for ; Fri, 15 Jan 2010 07:37:56 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E12123A6829 for ; Fri, 15 Jan 2010 07:37:55 -0800 (PST) Received: from [192.168.2.2] (pool-173-71-49-137.dllstx.fios.verizon.net [173.71.49.137]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0FFbnsr027066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Jan 2010 09:37:49 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 15 Jan 2010 09:37:48 -0600 References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 173.71.49.137 is authenticated by a trusted mechanism) Cc: SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 15:37:57 -0000 On Jan 15, 2010, at 6:27 AM, Christer Holmberg wrote: > > Hi, > >> I just skimmed -04 and see a few of things to pay attention to. >> >> 1) The IANA considerations section is confusing. If I >> remember the conversation correctly, the group settled on >> "Specification Required". That's what the document should say. > > Section 11.4, which describes the content of the registrary, > contains a bullet which says: > > "o Reference: A reference to a specification which describes the > Info Package." "Specification Required" is a special string that is easy for IANA to recognize. The section should contain this sentence: "The registration policy for this document is Specification Required [RFC5226]." It does not need to try to explain what Specification Required means. RFC5226 does that. > > --------------- > >> 2) I agree with Paul's BNF observation (I tried to point to >> that in my review of -01) > > Please se my reply to Paul. > > --------------- > >> 3) The document still requires putting Recv-INFO in an >> OPTIONS request. > > I have changed it to optional, and modified the text in section 4.4 > to: > > "...the UA MAY include Recv-Info header field in the message..." > > Or, is that still too much? Do you want to remove section 4.4? > > Regards, > > Christer From christer.holmberg@ericsson.com Fri Jan 15 13:26:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1153A6971 for ; Fri, 15 Jan 2010 13:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeIQ0t895uQa for ; Fri, 15 Jan 2010 13:26:01 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 7780A3A68FA for ; Fri, 15 Jan 2010 13:26:00 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-7f-4b50dd63d2ef Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 7D.CB.04178.36DD05B4; Fri, 15 Jan 2010 22:25:56 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 15 Jan 2010 22:25:55 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , Robert Sparks Date: Fri, 15 Jan 2010 22:25:55 +0100 Thread-Topic: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments Thread-Index: AcqV983Qday1WQF/TRer/U+HClAuQAAMWXlQ Message-ID: References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> <36779DD5-7C2A-4610-A0E8-A032DF581305@nostrum.com> <4B508A4A.9020009@cisco.com> In-Reply-To: <4B508A4A.9020009@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 21:26:02 -0000 Hi,=20 >I previously indicated I was ok with making this optional in OPTIONS. >But I'm ok with excluding it from OPTIONS too. Regardless, in practice I'm= going to recommend that implementors ignore it in the response to OPTIONS. I'll remove the section and change it to "-" in the table. Regards, Christer From christer.holmberg@ericsson.com Fri Jan 15 13:32:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC593A68FA for ; Fri, 15 Jan 2010 13:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.145 X-Spam-Level: X-Spam-Status: No, score=-6.145 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX3+SMafMiGN for ; Fri, 15 Jan 2010 13:32:41 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id F0C183A6971 for ; Fri, 15 Jan 2010 13:32:40 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-62-4b50def48cf1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id A0.2C.04178.4FED05B4; Fri, 15 Jan 2010 22:32:36 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.83) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 15 Jan 2010 22:32:36 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Fri, 15 Jan 2010 22:32:36 +0100 From: Christer Holmberg To: 'Robert Sparks' Date: Fri, 15 Jan 2010 22:32:35 +0100 Thread-Topic: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments Thread-Index: AcqV9Hb+AVZaiXlwTmKjB8oVVY1ZsgANSwqA Message-ID: References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> <36779DD5-7C2A-4610-A0E8-A032DF581305@nostrum.com> In-Reply-To: <36779DD5-7C2A-4610-A0E8-A032DF581305@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 21:32:42 -0000 Hi,=20 >>>> 3)The document still requires putting Recv-INFO in an OPTIONS=20 >>>> request. >>> >>> I have changed it to optional, and modified the text in section 4.4 >>> to: >>> >>> "...the UA MAY include Recv-Info header field in the message..." >>> >>> Or, is that still too much? Do you want to remove section 4.4? > >That's my preference. I have had conversations with others that think havi= ng the value appear in a response might be reasonable. >The group should express some consensus here. >Again, I think the section should be deleted. Gone it will be. >>[JRE] Well, if you do choose to include it, what does it mean to the=20 >>recipient? Isn't it simpler to remove it altogether? > >I can do that. > >I would like to keep the "o" in table 6.1, though, in order to not=20 >disallow it, when we in future have "fixed" OPTIONS. > >If the group decides to remove the section, that's an inappropriate thing = to do. >There is already text in the base spec that talks about how elements shoul= d be robust and ignore headers showing up where they shouldn't. Having a "-= " in this table would not constrain future specs from=20 >making it allowed. >That same "fixed" OPTIONS can modify the table when it's appropriate for t= he message to appear. I will modify it to "-" in the table. Regards, Christer From christer.holmberg@ericsson.com Fri Jan 15 13:40:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 029ED3A6925 for ; Fri, 15 Jan 2010 13:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra+EyO3x6A2z for ; Fri, 15 Jan 2010 13:40:24 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 49DC93A6784 for ; Fri, 15 Jan 2010 13:40:23 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-d5-4b50e0c3c90f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 58.6C.04178.3C0E05B4; Fri, 15 Jan 2010 22:40:20 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 15 Jan 2010 22:40:19 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Fri, 15 Jan 2010 22:40:19 +0100 From: Christer Holmberg To: 'Paul Kyzivat' Date: Fri, 15 Jan 2010 22:40:18 +0100 Thread-Topic: [sipcore] I-D Action:draft-ietf-sipcore-info-events-04.txt - Paul's comments Thread-Index: AcqV9Vw+3g2Hi+oWTG2fULsr6HuZMwANQgZw Message-ID: References: <20100114080001.CB2253A694D@core3.amsl.com> <4B4F3952.7060703@cisco.com> <4B508630.4050004@cisco.com> In-Reply-To: <4B508630.4050004@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-info-events-04.txt - Paul's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 21:40:26 -0000 Hi,=20 >>> Section 3.3.1: >>> >>> When a UA supports a specific Info-Package, the UA also support all=20 >>> message body MIME types associated with that Info-Package. However,=20 >>> in accordance with [RFC3261] the UA still indicates the supported=20 >>> MIME types using the Accept header. >>> >>> Is there supposed to be something normative here? As stated there=20 >>> isn't. >>> Perhaps: >>> >>> When a UA supports a specific Info-Package, the UA MUST also support=20 >>> message body MIME types in accord with that Info-Package. >>> However, in accordance with [RFC3261] the UA still indicates the=20 >>> supported MIME types using the Accept header. >>> >>> (I said "in accord" rather than "all" in the above because some info=20 >>> package specifications might define mime type alternatives in a way=20 >>> that doesn't require all to be supported.) >>=20 >> In principle the change looks good, but could "in accord" be something w= hich non-english people have troubles to understand? > >You are a better judge of that than I am, since I only speak English. :-) I wouldn't have understood it at least :) >>Could we say "in accordance with that Info-Package"? > >That seems fine, better than what I proposed. Good. ----------------- =20 >> Section 4.2.3: >> >> NOTE: Similar to SDP answers, the receiver can include the same=20 >> Recv-Info header field value in multiple responses (18x/2xx) for the=20 >> same INVITE/re-INVITE transaction, but the receiver is not allowed to=20 >> include a Recv-Info header field value which is different from a=20 >> value that the receiver has already included in a response for the=20 >> same transaction. >> >> I think "the receiver is not allowed" is intended to be normative.=20 >> But the language isn't normative. If it is indeed intended to be=20 >> normative this needs to be rewritten. > >You didn't comment on the above. >Do you agree that this ought to be normative? Sorry, I forgot to write down my comment earlier. Yes, I agree to making it normaive. I suggest to simply remove "NOTE:". Also, I suggest to change "is not allowed" to "MUST NOT". ----------------- >>> Section 6.1: >>> >>> Why is Info-Package permitted in 469? Is the expectation that the UAS=20 >>> will copy the Info-Package header (but not the body) from the request=20 >>> into the response? If so, then there ought to be some text somewhere=20 >>> that says that. But why bother? It would be more useful to include=20 >>> the Recv-Info header in the >>> 469 response. (That would require added specification, since it is=20 >>> currently forbidden to do so.) >>=20 >> I agree that Recv-Info makes more sense. >>=20 >> I guess we could add the following clarification text to section 3.2.2: >>=20 >> "If a UA receives an INFO request associated with an Info Package that=20 >> the UA has not indicated willingness to receive, the UA MUST send a >> 469 (Bad INFO Package) response (see Section 11.6), which=20 >> contains a Recv-Info Header field with Info Packages for which the UA=20 >> is willing to receive INFO requests. The UA MUST NOT use the response=20 >> to update the set of Info Packages, but simply to indicate the current=20 >> set. In the terminology of Multiple Dialog Usages [RFC5057],=20 >> this represents a Transaction Only failure, and does not terminate the=20 >> invite dialog usage." > >That seems reasonable to me. >But then you also need to update the table in 6.1 to show that Recv-Info i= s permitted in 469 responses. Yes. ----------------- =20 >>> Section 8.2: >>> >>> There is a preferred method for defining extensions now: >>> >>> Method =3D/ INFOm >>> >>> Also, the following is missing but needed: >>> >>> message-header =3D/ (Info-Package / Recv-Info) CRLF >>> >>> However these changes will require referencing RFC 5234 >>=20 >> I added a refernce to 5243 in the normative reference section. >>=20 >> Where do you want a reference in the text? Somewhere in section 8.1? >>=20 >> The text currently says: >>=20 >> "This section describes the syntax extensions required for the INFO=20 >> method, and for the Info-Package and Recv-Info header fields. The=20 >> previous sections describe the semantics. Note the formal syntax=20 >> definitions described in this document use the ABNF format used in=20 >> [RFC3261] and contain references to elements defined therein." >>=20 >> 3261 refers to 2234 for ABNF, but maybe that doesn't matter. >>=20 >> Maybe we could say something like: >>=20 >> "This section describes the syntax extensions to the ABNF format=20 >> defined in [RFC3261] required for the INFO method, and for the Info-Pack= age and Recv-Info header fields. The previous sections describe the semanti= cs. >> The ABNF defined in this specification is conformant to [RFC5234]." > >Almost. I suggest: > >"This section describes the syntax extensions to the ABNF syntax defined i= n [RFC3261] required for the INFO method, and adds definitions for the Info= -Package and Recv-Info header fields. The previous=20 >sections describe the semantics. The ABNF defined in this specification is= conformant to [RFC5234]." Looks good. ----------------- =20 >>> Section 10.4: >>> >>> The cross reference to section 10.5 is wrong. And I'm not certain=20 >>> what the correct value is - perhaps 11.4??? >>=20 >> It seems like some old text, that should have gone as part of some restr= ucturing. >>=20 >> I suggest to remove the paragraph. > >ok. Gone it will be. Regards, Christer From christer.holmberg@ericsson.com Fri Jan 15 13:52:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FEC63A684C for ; Fri, 15 Jan 2010 13:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.152 X-Spam-Level: X-Spam-Status: No, score=-6.152 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDruWHKnYLKS for ; Fri, 15 Jan 2010 13:52:38 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 780F63A6784 for ; Fri, 15 Jan 2010 13:52:38 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-d8-4b50e3a183da Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 4A.FC.04178.1A3E05B4; Fri, 15 Jan 2010 22:52:34 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 15 Jan 2010 22:52:33 +0100 From: Christer Holmberg To: 'Robert Sparks' Date: Fri, 15 Jan 2010 22:52:32 +0100 Thread-Topic: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments Thread-Index: AcqV+LNADsBJt1rjSaWROgNXoP6FHAAM3jfg Message-ID: References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 21:52:39 -0000 =20 Hi, >>> I just skimmed -04 and see a few of things to pay attention to. >>> >>> 1) The IANA considerations section is confusing. If I remember the=20 >>> conversation correctly, the group settled on "Specification=20 >>> Required". That's what the document should say. >> >> Section 11.4, which describes the content of the registrary, contains=20 >> a bullet which says: >> >> "o Reference: A reference to a specification which describes the Info=20 >> Package." > >"Specification Required" is a special string that is easy for IANA to =20 >recognize. > >The section should contain this sentence: > >"The registration policy for this document is Specification Required =20 >[RFC5226]." > >It does not need to try to explain what Specification Required means. =20 >RFC5226 does that. I did propose the section text on the list, and nobody objected.=20 Anyway, if I understand you correctly, I will replace the existing paragrap= h about IANA assigning an expert ect with your text above? So, the section would look become: ------------------------- 11.4. Creation of the Info Packages Registry Please create a subregistry in the SIP Parameters registry for Info Packages. The registration policy for this document is Specification Required =20 [RFC5226]. The following data elements populate the Info Package Registry. o Info Package Name: The Info Package Name is a case insensitive token. In addition, IANA shall not register multiple Info Package names that have identical case-insensitive values. o Reference: A reference to a specification which describes the Info Package. The initial population of this table shall be: Name Reference ------------------------- Regards, Christer= From christer.holmberg@ericsson.com Fri Jan 15 13:55:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2340A3A695F for ; Fri, 15 Jan 2010 13:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.155 X-Spam-Level: X-Spam-Status: No, score=-6.155 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BisJ25i1gysp for ; Fri, 15 Jan 2010 13:55:43 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 36EBA3A684C for ; Fri, 15 Jan 2010 13:55:41 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-a8-4b50e459bd48 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 1C.0D.04178.954E05B4; Fri, 15 Jan 2010 22:55:37 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 15 Jan 2010 22:55:37 +0100 From: Christer Holmberg To: "'Elwell, John'" , Gonzalo Camarillo Date: Fri, 15 Jan 2010 22:55:36 +0100 Thread-Topic: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) Thread-Index: AcqVvUb1Vex4olwzSvCa5rYWdkHPMgAANJDAAANffaAAGGBsMA== Message-ID: References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> <4B4FBA84.2040005@cisco.com> <4B50200B.9020806@ericsson.com> <4B50281E.1070901@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 21:55:44 -0000 Hi,=20 >There is not a lot of point in adding to something that is already broken,= so I tend to agree with Robert. I had not commented on this in the past, b= ut I never saw a lot of use for Recv-Info in OPTIONS=20 >(I just saw it as harmless), but given the concerns voiced by Robert and P= aul I would avoid adding to the known problem. Personally I think what I was trying to do was actually to fix the OPTIONS = problem, but adding explicit text for how the header field is used with OPT= IONS. No matter how much we "fix" OPTIONS, I think there will still be a need to = describe how it is used for specific header fields (maybe not all header fi= elds). But, regard that as a side note. I will remove the section :) Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 15 January 2010 08:39 > To: Gonzalo Camarillo > Cc: SIPCORE > Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting the=20 > publication of the draft-ietf-sipcore-info-events) >=20 >=20 > Sorry. I thought you changed the subject in order to discuss the=20 > specific OPTIONS comments given for the info draft. >=20 > Regards, >=20 > Christer >=20 > > -----Original Message----- > > From: Gonzalo Camarillo > > Sent: 15. tammikuuta 2010 10:33 > > To: Christer Holmberg > > Cc: Paul Kyzivat; SIPCORE > > Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting the=20 > > publication of the draft-ietf-sipcore-info-events) > >=20 > > Hi Christer, > >=20 > > the reason I had changed the subject of the thread was to keep=20 > > discussions on the info events draft and on the possibility to work=20 > > on fixing OPTIONS separate ;o) > >=20 > > People appreciate having the right subjects on the right threads=20 > > when they have to go back to the archives to look for something. > >=20 > > Cheers, > >=20 > > Gonzalo > >=20 > > Christer Holmberg wrote: > > > =20 > > > Hi, > > >=20 > > > So, what do I do? Change mandatory to optional? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >> -----Original Message----- > > >> From: sipcore-bounces@ietf.org > > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > > >> Sent: 15. tammikuuta 2010 9:58 > > >> To: Paul Kyzivat > > >> Cc: SIPCORE > > >> Subject: [sipcore] OPTIONS requests WAS (Re: Requesting the=20 > > >> publication of the draft-ietf-sipcore-info-events) > > >> > > >> Hi Paul, > > >> > > >>> I agree, but the problem is bigger than this draft. > > >>> > > >>> The whole concept that OPTIONS will tell you the > > >> capabilities of the > > >>> UA is pretty broken - it assumes those are stable over > > time and are > > >>> context free, which is often not the case. There are almost > > >> never any > > >>> guarantees that the info you receive from OPTIONS will > > >> still be true > > >>> if you try to act on it. > > >>> > > >>> The concept that the response code from OPTIONS should be > > >> the same as > > >>> you would get were you to send an INVITE is even more > broken. It > > >>> doesn't work at all well for UAs that don't support INVITE. > > >>> > > >>> The definition of OPTIONS needs some serious rework. > > >> yes, this has come up several times in the past. When > > people try to > > >> use OPTIONS to provide a meaningful service, they fairly > > soon notice > > >> how broken it is. At some point, it could be interesting > > to gather a > > >> few requirements and try to fix it somehow. > > >> > > >> Cheers, > > >> > > >> Gonzalo > > >> > > >> _______________________________________________ > > >> sipcore mailing list > > >> sipcore@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sipcore > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From rjsparks@nostrum.com Fri Jan 15 14:09:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6213D3A6857 for ; Fri, 15 Jan 2010 14:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hQa-mALPoNH for ; Fri, 15 Jan 2010 14:09:08 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 2BD353A67E5 for ; Fri, 15 Jan 2010 14:09:07 -0800 (PST) Received: from [192.168.2.2] (pool-173-71-49-137.dllstx.fios.verizon.net [173.71.49.137]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0FM91em059885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Jan 2010 16:09:01 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <3D006D6F-6936-41FF-A3FA-EB51AF4BC6FF@nostrum.com> From: Robert Sparks To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 15 Jan 2010 16:09:00 -0600 References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 173.71.49.137 is authenticated by a trusted mechanism) Cc: SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 22:09:09 -0000 What you have below looks correct to me except for one nit (which is my fault - sorry). It should say "policy for this registry" instead of "policy for this document". Thanks, RjS On Jan 15, 2010, at 3:52 PM, Christer Holmberg wrote: > > Hi, > >>>> I just skimmed -04 and see a few of things to pay attention to. >>>> >>>> 1) The IANA considerations section is confusing. If I remember the >>>> conversation correctly, the group settled on "Specification >>>> Required". That's what the document should say. >>> >>> Section 11.4, which describes the content of the registrary, >>> contains >>> a bullet which says: >>> >>> "o Reference: A reference to a specification which describes the >>> Info >>> Package." >> >> "Specification Required" is a special string that is easy for IANA to >> recognize. >> >> The section should contain this sentence: >> >> "The registration policy for this document is Specification Required >> [RFC5226]." >> >> It does not need to try to explain what Specification Required means. >> RFC5226 does that. > > I did propose the section text on the list, and nobody objected. > > Anyway, if I understand you correctly, I will replace the existing > paragraph about IANA assigning an expert ect with your text above? > > So, the section would look become: > > ------------------------- > > 11.4. Creation of the Info Packages Registry > > Please create a subregistry in the SIP Parameters registry for Info > Packages. > > The registration policy for this document is Specification Required > [RFC5226]. > > The following data elements populate the Info Package Registry. > o Info Package Name: The Info Package Name is a case insensitive > token. In addition, IANA shall not register multiple Info > Package > names that have identical case-insensitive values. > o Reference: A reference to a specification which describes the > Info > Package. > > The initial population of this table shall be: > > Name Reference > > ------------------------- > > Regards, > > Christer From pkyzivat@cisco.com Fri Jan 15 15:32:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8229D3A6959 for ; Fri, 15 Jan 2010 15:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.42 X-Spam-Level: X-Spam-Status: No, score=-10.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4wCflCy+8c7 for ; Fri, 15 Jan 2010 15:32:46 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B85053A6840 for ; Fri, 15 Jan 2010 15:32:46 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHSKUEutJV2c/2dsb2JhbADFFZUkhDEE X-IronPort-AV: E=Sophos;i="4.49,285,1262563200"; d="scan'208";a="467653332" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-6.cisco.com with ESMTP; 15 Jan 2010 23:32:43 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o0FNWhvN031572; Fri, 15 Jan 2010 23:32:43 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 17:32:43 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 17:32:43 -0600 Message-ID: <4B50FB1A.4070800@cisco.com> Date: Fri, 15 Jan 2010 18:32:42 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <20100114080001.CB2253A694D@core3.amsl.com> <4B4F3952.7060703@cisco.com> <4B508630.4050004@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2010 23:32:43.0184 (UTC) FILETIME=[0901F300:01CA963B] Cc: SIPCORE Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-info-events-04.txt - Paul's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 23:32:47 -0000 Christer Holmberg wrote: > ----------------- > >>> Section 4.2.3: >>> >>> NOTE: Similar to SDP answers, the receiver can include the same >>> Recv-Info header field value in multiple responses (18x/2xx) for the >>> same INVITE/re-INVITE transaction, but the receiver is not allowed to >>> include a Recv-Info header field value which is different from a >>> value that the receiver has already included in a response for the >>> same transaction. >>> >>> I think "the receiver is not allowed" is intended to be normative. >>> But the language isn't normative. If it is indeed intended to be >>> normative this needs to be rewritten. >> You didn't comment on the above. >> Do you agree that this ought to be normative? > > Sorry, I forgot to write down my comment earlier. > > Yes, I agree to making it normaive. I suggest to simply remove "NOTE:". > > Also, I suggest to change "is not allowed" to "MUST NOT". That works for me. With all the changes you have proposed it all seems good to me. Thanks, Paul From gao.yang2@zte.com.cn Fri Jan 15 18:47:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106233A67E4 for ; Fri, 15 Jan 2010 18:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.236 X-Spam-Level: X-Spam-Status: No, score=-94.236 tagged_above=-999 required=5 tests=[AWL=3.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJQIxoqx1G4N for ; Fri, 15 Jan 2010 18:47:03 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 82D743A67A8 for ; Fri, 15 Jan 2010 18:47:02 -0800 (PST) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91101727820181; Sat, 16 Jan 2010 10:21:24 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 75400.2980680612; Sat, 16 Jan 2010 10:46:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o0G2kv2H057792; Sat, 16 Jan 2010 10:46:57 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4B4ED6EE.5060101@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Sat, 16 Jan 2010 10:45:44 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-01-16 10:46:52, Serialize complete at 2010-01-16 10:46:52 Content-Type: multipart/alternative; boundary="=_alternative 000F4595482576AD_=" X-MAIL: mse2.zte.com.cn o0G2kv2H057792 Cc: SIPCORE Subject: Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2010 02:47:05 -0000 This is a multipart message in MIME format. --=_alternative 000F4595482576AD_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCk1heWJlIGNsYXJpZmljYXRpb24gb2YgcHJlY29ucyBoYXMgc29tZXRoaW5nIGJleW9u ZCBSZS1JTlZJVEUgaGFuZGxpbmcgDQp0ZXh0LiANCg0KQXMgUmUtSU5WSVRFIGhhbmRsaW5nIHRl eHQgYWltcyBmb3IgdXBkYXRpbmcgb2YgUkZDMzI2MSwgd2UgbWF5IG5lZWQgYSANCmRldGFpbGVk IG5vcm1hdGl2ZSB0ZXh0IGZvciB1cGRhdGluZyBSRkMzMzEyICYgUkZDNDAzMi4gQW5kIHdlIGNh biB0YWxrIA0KdG9waWNzIHJlbGF0aW5nIHRvIHByZWNvbnMgYnV0IG91dHNpZGUgb2YgdGhlIHNj b3BlIG9mIFJlLUlOVklURSBoYW5kbGluZyANCnRleHQsIHN1Y2ggYXMgInJlc3VtaW5nIGFuZCBz dXNwZW5kaW5nIGZvciBzZXNzaW9uIG9yIGZvciBzZXBhcmF0ZSANCnN0cmVhbSIuDQoNClR3byBz ZXBhcmF0ZSB0ZXh0IG1lYW5zIGRpZmZlcmVudCBtYWludGVuYW5jZSBwcm9jZXNzIGFuZCBsaWZl Y3ljbGUuIElmIHdlIA0KY2FuIGd1YXJhbnRlZSB0aGUgY29uc2lzdGVuY3kgYW5kIGludGVncmFs aXR5IG9mIHRoZSB0d28gdGV4dCwgSSB0aGluayB0d28gDQp0ZXh0IHdvdWxkIGJlIGNsZWFyIGZv ciB0d28gKHJlbGF0aW5nKSB0b3BpY3MuDQoNClRoYW5rcywNCg0KR2FvDQoNCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDogODcy MTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUu Y29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KR29uemFs byBDYW1hcmlsbG8gPEdvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbT4gDQq3orz+yMs6ICBz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTAtMDEtMTQgMTY6MzMNCg0KytW8/sjLDQpTSVBD T1JFIDxzaXBjb3JlQGlldGYub3JnPg0Ks63LzQ0KDQrW98ziDQpSZTogW3NpcGNvcmVdIFF1ZXN0 aW9uIG9uIGRyYWZ0LWNhbWFyaWxsby1zaXBjb3JlLXJlaW52aXRlLTAxLnR4dA0KDQoNCg0KDQoN Cg0KSGksDQoNCkkgaGF2ZSBwdXQgdG9nZXRoZXIgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQ6 DQoNCmh0dHA6Ly91c2Vycy5waXVoYS5uZXQvZ29uemFsby90ZW1wL2RyYWZ0LWlldGYtc2lwY29y ZS1yZWludml0ZS1wcmUwMWEudHh0DQoNCkxldCBtZSBrbm93IGlmIHlvdSBoYXZlIHNvbWUgY29t bWVudHMgYmVmb3JlIEkgc3VibWl0IGl0Lg0KDQpSZWdhcmRpbmcgdGhlIGRlY2lzaW9uIGFib3V0 IHdoZW4gYSBnaXZlbiBjaGFuZ2UgaW4gdGhlIHNlc3Npb24gc3RhdGUgDQpoYXMgYmVlbiBleGVj dXRlZCB3aGVuIHByZWNvbmRpdGlvbnMgYXJlIHVzZWQsIEkgaGF2ZSBhZGRlZCBhIHBhcmFncmFw aCANCnRoYXQgc3VtbWFyaXplcyBvdXIgZGlzY3Vzc2lvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZHJh ZnQ6DQoNCmh0dHA6Ly93d3cud2F0ZXJzcHJpbmdzLm9yZy9wdWIvaWQvZHJhZnQtY2FtYXJpbGxv LXNpcHBpbmctcHJlY29ucy0wMC50eHQNCg0KUGxlYXNlLCByZWFkIFNlY3Rpb24gNS4NCg0KU2Vj dGlvbnMgNyBhbmQgMTUgY29udGFpbiBuZXcgcnVsZXMgdG8gYXZvaWQgZ2xhcmUgc2l0dWF0aW9u cyBhbmQgcmFjZSANCmNvbmRpdGlvbnMuIFRoZXNlIHJ1bGVzIGF2b2lkIG5hc3R5IGNhbGwgZmxv d3MgdGhhdCB3ZXJlIGFibGUgdG8gZ2V0IHRoZSANClVBcyBvdXQgb2Ygc3luY2guDQoNClNvbWUg dGltZSBhZ28sIHdlIGRpc2N1c3NlZCB3aGV0aGVyIG9yIG5vdCB1bnJlbGlhYmxlIHByb3Zpc2lv bmFsIA0KcmVzcG9uc2VzIGNvdWxkIHJlZnJlc2ggdGhlIHJlbW90ZSB0YXJnZXQuIFRoZXJlIGFy ZSBzZXZlcmFsIHByb2JsZW1zIA0Kd2l0aCB1bnJlbGlhYmxlIHJlc3BvbnNlcyB1cGRhdGluZyBy ZW1vdGUgdGFyZ2V0cy4gRmlyc3QsIHdlIHdvdWxkIG5lZWQgDQp0byBkZWZpbmUgZXZlbiBtb3Jl IHJ1bGVzIHRvIGF2b2lkIGdsYXJlIHNpdHVhdGlvbnMgYW5kIHJhY2UgY29uZGl0aW9ucy4gDQpT ZWNvbmQsIFNJUCBkb2VzIG5vdCBwcm92aWRlIGFueSBvcmRlcmluZyBmb3IgdW5yZWxpYWJsZSBw cm92aXNpb25hbCANCnJlc3BvbnNlcy4gUmVzcG9uc2VzIGFycml2aW5nIG91dCBvZiBvcmRlciBh dCB0aGUgVUFDIGNvdWxkIGVhc2lseSBnZXQgDQpib3RoIFVBcyBvdXQgb2Ygc3luY2guIFRoZXJl Zm9yZSwgb25seSByZWxpYWJsZSByZXNwb25zZXMgY2FuIHJlZnJlc2ggDQpyZW1vdGUgdGFyZ2V0 cywgYXMgd2FzIHNwZWNpZmllZCBpbiBSRkMgMzI2MSBhbnl3YXkuDQoNCldlIGFsc28gZGlzY3Vz c2VkIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSB0YXJnZXQgcmVmcmVzaCBydWxlcyB0byANCmlu aXRpYWwgSU5WSVRFcy4gVGhlIHJ1bGVzIGluIHRoZSBkcmFmdCBjb3ZlciB0aGVtIGFzIHdlbGwg c28gSSBkbyBub3QgDQp0aGluayB3ZSBuZWVkIHRvIGFkZCBhbnl0aGluZyBlbHNlIHRvIHRoYXQg ZW5kLg0KDQpUaGFua3MsDQoNCkdvbnphbG8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KDQoN Cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBv cmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVj aXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5k IGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11 bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVk IHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRo ZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMg bWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdl IGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBz eXN0ZW0uDQo= --=_alternative 000F4595482576AD_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TWF5YmUgY2xhcmlmaWNhdGlvbiBvZiBw cmVjb25zIGhhcyBzb21ldGhpbmcNCmJleW9uZCBSZS1JTlZJVEUgaGFuZGxpbmcgdGV4dC4gPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BcyBSZS1JTlZJ VEUgaGFuZGxpbmcgdGV4dCBhaW1zIGZvcg0KdXBkYXRpbmcgb2YgUkZDMzI2MSwgd2UgbWF5IG5l ZWQgYSBkZXRhaWxlZCBub3JtYXRpdmUgdGV4dCBmb3IgdXBkYXRpbmcNClJGQzMzMTIgJmFtcDsg UkZDNDAzMi4gQW5kIHdlIGNhbiB0YWxrIHRvcGljcyByZWxhdGluZyB0byBwcmVjb25zIGJ1dCBv dXRzaWRlDQpvZiB0aGUgc2NvcGUgb2YgUmUtSU5WSVRFIGhhbmRsaW5nIHRleHQsIHN1Y2ggYXMg JnF1b3Q7cmVzdW1pbmcgYW5kIHN1c3BlbmRpbmcNCmZvciBzZXNzaW9uIG9yIGZvciBzZXBhcmF0 ZSBzdHJlYW0mcXVvdDsuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5Ud28gc2VwYXJhdGUgdGV4dCBtZWFucyBkaWZmZXJlbnQgbWFpbnRlbmFuY2UNCnBy b2Nlc3MgYW5kIGxpZmVjeWNsZS4gSWYgd2UgY2FuIGd1YXJhbnRlZSB0aGUgY29uc2lzdGVuY3kg YW5kIGludGVncmFsaXR5DQpvZiB0aGUgdHdvIHRleHQsIEkgdGhpbmsgdHdvIHRleHQgd291bGQg YmUgY2xlYXIgZm9yIHR3byAocmVsYXRpbmcpIHRvcGljcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT08YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZuYnNw OzogODcyMTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBlX21h aWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPkdvbnphbG8gQ2FtYXJpbGxvICZsdDtHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5j b20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63 orz+yMs6ICZuYnNwO3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTAxLTE0IDE2OjMzPC9mb250Pg0KPHRkIHdpZHRo PTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlNJUENPUkUgJmx0O3NpcGNv cmVAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0K PHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5SZTogW3NpcGNvcmVdIFF1ZXN0aW9uIG9uIGRyYWZ0LWNhbWFyaWxs by1zaXBjb3JlLXJlaW52aXRlLTAxLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0K PGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SGksPGJyPg0KPGJyPg0KSSBoYXZlIHB1dCB0b2dl dGhlciBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdDo8YnI+DQo8YnI+DQpodHRwOi8vdXNlcnMu cGl1aGEubmV0L2dvbnphbG8vdGVtcC9kcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtcHJlMDFh LnR4dDxicj4NCjxicj4NCkxldCBtZSBrbm93IGlmIHlvdSBoYXZlIHNvbWUgY29tbWVudHMgYmVm b3JlIEkgc3VibWl0IGl0Ljxicj4NCjxicj4NClJlZ2FyZGluZyB0aGUgZGVjaXNpb24gYWJvdXQg d2hlbiBhIGdpdmVuIGNoYW5nZSBpbiB0aGUgc2Vzc2lvbiBzdGF0ZSA8YnI+DQpoYXMgYmVlbiBl eGVjdXRlZCB3aGVuIHByZWNvbmRpdGlvbnMgYXJlIHVzZWQsIEkgaGF2ZSBhZGRlZCBhIHBhcmFn cmFwaA0KPGJyPg0KdGhhdCBzdW1tYXJpemVzIG91ciBkaXNjdXNzaW9ucyBhbmQgdGhlIGZvbGxv d2luZyBkcmFmdDo8YnI+DQo8YnI+DQpodHRwOi8vd3d3LndhdGVyc3ByaW5ncy5vcmcvcHViL2lk L2RyYWZ0LWNhbWFyaWxsby1zaXBwaW5nLXByZWNvbnMtMDAudHh0PGJyPg0KPGJyPg0KUGxlYXNl LCByZWFkIFNlY3Rpb24gNS48YnI+DQo8YnI+DQpTZWN0aW9ucyA3IGFuZCAxNSBjb250YWluIG5l dyBydWxlcyB0byBhdm9pZCBnbGFyZSBzaXR1YXRpb25zIGFuZCByYWNlDQo8YnI+DQpjb25kaXRp b25zLiBUaGVzZSBydWxlcyBhdm9pZCBuYXN0eSBjYWxsIGZsb3dzIHRoYXQgd2VyZSBhYmxlIHRv IGdldCB0aGUNCjxicj4NClVBcyBvdXQgb2Ygc3luY2guPGJyPg0KPGJyPg0KU29tZSB0aW1lIGFn bywgd2UgZGlzY3Vzc2VkIHdoZXRoZXIgb3Igbm90IHVucmVsaWFibGUgcHJvdmlzaW9uYWwgPGJy Pg0KcmVzcG9uc2VzIGNvdWxkIHJlZnJlc2ggdGhlIHJlbW90ZSB0YXJnZXQuIFRoZXJlIGFyZSBz ZXZlcmFsIHByb2JsZW1zIDxicj4NCndpdGggdW5yZWxpYWJsZSByZXNwb25zZXMgdXBkYXRpbmcg cmVtb3RlIHRhcmdldHMuIEZpcnN0LCB3ZSB3b3VsZCBuZWVkDQo8YnI+DQp0byBkZWZpbmUgZXZl biBtb3JlIHJ1bGVzIHRvIGF2b2lkIGdsYXJlIHNpdHVhdGlvbnMgYW5kIHJhY2UgY29uZGl0aW9u cy4NCjxicj4NClNlY29uZCwgU0lQIGRvZXMgbm90IHByb3ZpZGUgYW55IG9yZGVyaW5nIGZvciB1 bnJlbGlhYmxlIHByb3Zpc2lvbmFsIDxicj4NCnJlc3BvbnNlcy4gUmVzcG9uc2VzIGFycml2aW5n IG91dCBvZiBvcmRlciBhdCB0aGUgVUFDIGNvdWxkIGVhc2lseSBnZXQNCjxicj4NCmJvdGggVUFz IG91dCBvZiBzeW5jaC4gVGhlcmVmb3JlLCBvbmx5IHJlbGlhYmxlIHJlc3BvbnNlcyBjYW4gcmVm cmVzaCA8YnI+DQpyZW1vdGUgdGFyZ2V0cywgYXMgd2FzIHNwZWNpZmllZCBpbiBSRkMgMzI2MSBh bnl3YXkuPGJyPg0KPGJyPg0KV2UgYWxzbyBkaXNjdXNzZWQgdGhlIGFwcGxpY2FiaWxpdHkgb2Yg dGhlIHRhcmdldCByZWZyZXNoIHJ1bGVzIHRvIDxicj4NCmluaXRpYWwgSU5WSVRFcy4gVGhlIHJ1 bGVzIGluIHRoZSBkcmFmdCBjb3ZlciB0aGVtIGFzIHdlbGwgc28gSSBkbyBub3QNCjxicj4NCnRo aW5rIHdlIG5lZWQgdG8gYWRkIGFueXRoaW5nIGVsc2UgdG8gdGhhdCBlbmQuPGJyPg0KPGJyPg0K VGhhbmtzLDxicj4NCjxicj4NCkdvbnphbG88YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJy Pg0Kc2lwY29yZUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2lwY29yZTxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUm bmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21h aWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJz cDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2Nv bW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5i c3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7 bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVy bWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7 b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhp cyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRl ZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZu YnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZu YnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7 eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4m bmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0 b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJz cDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7 dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlz Jm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5i c3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGkt U3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 000F4595482576AD_=-- From christer.holmberg@ericsson.com Sat Jan 16 11:19:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8093E3A67E2 for ; Sat, 16 Jan 2010 11:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.158 X-Spam-Level: X-Spam-Status: No, score=-6.158 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zk0hOfuwJhq for ; Sat, 16 Jan 2010 11:19:39 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 057943A67EE for ; Sat, 16 Jan 2010 11:19:35 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-fb-4b5211424cfd Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id B9.6C.04178.241125B4; Sat, 16 Jan 2010 20:19:30 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sat, 16 Jan 2010 20:19:30 +0100 From: Christer Holmberg To: Robert Sparks Date: Sat, 16 Jan 2010 20:18:46 +0100 Thread-Topic: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments Thread-Index: AcqWL1lJkgBVo7T2SBWlaVB+Pp66zAAsWDy2 Message-ID: References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> , <3D006D6F-6936-41FF-A3FA-EB51AF4BC6FF@nostrum.com> In-Reply-To: <3D006D6F-6936-41FF-A3FA-EB51AF4BC6FF@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] Requesting the publication of the draft-ietf-sipcore-info-events - Robert's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2010 19:19:43 -0000 Hi, >What you have below looks correct to me except for one nit (which is >my fault - sorry). >It should say "policy for this registry" instead of "policy for this >document". Is it ok to say "THE registry"? Regards, Christer > > Hi, > >>>> I just skimmed -04 and see a few of things to pay attention to. >>>> >>>> 1) The IANA considerations section is confusing. If I remember the >>>> conversation correctly, the group settled on "Specification >>>> Required". That's what the document should say. >>> >>> Section 11.4, which describes the content of the registrary, >>> contains >>> a bullet which says: >>> >>> "o Reference: A reference to a specification which describes the >>> Info >>> Package." >> >> "Specification Required" is a special string that is easy for IANA to >> recognize. >> >> The section should contain this sentence: >> >> "The registration policy for this document is Specification Required >> [RFC5226]." >> >> It does not need to try to explain what Specification Required means. >> RFC5226 does that. > > I did propose the section text on the list, and nobody objected. > > Anyway, if I understand you correctly, I will replace the existing > paragraph about IANA assigning an expert ect with your text above? > > So, the section would look become: > > ------------------------- > > 11.4. Creation of the Info Packages Registry > > Please create a subregistry in the SIP Parameters registry for Info > Packages. > > The registration policy for this document is Specification Required > [RFC5226]. > > The following data elements populate the Info Package Registry. > o Info Package Name: The Info Package Name is a case insensitive > token. In addition, IANA shall not register multiple Info > Package > names that have identical case-insensitive values. > o Reference: A reference to a specification which describes the > Info > Package. > > The initial population of this table shall be: > > Name Reference > > ------------------------- > > Regards, > > Christer= From christer.holmberg@ericsson.com Sun Jan 17 22:57:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5CB23A68DA for ; Sun, 17 Jan 2010 22:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U28hu5+KFSaU for ; Sun, 17 Jan 2010 22:57:01 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 469103A680E for ; Sun, 17 Jan 2010 22:57:01 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-73-4b54063801a4 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 27.E3.04178.836045B4; Mon, 18 Jan 2010 07:56:56 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 18 Jan 2010 07:56:55 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Mon, 18 Jan 2010 07:56:55 +0100 From: Christer Holmberg To: SIPCORE Date: Mon, 18 Jan 2010 07:56:54 +0100 Thread-Topic: Draft new version: draft-ietf-sipcore-info-events-05 Thread-Index: AcqYC2tkD+ZbCH77QguZc1GgL0AGgw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FF84A09F50A6DC48ACB6714F4666CC743C57276874ESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Gonzalo Camarillo , Hadriel Kaplan Subject: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 06:57:02 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC743C57276874ESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the WGLC comments, a new version (-05) of the info-event draft has= been submitted. It can also be found at: http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-05.tx= t Since there has been some e-mail editing etc, please take a look and make s= ure that your comments/issues have been addressed. Regards, Christer --_000_FF84A09F50A6DC48ACB6714F4666CC743C57276874ESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Based on the WGLC comments, a new version (-05) of th= e info-event draft has been submitted.
 
It can also be found at:
 
 
Since there has been some e-mail editing etc, please = take a look and make sure that your comments/issues have been addressed.
 
Regards,
 
Christer
 
 
 --_000_FF84A09F50A6DC48ACB6714F4666CC743C57276874ESESSCMS0354e_-- From root@core3.amsl.com Sun Jan 17 23:00:01 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9DAE93A6A18; Sun, 17 Jan 2010 23:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100118070001.9DAE93A6A18@core3.amsl.com> Date: Sun, 17 Jan 2010 23:00:01 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-info-events-05.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 07:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) INFO Method and Package Framework Author(s) : C. Holmberg, et al. Filename : draft-ietf-sipcore-info-events-05.txt Pages : 39 Date : 2010-01-17 This document defines a method, INFO, for the Session Initiation Protocol (SIP) [RFC3261], and an Info Package mechanism. The document obsoletes [RFC2976]. For backward compatibility the document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in [RFC2976], referred to as "legacy INFO Usage" in this document. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The terminology in this document conforms to the Internet Security Glossary [RFC4949]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 22, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-info-events-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-17225246.I-D@ietf.org> --NextPart-- From gonzalo.camarillo@ericsson.com Mon Jan 18 00:14:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 036153A6A81 for ; Mon, 18 Jan 2010 00:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.881 X-Spam-Level: X-Spam-Status: No, score=-104.881 tagged_above=-999 required=5 tests=[AWL=-1.082, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDlZiYSBg4gn for ; Mon, 18 Jan 2010 00:14:24 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E85793A67A4 for ; Mon, 18 Jan 2010 00:14:23 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-2e-4b54185b77f5 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 54.C6.04178.B58145B4; Mon, 18 Jan 2010 09:14:19 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 09:14:13 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 09:14:13 +0100 Message-ID: <4B541854.5010907@ericsson.com> Date: Mon, 18 Jan 2010 10:14:12 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "gao.yang2@zte.com.cn" References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 18 Jan 2010 08:14:13.0108 (UTC) FILETIME=[3814F340:01CA9816] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 08:14:26 -0000 Hi Gao, that is why I wrote the draft about preconditions. However, not many people showed interest in it at that time. Cheers, Gonzalo gao.yang2@zte.com.cn wrote: > > Hi, > > Maybe clarification of precons has something beyond Re-INVITE handling > text. > > As Re-INVITE handling text aims for updating of RFC3261, we may need a > detailed normative text for updating RFC3312 & RFC4032. And we can talk > topics relating to precons but outside of the scope of Re-INVITE > handling text, such as "resuming and suspending for session or for > separate stream". > > Two separate text means different maintenance process and lifecycle. If > we can guarantee the consistency and integrality of the two text, I > think two text would be clear for two (relating) topics. > > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > *Gonzalo Camarillo * > 发件人: sipcore-bounces@ietf.org > > 2010-01-14 16:33 > > > 收件人 > SIPCORE > 抄送 > > 主题 > Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt > > > > > > > > > Hi, > > I have put together a new version of the draft: > > http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre01a.txt > > Let me know if you have some comments before I submit it. > > Regarding the decision about when a given change in the session state > has been executed when preconditions are used, I have added a paragraph > that summarizes our discussions and the following draft: > > http://www.watersprings.org/pub/id/draft-camarillo-sipping-precons-00.txt > > Please, read Section 5. > > Sections 7 and 15 contain new rules to avoid glare situations and race > conditions. These rules avoid nasty call flows that were able to get the > UAs out of synch. > > Some time ago, we discussed whether or not unreliable provisional > responses could refresh the remote target. There are several problems > with unreliable responses updating remote targets. First, we would need > to define even more rules to avoid glare situations and race conditions. > Second, SIP does not provide any ordering for unreliable provisional > responses. Responses arriving out of order at the UAC could easily get > both UAs out of synch. Therefore, only reliable responses can refresh > remote targets, as was specified in RFC 3261 anyway. > > We also discussed the applicability of the target refresh rules to > initial INVITEs. The rules in the draft cover them as well so I do not > think we need to add anything else to that end. > > Thanks, > > Gonzalo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > From john.elwell@siemens-enterprise.com Mon Jan 18 00:43:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A6583A688E for ; Mon, 18 Jan 2010 00:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrQVU1sdWjUM for ; Mon, 18 Jan 2010 00:43:43 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id F15263A680F for ; Mon, 18 Jan 2010 00:43:42 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-566049 for sipcore@ietf.org; Mon, 18 Jan 2010 09:43:38 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 8899723F0278 for ; Mon, 18 Jan 2010 09:43:38 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 18 Jan 2010 09:43:38 +0100 From: "Elwell, John" To: SIPCORE Date: Mon, 18 Jan 2010 09:43:36 +0100 Thread-Topic: Draft new version: draft-ietf-sipcore-info-events-05 Thread-Index: AcqYC2tkD+ZbCH77QguZc1GgL0AGgwADtrAQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A444A0F8084434499206E78C106220CA6A1C3CBBMCHP058Aglobala_" MIME-Version: 1.0 Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 08:43:44 -0000 --_000_A444A0F8084434499206E78C106220CA6A1C3CBBMCHP058Aglobala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looks good to me. John ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 18 January 2010 06:57 To: SIPCORE Cc: Adam Roach; Gonzalo Camarillo; Eric Burger; Hadriel Kaplan; Robert Spar= ks; Paul Kyzivat; Elwell, John Subject: Draft new version: draft-ietf-sipcore-info-events-05 Hi, Based on the WGLC comments, a new version (-05) of the info-event draft has= been submitted. It can also be found at: http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-05.tx= t Since there has been some e-mail editing etc, please take a look and make s= ure that your comments/issues have been addressed. Regards, Christer --_000_A444A0F8084434499206E78C106220CA6A1C3CBBMCHP058Aglobala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Looks good to me.
 
John

From: Christer Holmberg=20 [mailto:christer.holmberg@ericsson.com]
Sent: 18 January 2010= =20 06:57
To: SIPCORE
Cc: Adam Roach; Gonzalo Camarillo; = Eric=20 Burger; Hadriel Kaplan; Robert Sparks; Paul Kyzivat; Elwell,=20 John
Subject: Draft new version:=20 draft-ietf-sipcore-info-events-05

 
Hi,
 
Based on the WGLC comments, a new version (-05) of th= e=20 info-event draft has been submitted.
 
It can also be found at:
 
http://users.piuha.net/cholmber/drafts/draft-ietf-sipc= ore-info-events-05.txt
 
Since there has been some e-mail editing etc, please = take a=20 look and make sure that your comments/issues have been addressed.<= /DIV>
 
Regards,
 
Christer
 
 
 --_000_A444A0F8084434499206E78C106220CA6A1C3CBBMCHP058Aglobala_-- From gao.yang2@zte.com.cn Mon Jan 18 02:26:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E203A6836 for ; Mon, 18 Jan 2010 02:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xleLpQldp5lu for ; Mon, 18 Jan 2010 02:26:31 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 7CBF23A6405 for ; Mon, 18 Jan 2010 02:26:30 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641727820181; Mon, 18 Jan 2010 17:52:28 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 75400.2980680612; Mon, 18 Jan 2010 18:26:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id o0IAQaXl089381; Mon, 18 Jan 2010 18:26:36 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4B541854.5010907@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 18 Jan 2010 18:25:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-01-18 18:26:22, Serialize complete at 2010-01-18 18:26:22 Content-Type: multipart/alternative; boundary="=_alternative 0039611D482576AF_=" X-MAIL: mse1.zte.com.cn o0IAQaXl089381 Cc: SIPCORE Subject: Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 10:26:33 -0000 This is a multipart message in MIME format. --=_alternative 0039611D482576AF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR29uemFsbywNCg0KWWVzLCBJIGFsc28gZm91bmQgdGhhdCBub3QgbWFueSBwZW9wbGUgc2hv d2VkIGludGVyZXN0IGluIGl0Lg0KDQpCeSBkZWVwbHkgZGlzY3Vzc2lvbiAiUmUtSU5WSVRFIGhh bmRsaW5nIiBkcmFmdCB0aGVzZSBkYXlzLCB3ZSBmaW5kIHRoYXQgDQp3ZSBzaG91bGQgY2xhcmlm eSBob3cgbW9kaWZpZWQgbWVkaWEgY2FuL3Nob3VsZCBiZSB1c2VkLiBCdXQgaG93IG1vZGlmaWVk IA0KbWVkaWEgY2FuL3Nob3VsZC9tYXkgYmUgdXNlZCBpcyBhIG1vcmUgYmFzaWMgdG9waWMuDQoN ClRoaXMgdG9waWMgaGFzIGluZmx1ZW5jZSBvbiBvdGhlciBoaWdoZXIgbGV2ZWwgdG9waWNzLCBz dWNoIGFzICJSZS1JTlZJVEUgDQpoYW5kbGluZyIgZHJhZnQgYW5kIGV0Yy4gU28sIEkgaG9wZSBt b3JlIHBlb3BsZSBjb3VsZCBwYXkgYXR0ZW50aW9uIHRvIGl0Lg0KDQpUaGFua3MsDQoNCkdhbw0K DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0K IFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBn YW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N Cg0KDQoNCkdvbnphbG8gQ2FtYXJpbGxvIDxHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20+ IA0KMjAxMC0wMS0xOCAxNjoxNA0KDQrK1bz+yMsNCiJnYW8ueWFuZzJAenRlLmNvbS5jbiIgPGdh by55YW5nMkB6dGUuY29tLmNuPg0Ks63LzQ0KU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NCtb3 zOINClJlOiBbc2lwY29yZV0gUXVlc3Rpb24gb24gZHJhZnQtY2FtYXJpbGxvLXNpcGNvcmUtcmVp bnZpdGUtMDEudHh0DQoNCg0KDQoNCg0KDQpIaSBHYW8sDQoNCnRoYXQgaXMgd2h5IEkgd3JvdGUg dGhlIGRyYWZ0IGFib3V0IHByZWNvbmRpdGlvbnMuIEhvd2V2ZXIsIG5vdCBtYW55DQpwZW9wbGUg c2hvd2VkIGludGVyZXN0IGluIGl0IGF0IHRoYXQgdGltZS4NCg0KQ2hlZXJzLA0KDQpHb256YWxv DQoNCmdhby55YW5nMkB6dGUuY29tLmNuIHdyb3RlOg0KPiANCj4gSGksDQo+IA0KPiBNYXliZSBj bGFyaWZpY2F0aW9uIG9mIHByZWNvbnMgaGFzIHNvbWV0aGluZyBiZXlvbmQgUmUtSU5WSVRFIGhh bmRsaW5nIA0KPiB0ZXh0Lg0KPiANCj4gQXMgUmUtSU5WSVRFIGhhbmRsaW5nIHRleHQgYWltcyBm b3IgdXBkYXRpbmcgb2YgUkZDMzI2MSwgd2UgbWF5IG5lZWQgYSANCj4gZGV0YWlsZWQgbm9ybWF0 aXZlIHRleHQgZm9yIHVwZGF0aW5nIFJGQzMzMTIgJiBSRkM0MDMyLiBBbmQgd2UgY2FuIHRhbGsg DQo+IHRvcGljcyByZWxhdGluZyB0byBwcmVjb25zIGJ1dCBvdXRzaWRlIG9mIHRoZSBzY29wZSBv ZiBSZS1JTlZJVEUgDQo+IGhhbmRsaW5nIHRleHQsIHN1Y2ggYXMgInJlc3VtaW5nIGFuZCBzdXNw ZW5kaW5nIGZvciBzZXNzaW9uIG9yIGZvciANCj4gc2VwYXJhdGUgc3RyZWFtIi4NCj4gDQo+IFR3 byBzZXBhcmF0ZSB0ZXh0IG1lYW5zIGRpZmZlcmVudCBtYWludGVuYW5jZSBwcm9jZXNzIGFuZCBs aWZlY3ljbGUuIElmIA0KPiB3ZSBjYW4gZ3VhcmFudGVlIHRoZSBjb25zaXN0ZW5jeSBhbmQgaW50 ZWdyYWxpdHkgb2YgdGhlIHR3byB0ZXh0LCBJIA0KPiB0aGluayB0d28gdGV4dCB3b3VsZCBiZSBj bGVhciBmb3IgdHdvIChyZWxhdGluZykgdG9waWNzLg0KPiANCj4gVGhhbmtzLA0KPiANCj4gR2Fv DQo+IA0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiBaaXAgICAgOiAy MTAwMTINCj4gVGVsICAgIDogODcyMTENCj4gVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCj4g ZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj4gPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCj4gDQo+IA0KPiAqR29uemFsbyBDYW1hcmlsbG8gPEdvbnphbG8uQ2FtYXJp bGxvQGVyaWNzc29uLmNvbT4qDQo+ILeivP7IyzogIHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZw0K PiANCj4gMjAxMC0wMS0xNCAxNjozMw0KPiANCj4gDQo+IMrVvP7Iyw0KPiAgICAgICAgICAgICAg ICBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0KPiCzrcvNDQo+IA0KPiDW98ziDQo+ICAgICAg ICAgICAgICAgIFJlOiBbc2lwY29yZV0gUXVlc3Rpb24gb24gDQpkcmFmdC1jYW1hcmlsbG8tc2lw Y29yZS1yZWludml0ZS0wMS50eHQNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBI aSwNCj4gDQo+IEkgaGF2ZSBwdXQgdG9nZXRoZXIgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQ6 DQo+IA0KPiANCmh0dHA6Ly91c2Vycy5waXVoYS5uZXQvZ29uemFsby90ZW1wL2RyYWZ0LWlldGYt c2lwY29yZS1yZWludml0ZS1wcmUwMWEudHh0DQo+IA0KPiBMZXQgbWUga25vdyBpZiB5b3UgaGF2 ZSBzb21lIGNvbW1lbnRzIGJlZm9yZSBJIHN1Ym1pdCBpdC4NCj4gDQo+IFJlZ2FyZGluZyB0aGUg ZGVjaXNpb24gYWJvdXQgd2hlbiBhIGdpdmVuIGNoYW5nZSBpbiB0aGUgc2Vzc2lvbiBzdGF0ZQ0K PiBoYXMgYmVlbiBleGVjdXRlZCB3aGVuIHByZWNvbmRpdGlvbnMgYXJlIHVzZWQsIEkgaGF2ZSBh ZGRlZCBhIHBhcmFncmFwaA0KPiB0aGF0IHN1bW1hcml6ZXMgb3VyIGRpc2N1c3Npb25zIGFuZCB0 aGUgZm9sbG93aW5nIGRyYWZ0Og0KPiANCj4gDQpodHRwOi8vd3d3LndhdGVyc3ByaW5ncy5vcmcv cHViL2lkL2RyYWZ0LWNhbWFyaWxsby1zaXBwaW5nLXByZWNvbnMtMDAudHh0DQo+IA0KPiBQbGVh c2UsIHJlYWQgU2VjdGlvbiA1Lg0KPiANCj4gU2VjdGlvbnMgNyBhbmQgMTUgY29udGFpbiBuZXcg cnVsZXMgdG8gYXZvaWQgZ2xhcmUgc2l0dWF0aW9ucyBhbmQgcmFjZQ0KPiBjb25kaXRpb25zLiBU aGVzZSBydWxlcyBhdm9pZCBuYXN0eSBjYWxsIGZsb3dzIHRoYXQgd2VyZSBhYmxlIHRvIGdldCB0 aGUNCj4gVUFzIG91dCBvZiBzeW5jaC4NCj4gDQo+IFNvbWUgdGltZSBhZ28sIHdlIGRpc2N1c3Nl ZCB3aGV0aGVyIG9yIG5vdCB1bnJlbGlhYmxlIHByb3Zpc2lvbmFsDQo+IHJlc3BvbnNlcyBjb3Vs ZCByZWZyZXNoIHRoZSByZW1vdGUgdGFyZ2V0LiBUaGVyZSBhcmUgc2V2ZXJhbCBwcm9ibGVtcw0K PiB3aXRoIHVucmVsaWFibGUgcmVzcG9uc2VzIHVwZGF0aW5nIHJlbW90ZSB0YXJnZXRzLiBGaXJz dCwgd2Ugd291bGQgbmVlZA0KPiB0byBkZWZpbmUgZXZlbiBtb3JlIHJ1bGVzIHRvIGF2b2lkIGds YXJlIHNpdHVhdGlvbnMgYW5kIHJhY2UgY29uZGl0aW9ucy4NCj4gU2Vjb25kLCBTSVAgZG9lcyBu b3QgcHJvdmlkZSBhbnkgb3JkZXJpbmcgZm9yIHVucmVsaWFibGUgcHJvdmlzaW9uYWwNCj4gcmVz cG9uc2VzLiBSZXNwb25zZXMgYXJyaXZpbmcgb3V0IG9mIG9yZGVyIGF0IHRoZSBVQUMgY291bGQg ZWFzaWx5IGdldA0KPiBib3RoIFVBcyBvdXQgb2Ygc3luY2guIFRoZXJlZm9yZSwgb25seSByZWxp YWJsZSByZXNwb25zZXMgY2FuIHJlZnJlc2gNCj4gcmVtb3RlIHRhcmdldHMsIGFzIHdhcyBzcGVj aWZpZWQgaW4gUkZDIDMyNjEgYW55d2F5Lg0KPiANCj4gV2UgYWxzbyBkaXNjdXNzZWQgdGhlIGFw cGxpY2FiaWxpdHkgb2YgdGhlIHRhcmdldCByZWZyZXNoIHJ1bGVzIHRvDQo+IGluaXRpYWwgSU5W SVRFcy4gVGhlIHJ1bGVzIGluIHRoZSBkcmFmdCBjb3ZlciB0aGVtIGFzIHdlbGwgc28gSSBkbyBu b3QNCj4gdGhpbmsgd2UgbmVlZCB0byBhZGQgYW55dGhpbmcgZWxzZSB0byB0aGF0IGVuZC4NCj4g DQo+IFRoYW5rcywNCj4gDQo+IEdvbnphbG8NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+IHNpcGNv cmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj b3JlDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIA0KaXMgc29sZWx5IHByb3BlcnR5 IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIA0K aXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8g bWFpbnRhaW4gc2VjcmVjeSANCmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUg Y29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIA0Kb3RoZXJzLg0KPiBUaGlzIGVtYWls IGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCAN CmludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkg dG8gd2hvbSB0aGV5IGFyZSANCmFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSANCm9yaWdpbmF0b3Igb2YgdGhlIG1lc3Nh Z2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSANCm9mIHRo ZSBpbmRpdmlkdWFsIHNlbmRlci4NCj4gVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9y IHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSANCnN5c3RlbS4NCj4gDQoNCg0KDQoN Cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBv cmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVj aXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5k IGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11 bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVk IHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRo ZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMg bWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdl IGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBz eXN0ZW0uDQo= --=_alternative 0039611D482576AF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdvbnphbG8sPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5ZZXMsIEkgYWxzbyBmb3Vu ZCB0aGF0IDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPm5vdA0KbWFueSBwZW9wbGUgc2hvd2VkIGlu dGVyZXN0IGluIGl0LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5CeSBkZWVwbHkgZGlzY3Vzc2lvbiAmcXVvdDtSZS1JTlZJVEUNCmhhbmRsaW5n JnF1b3Q7IGRyYWZ0IHRoZXNlIGRheXMsIHdlIGZpbmQgdGhhdCB3ZSBzaG91bGQgY2xhcmlmeSBo b3cgbW9kaWZpZWQNCm1lZGlhIGNhbi9zaG91bGQgYmUgdXNlZC4gQnV0IGhvdyBtb2RpZmllZCBt ZWRpYSBjYW4vc2hvdWxkL21heSBiZSB1c2VkDQppcyBhIG1vcmUgYmFzaWMgdG9waWMuPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGlzIHRvcGljIGhh cyBpbmZsdWVuY2Ugb24gb3RoZXIgaGlnaGVyDQpsZXZlbCB0b3BpY3MsIHN1Y2ggYXMgJnF1b3Q7 UmUtSU5WSVRFIGhhbmRsaW5nJnF1b3Q7IGRyYWZ0IGFuZCBldGMuIFNvLA0KSSBob3BlIG1vcmUg cGVvcGxlIGNvdWxkIHBheSBhdHRlbnRpb24gdG8gaXQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6 IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWls IDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij48Yj5Hb256YWxvIENhbWFyaWxsbyAmbHQ7R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29t Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEw LTAxLTE4IDE2OjE0PC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPiZxdW90O2dhby55YW5nMkB6dGUuY29tLmNuJnF1b3Q7ICZsdDtnYW8ueWFu ZzJAenRlLmNvbS5jbiZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlNJUENPUkUgJmx0O3NpcGNvcmVA aWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW3NpcGNvcmVdIFF1ZXN0aW9uIG9u IGRyYWZ0LWNhbWFyaWxsby1zaXBjb3JlLXJlaW52aXRlLTAxLnR4dDwvZm9udD48L3RhYmxlPg0K PGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48 L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SGkgR2FvLDxicj4NCjxi cj4NCnRoYXQgaXMgd2h5IEkgd3JvdGUgdGhlIGRyYWZ0IGFib3V0IHByZWNvbmRpdGlvbnMuIEhv d2V2ZXIsIG5vdCBtYW55PGJyPg0KcGVvcGxlIHNob3dlZCBpbnRlcmVzdCBpbiBpdCBhdCB0aGF0 IHRpbWUuPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCjxicj4NCkdvbnphbG88YnI+DQo8YnI+DQpn YW8ueWFuZzJAenRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGksPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IE1heWJlIGNsYXJpZmljYXRpb24gb2YgcHJlY29ucyBoYXMgc29tZXRo aW5nIGJleW9uZCBSZS1JTlZJVEUgaGFuZGxpbmcNCjxicj4NCiZndDsgdGV4dC48YnI+DQomZ3Q7 IDxicj4NCiZndDsgQXMgUmUtSU5WSVRFIGhhbmRsaW5nIHRleHQgYWltcyBmb3IgdXBkYXRpbmcg b2YgUkZDMzI2MSwgd2UgbWF5IG5lZWQNCmEgPGJyPg0KJmd0OyBkZXRhaWxlZCBub3JtYXRpdmUg dGV4dCBmb3IgdXBkYXRpbmcgUkZDMzMxMiAmYW1wOyBSRkM0MDMyLiBBbmQgd2UNCmNhbiB0YWxr IDxicj4NCiZndDsgdG9waWNzIHJlbGF0aW5nIHRvIHByZWNvbnMgYnV0IG91dHNpZGUgb2YgdGhl IHNjb3BlIG9mIFJlLUlOVklURSA8YnI+DQomZ3Q7IGhhbmRsaW5nIHRleHQsIHN1Y2ggYXMgJnF1 b3Q7cmVzdW1pbmcgYW5kIHN1c3BlbmRpbmcgZm9yIHNlc3Npb24gb3INCmZvciA8YnI+DQomZ3Q7 IHNlcGFyYXRlIHN0cmVhbSZxdW90Oy48YnI+DQomZ3Q7IDxicj4NCiZndDsgVHdvIHNlcGFyYXRl IHRleHQgbWVhbnMgZGlmZmVyZW50IG1haW50ZW5hbmNlIHByb2Nlc3MgYW5kIGxpZmVjeWNsZS4N CklmIDxicj4NCiZndDsgd2UgY2FuIGd1YXJhbnRlZSB0aGUgY29uc2lzdGVuY3kgYW5kIGludGVn cmFsaXR5IG9mIHRoZSB0d28gdGV4dCwNCkkgPGJyPg0KJmd0OyB0aGluayB0d28gdGV4dCB3b3Vs ZCBiZSBjbGVhciBmb3IgdHdvIChyZWxhdGluZykgdG9waWNzLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBUaGFua3MsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEdhbzxicj4NCiZndDsgPGJyPg0KJmd0OyA9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiZndDsgWmlwICZuYnNwOyAm bmJzcDs6IDIxMDAxMjxicj4NCiZndDsgVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KJmd0 OyBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KJmd0OyBlX21haWwgOiBnYW8u eWFuZzJAenRlLmNvbS5jbjxicj4NCiZndDsgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT08YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAqR29uemFsbyBDYW1hcmlsbG8g Jmx0O0dvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbSZndDsqPGJyPg0KJmd0OyC3orz+yMs6 ICZuYnNwO3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzxicj4NCiZndDsgPGJyPg0KJmd0OyAyMDEw LTAxLTE0IDE2OjMzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyDK1bz+yMs8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7U0lQQ09SRQ0KJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7PGJyPg0KJmd0 OyCzrcvNPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsg1vfM4jxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSZToN CltzaXBjb3JlXSBRdWVzdGlvbiBvbiBkcmFmdC1jYW1hcmlsbG8tc2lwY29yZS1yZWludml0ZS0w MS50eHQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpLDxi cj4NCiZndDsgPGJyPg0KJmd0OyBJIGhhdmUgcHV0IHRvZ2V0aGVyIGEgbmV3IHZlcnNpb24gb2Yg dGhlIGRyYWZ0Ojxicj4NCiZndDsgPGJyPg0KJmd0OyBodHRwOi8vdXNlcnMucGl1aGEubmV0L2dv bnphbG8vdGVtcC9kcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtcHJlMDFhLnR4dDxicj4NCiZn dDsgPGJyPg0KJmd0OyBMZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBzb21lIGNvbW1lbnRzIGJlZm9y ZSBJIHN1Ym1pdCBpdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkaW5nIHRoZSBkZWNpc2lv biBhYm91dCB3aGVuIGEgZ2l2ZW4gY2hhbmdlIGluIHRoZSBzZXNzaW9uIHN0YXRlPGJyPg0KJmd0 OyBoYXMgYmVlbiBleGVjdXRlZCB3aGVuIHByZWNvbmRpdGlvbnMgYXJlIHVzZWQsIEkgaGF2ZSBh ZGRlZCBhIHBhcmFncmFwaDxicj4NCiZndDsgdGhhdCBzdW1tYXJpemVzIG91ciBkaXNjdXNzaW9u cyBhbmQgdGhlIGZvbGxvd2luZyBkcmFmdDo8YnI+DQomZ3Q7IDxicj4NCiZndDsgaHR0cDovL3d3 dy53YXRlcnNwcmluZ3Mub3JnL3B1Yi9pZC9kcmFmdC1jYW1hcmlsbG8tc2lwcGluZy1wcmVjb25z LTAwLnR4dDxicj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2UsIHJlYWQgU2VjdGlvbiA1Ljxicj4N CiZndDsgPGJyPg0KJmd0OyBTZWN0aW9ucyA3IGFuZCAxNSBjb250YWluIG5ldyBydWxlcyB0byBh dm9pZCBnbGFyZSBzaXR1YXRpb25zIGFuZA0KcmFjZTxicj4NCiZndDsgY29uZGl0aW9ucy4gVGhl c2UgcnVsZXMgYXZvaWQgbmFzdHkgY2FsbCBmbG93cyB0aGF0IHdlcmUgYWJsZSB0byBnZXQNCnRo ZTxicj4NCiZndDsgVUFzIG91dCBvZiBzeW5jaC48YnI+DQomZ3Q7IDxicj4NCiZndDsgU29tZSB0 aW1lIGFnbywgd2UgZGlzY3Vzc2VkIHdoZXRoZXIgb3Igbm90IHVucmVsaWFibGUgcHJvdmlzaW9u YWw8YnI+DQomZ3Q7IHJlc3BvbnNlcyBjb3VsZCByZWZyZXNoIHRoZSByZW1vdGUgdGFyZ2V0LiBU aGVyZSBhcmUgc2V2ZXJhbCBwcm9ibGVtczxicj4NCiZndDsgd2l0aCB1bnJlbGlhYmxlIHJlc3Bv bnNlcyB1cGRhdGluZyByZW1vdGUgdGFyZ2V0cy4gRmlyc3QsIHdlIHdvdWxkDQpuZWVkPGJyPg0K Jmd0OyB0byBkZWZpbmUgZXZlbiBtb3JlIHJ1bGVzIHRvIGF2b2lkIGdsYXJlIHNpdHVhdGlvbnMg YW5kIHJhY2UgY29uZGl0aW9ucy48YnI+DQomZ3Q7IFNlY29uZCwgU0lQIGRvZXMgbm90IHByb3Zp ZGUgYW55IG9yZGVyaW5nIGZvciB1bnJlbGlhYmxlIHByb3Zpc2lvbmFsPGJyPg0KJmd0OyByZXNw b25zZXMuIFJlc3BvbnNlcyBhcnJpdmluZyBvdXQgb2Ygb3JkZXIgYXQgdGhlIFVBQyBjb3VsZCBl YXNpbHkNCmdldDxicj4NCiZndDsgYm90aCBVQXMgb3V0IG9mIHN5bmNoLiBUaGVyZWZvcmUsIG9u bHkgcmVsaWFibGUgcmVzcG9uc2VzIGNhbiByZWZyZXNoPGJyPg0KJmd0OyByZW1vdGUgdGFyZ2V0 cywgYXMgd2FzIHNwZWNpZmllZCBpbiBSRkMgMzI2MSBhbnl3YXkuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFdlIGFsc28gZGlzY3Vzc2VkIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSB0YXJnZXQgcmVm cmVzaCBydWxlcyB0bzxicj4NCiZndDsgaW5pdGlhbCBJTlZJVEVzLiBUaGUgcnVsZXMgaW4gdGhl IGRyYWZ0IGNvdmVyIHRoZW0gYXMgd2VsbCBzbyBJIGRvDQpub3Q8YnI+DQomZ3Q7IHRoaW5rIHdl IG5lZWQgdG8gYWRkIGFueXRoaW5nIGVsc2UgdG8gdGhhdCBlbmQuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFRoYW5rcyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgR29uemFsbzxicj4NCiZndDsgPGJyPg0K Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsgc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IHNpcGNvcmVAaWV0Zi5vcmc8YnI+ DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxicj4N CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IFpURSBJbmZv cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cw0KbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4g VGhpcyBtYWlsIGNvbW11bmljYXRpb24NCmlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1l ZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kNCmFuZCBhcmUgbm90IHBl cm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRv DQpvdGhlcnMuPGJyPg0KJmd0OyBUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZA0KaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlDQphZGRyZXNzZWQu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvcg0Kb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjxicj4NCiZndDsg VGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRF IEFudGktU3BhbQ0Kc3lzdGVtLjxicj4NCiZndDsgPGJyPg0KPGJyPg0KPGJyPg0KPC9mb250Pjwv dHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5 Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5i c3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVy dHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNw O1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50 aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7 b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJz cDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7 dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5i c3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJz cDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7 Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3Im bmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtv ciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDth ZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0 aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5 Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4m bmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNw O21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZp ZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZu YnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNw O2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0039611D482576AF_=-- From gonzalo.camarillo@ericsson.com Mon Jan 18 03:51:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F36B3A67CF for ; Mon, 18 Jan 2010 03:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.846 X-Spam-Level: X-Spam-Status: No, score=-104.846 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHKMonLGDZ-o for ; Mon, 18 Jan 2010 03:51:19 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 4063A3A6405 for ; Mon, 18 Jan 2010 03:51:18 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-32-4b544b31b897 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 11.D5.04178.13B445B4; Mon, 18 Jan 2010 12:51:14 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 12:49:45 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 12:49:44 +0100 Message-ID: <4B544AD8.7020104@ericsson.com> Date: Mon, 18 Jan 2010 13:49:44 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "gao.yang2@zte.com.cn" References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 18 Jan 2010 11:49:44.0966 (UTC) FILETIME=[5411E260:01CA9834] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 11:51:21 -0000 Hi Gao, let's proceed as follows. Let's focus our efforts in finishing the re-INVITE draft for now. Once we are done with it, let's decide whether or not we want to work on clarifying all the open issues related to preconditions we have been talking about. Thanks, Gonzalo gao.yang2@zte.com.cn wrote: > > Hi Gonzalo, > > Yes, I also found that not many people showed interest in it. > > By deeply discussion "Re-INVITE handling" draft these days, we find that > we should clarify how modified media can/should be used. But how > modified media can/should/may be used is a more basic topic. > > This topic has influence on other higher level topics, such as > "Re-INVITE handling" draft and etc. So, I hope more people could pay > attention to it. > > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > *Gonzalo Camarillo * > > 2010-01-18 16:14 > > > 收件人 > "gao.yang2@zte.com.cn" > 抄送 > SIPCORE > 主题 > Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt > > > > > > > > > Hi Gao, > > that is why I wrote the draft about preconditions. However, not many > people showed interest in it at that time. > > Cheers, > > Gonzalo > > gao.yang2@zte.com.cn wrote: > > > > Hi, > > > > Maybe clarification of precons has something beyond Re-INVITE handling > > text. > > > > As Re-INVITE handling text aims for updating of RFC3261, we may need a > > detailed normative text for updating RFC3312 & RFC4032. And we can talk > > topics relating to precons but outside of the scope of Re-INVITE > > handling text, such as "resuming and suspending for session or for > > separate stream". > > > > Two separate text means different maintenance process and lifecycle. If > > we can guarantee the consistency and integrality of the two text, I > > think two text would be clear for two (relating) topics. > > > > Thanks, > > > > Gao > > > > =================================== > > Zip : 210012 > > Tel : 87211 > > Tel2 :(+86)-025-52877211 > > e_mail : gao.yang2@zte.com.cn > > =================================== > > > > > > *Gonzalo Camarillo * > > 发件人: sipcore-bounces@ietf.org > > > > 2010-01-14 16:33 > > > > > > 收件人 > > SIPCORE > > 抄送 > > > > 主题 > > Re: [sipcore] Question on > draft-camarillo-sipcore-reinvite-01.txt > > > > > > > > > > > > > > > > > > Hi, > > > > I have put together a new version of the draft: > > > > > http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre01a.txt > > > > Let me know if you have some comments before I submit it. > > > > Regarding the decision about when a given change in the session state > > has been executed when preconditions are used, I have added a paragraph > > that summarizes our discussions and the following draft: > > > > http://www.watersprings.org/pub/id/draft-camarillo-sipping-precons-00.txt > > > > Please, read Section 5. > > > > Sections 7 and 15 contain new rules to avoid glare situations and race > > conditions. These rules avoid nasty call flows that were able to get the > > UAs out of synch. > > > > Some time ago, we discussed whether or not unreliable provisional > > responses could refresh the remote target. There are several problems > > with unreliable responses updating remote targets. First, we would need > > to define even more rules to avoid glare situations and race conditions. > > Second, SIP does not provide any ordering for unreliable provisional > > responses. Responses arriving out of order at the UAC could easily get > > both UAs out of synch. Therefore, only reliable responses can refresh > > remote targets, as was specified in RFC 3261 anyway. > > > > We also discussed the applicability of the target refresh rules to > > initial INVITEs. The rules in the draft cover them as well so I do not > > think we need to add anything else to that end. > > > > Thanks, > > > > Gonzalo > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated to > maintain secrecy and are not permitted to disclose the contents of this > communication to others. > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you have received this email in error please notify the > originator of the message. Any views expressed in this message are those > of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > From gao.yang2@zte.com.cn Mon Jan 18 04:13:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8505B3A683D for ; Mon, 18 Jan 2010 04:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.493 X-Spam-Level: X-Spam-Status: No, score=-92.493 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25CtYLQqkfyl for ; Mon, 18 Jan 2010 04:13:45 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 7F19A3A6916 for ; Mon, 18 Jan 2010 04:13:36 -0800 (PST) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91101727820181; Mon, 18 Jan 2010 19:47:34 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 78921.2980680612; Mon, 18 Jan 2010 20:04:35 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o0IC4gwf089671; Mon, 18 Jan 2010 20:04:42 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4B544AD8.7020104@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 18 Jan 2010 20:03:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-01-18 20:04:24, Serialize complete at 2010-01-18 20:04:24 Content-Type: multipart/alternative; boundary="=_alternative 00425A22482576AF_=" X-MAIL: mse2.zte.com.cn o0IC4gwf089671 Cc: SIPCORE Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBRdWVzdGlvbiBvbiBkcmFmdC1jYW1h?= =?gb2312?b?cmlsbG8tc2lwY29yZS1yZWludml0ZS0wMS50eHQ=?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 12:13:47 -0000 This is a multipart message in MIME format. --=_alternative 00425A22482576AF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR29uemFsbywNCg0KWWVzLCB3ZSBjYW4gZG8gaXQgaW4gZGlmZmVyZW50IHNlcXVlbmNlLg0K DQpDaGVlcnMsDQoNCkdhbw0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K IFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4 NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCg0KDQoNCkdvbnphbG8gQ2FtYXJpbGxvIDxHb256YWxvLkNhbWFy aWxsb0Blcmljc3Nvbi5jb20+IA0Kt6K8/sjLOiAgc2lwY29yZS1ib3VuY2VzQGlldGYub3JnDQoy MDEwLTAxLTE4IDE5OjQ5DQoNCsrVvP7Iyw0KImdhby55YW5nMkB6dGUuY29tLmNuIiA8Z2FvLnlh bmcyQHp0ZS5jb20uY24+DQqzrcvNDQpTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0K1vfM4g0K UmU6IFtzaXBjb3JlXSBRdWVzdGlvbiBvbiBkcmFmdC1jYW1hcmlsbG8tc2lwY29yZS1yZWludml0 ZS0wMS50eHQNCg0KDQoNCg0KDQoNCkhpIEdhbywNCg0KbGV0J3MgcHJvY2VlZCBhcyBmb2xsb3dz LiBMZXQncyBmb2N1cyBvdXIgZWZmb3J0cyBpbiBmaW5pc2hpbmcgdGhlDQpyZS1JTlZJVEUgZHJh ZnQgZm9yIG5vdy4gT25jZSB3ZSBhcmUgZG9uZSB3aXRoIGl0LCBsZXQncyBkZWNpZGUgd2hldGhl cg0Kb3Igbm90IHdlIHdhbnQgdG8gd29yayBvbiBjbGFyaWZ5aW5nIGFsbCB0aGUgb3BlbiBpc3N1 ZXMgcmVsYXRlZCB0bw0KcHJlY29uZGl0aW9ucyB3ZSBoYXZlIGJlZW4gdGFsa2luZyBhYm91dC4N Cg0KVGhhbmtzLA0KDQpHb256YWxvDQoNCmdhby55YW5nMkB6dGUuY29tLmNuIHdyb3RlOg0KPiAN Cj4gSGkgR29uemFsbywNCj4gDQo+IFllcywgSSBhbHNvIGZvdW5kIHRoYXQgbm90IG1hbnkgcGVv cGxlIHNob3dlZCBpbnRlcmVzdCBpbiBpdC4NCj4gDQo+IEJ5IGRlZXBseSBkaXNjdXNzaW9uICJS ZS1JTlZJVEUgaGFuZGxpbmciIGRyYWZ0IHRoZXNlIGRheXMsIHdlIGZpbmQgdGhhdCANCg0KPiB3 ZSBzaG91bGQgY2xhcmlmeSBob3cgbW9kaWZpZWQgbWVkaWEgY2FuL3Nob3VsZCBiZSB1c2VkLiBC dXQgaG93IA0KPiBtb2RpZmllZCBtZWRpYSBjYW4vc2hvdWxkL21heSBiZSB1c2VkIGlzIGEgbW9y ZSBiYXNpYyB0b3BpYy4NCj4gDQo+IFRoaXMgdG9waWMgaGFzIGluZmx1ZW5jZSBvbiBvdGhlciBo aWdoZXIgbGV2ZWwgdG9waWNzLCBzdWNoIGFzIA0KPiAiUmUtSU5WSVRFIGhhbmRsaW5nIiBkcmFm dCBhbmQgZXRjLiBTbywgSSBob3BlIG1vcmUgcGVvcGxlIGNvdWxkIHBheSANCj4gYXR0ZW50aW9u IHRvIGl0Lg0KPiANCj4gVGhhbmtzLA0KPiANCj4gR2FvDQo+IA0KPiA9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KPiBaaXAgICAgOiAyMTAwMTINCj4gVGVsICAgIDogODcyMTEN Cj4gVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCj4gZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5j b20uY24NCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gDQo+IA0KPiAq R29uemFsbyBDYW1hcmlsbG8gPEdvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbT4qDQo+IA0K PiAyMDEwLTAxLTE4IDE2OjE0DQo+IA0KPiANCj4gytW8/sjLDQo+ICAgICAgICAgICAgICAgICJn YW8ueWFuZzJAenRlLmNvbS5jbiIgPGdhby55YW5nMkB6dGUuY29tLmNuPg0KPiCzrcvNDQo+ICAg ICAgICAgICAgICAgIFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc+DQo+INb3zOINCj4gICAgICAg ICAgICAgICAgUmU6IFtzaXBjb3JlXSBRdWVzdGlvbiBvbiANCmRyYWZ0LWNhbWFyaWxsby1zaXBj b3JlLXJlaW52aXRlLTAxLnR4dA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IEhp IEdhbywNCj4gDQo+IHRoYXQgaXMgd2h5IEkgd3JvdGUgdGhlIGRyYWZ0IGFib3V0IHByZWNvbmRp dGlvbnMuIEhvd2V2ZXIsIG5vdCBtYW55DQo+IHBlb3BsZSBzaG93ZWQgaW50ZXJlc3QgaW4gaXQg YXQgdGhhdCB0aW1lLg0KPiANCj4gQ2hlZXJzLA0KPiANCj4gR29uemFsbw0KPiANCj4gZ2FvLnlh bmcyQHp0ZS5jb20uY24gd3JvdGU6DQo+ICA+DQo+ICA+IEhpLA0KPiAgPg0KPiAgPiBNYXliZSBj bGFyaWZpY2F0aW9uIG9mIHByZWNvbnMgaGFzIHNvbWV0aGluZyBiZXlvbmQgUmUtSU5WSVRFIA0K aGFuZGxpbmcNCj4gID4gdGV4dC4NCj4gID4NCj4gID4gQXMgUmUtSU5WSVRFIGhhbmRsaW5nIHRl eHQgYWltcyBmb3IgdXBkYXRpbmcgb2YgUkZDMzI2MSwgd2UgbWF5IG5lZWQgDQphDQo+ICA+IGRl dGFpbGVkIG5vcm1hdGl2ZSB0ZXh0IGZvciB1cGRhdGluZyBSRkMzMzEyICYgUkZDNDAzMi4gQW5k IHdlIGNhbiANCnRhbGsNCj4gID4gdG9waWNzIHJlbGF0aW5nIHRvIHByZWNvbnMgYnV0IG91dHNp ZGUgb2YgdGhlIHNjb3BlIG9mIFJlLUlOVklURQ0KPiAgPiBoYW5kbGluZyB0ZXh0LCBzdWNoIGFz ICJyZXN1bWluZyBhbmQgc3VzcGVuZGluZyBmb3Igc2Vzc2lvbiBvciBmb3INCj4gID4gc2VwYXJh dGUgc3RyZWFtIi4NCj4gID4NCj4gID4gVHdvIHNlcGFyYXRlIHRleHQgbWVhbnMgZGlmZmVyZW50 IG1haW50ZW5hbmNlIHByb2Nlc3MgYW5kIGxpZmVjeWNsZS4gDQpJZg0KPiAgPiB3ZSBjYW4gZ3Vh cmFudGVlIHRoZSBjb25zaXN0ZW5jeSBhbmQgaW50ZWdyYWxpdHkgb2YgdGhlIHR3byB0ZXh0LCBJ DQo+ICA+IHRoaW5rIHR3byB0ZXh0IHdvdWxkIGJlIGNsZWFyIGZvciB0d28gKHJlbGF0aW5nKSB0 b3BpY3MuDQo+ICA+DQo+ICA+IFRoYW5rcywNCj4gID4NCj4gID4gR2FvDQo+ICA+DQo+ICA+ID09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ICA+IFppcCAgICA6IDIxMDAxMg0K PiAgPiBUZWwgICAgOiA4NzIxMQ0KPiAgPiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KPiAg PiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPiAgPiA9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KPiAgPg0KPiAgPg0KPiAgPiAqR29uemFsbyBDYW1hcmlsbG8gPEdv bnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbT4qDQo+ICA+ILeivP7IyzogIHNpcGNvcmUtYm91 bmNlc0BpZXRmLm9yZw0KPiAgPg0KPiAgPiAyMDEwLTAxLTE0IDE2OjMzDQo+ICA+DQo+ICA+IA0K PiAgPiDK1bz+yMsNCj4gID4gICAgICAgICAgICAgICAgICBTSVBDT1JFIDxzaXBjb3JlQGlldGYu b3JnPg0KPiAgPiCzrcvNDQo+ICA+IA0KPiAgPiDW98ziDQo+ICA+ICAgICAgICAgICAgICAgICAg UmU6IFtzaXBjb3JlXSBRdWVzdGlvbiBvbiANCj4gZHJhZnQtY2FtYXJpbGxvLXNpcGNvcmUtcmVp bnZpdGUtMDEudHh0DQo+ICA+DQo+ICA+DQo+ICA+IA0KPiAgPg0KPiAgPg0KPiAgPg0KPiAgPg0K PiAgPg0KPiAgPiBIaSwNCj4gID4NCj4gID4gSSBoYXZlIHB1dCB0b2dldGhlciBhIG5ldyB2ZXJz aW9uIG9mIHRoZSBkcmFmdDoNCj4gID4NCj4gID4gDQo+IA0KaHR0cDovL3VzZXJzLnBpdWhhLm5l dC9nb256YWxvL3RlbXAvZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLXByZTAxYS50eHQNCj4g ID4NCj4gID4gTGV0IG1lIGtub3cgaWYgeW91IGhhdmUgc29tZSBjb21tZW50cyBiZWZvcmUgSSBz dWJtaXQgaXQuDQo+ICA+DQo+ICA+IFJlZ2FyZGluZyB0aGUgZGVjaXNpb24gYWJvdXQgd2hlbiBh IGdpdmVuIGNoYW5nZSBpbiB0aGUgc2Vzc2lvbiBzdGF0ZQ0KPiAgPiBoYXMgYmVlbiBleGVjdXRl ZCB3aGVuIHByZWNvbmRpdGlvbnMgYXJlIHVzZWQsIEkgaGF2ZSBhZGRlZCBhIA0KcGFyYWdyYXBo DQo+ICA+IHRoYXQgc3VtbWFyaXplcyBvdXIgZGlzY3Vzc2lvbnMgYW5kIHRoZSBmb2xsb3dpbmcg ZHJhZnQ6DQo+ICA+DQo+ICA+IA0KaHR0cDovL3d3dy53YXRlcnNwcmluZ3Mub3JnL3B1Yi9pZC9k cmFmdC1jYW1hcmlsbG8tc2lwcGluZy1wcmVjb25zLTAwLnR4dA0KPiAgPg0KPiAgPiBQbGVhc2Us IHJlYWQgU2VjdGlvbiA1Lg0KPiAgPg0KPiAgPiBTZWN0aW9ucyA3IGFuZCAxNSBjb250YWluIG5l dyBydWxlcyB0byBhdm9pZCBnbGFyZSBzaXR1YXRpb25zIGFuZCANCnJhY2UNCj4gID4gY29uZGl0 aW9ucy4gVGhlc2UgcnVsZXMgYXZvaWQgbmFzdHkgY2FsbCBmbG93cyB0aGF0IHdlcmUgYWJsZSB0 byBnZXQgDQp0aGUNCj4gID4gVUFzIG91dCBvZiBzeW5jaC4NCj4gID4NCj4gID4gU29tZSB0aW1l IGFnbywgd2UgZGlzY3Vzc2VkIHdoZXRoZXIgb3Igbm90IHVucmVsaWFibGUgcHJvdmlzaW9uYWwN Cj4gID4gcmVzcG9uc2VzIGNvdWxkIHJlZnJlc2ggdGhlIHJlbW90ZSB0YXJnZXQuIFRoZXJlIGFy ZSBzZXZlcmFsIHByb2JsZW1zDQo+ICA+IHdpdGggdW5yZWxpYWJsZSByZXNwb25zZXMgdXBkYXRp bmcgcmVtb3RlIHRhcmdldHMuIEZpcnN0LCB3ZSB3b3VsZCANCm5lZWQNCj4gID4gdG8gZGVmaW5l IGV2ZW4gbW9yZSBydWxlcyB0byBhdm9pZCBnbGFyZSBzaXR1YXRpb25zIGFuZCByYWNlIA0KY29u ZGl0aW9ucy4NCj4gID4gU2Vjb25kLCBTSVAgZG9lcyBub3QgcHJvdmlkZSBhbnkgb3JkZXJpbmcg Zm9yIHVucmVsaWFibGUgcHJvdmlzaW9uYWwNCj4gID4gcmVzcG9uc2VzLiBSZXNwb25zZXMgYXJy aXZpbmcgb3V0IG9mIG9yZGVyIGF0IHRoZSBVQUMgY291bGQgZWFzaWx5IA0KZ2V0DQo+ICA+IGJv dGggVUFzIG91dCBvZiBzeW5jaC4gVGhlcmVmb3JlLCBvbmx5IHJlbGlhYmxlIHJlc3BvbnNlcyBj YW4gcmVmcmVzaA0KPiAgPiByZW1vdGUgdGFyZ2V0cywgYXMgd2FzIHNwZWNpZmllZCBpbiBSRkMg MzI2MSBhbnl3YXkuDQo+ICA+DQo+ICA+IFdlIGFsc28gZGlzY3Vzc2VkIHRoZSBhcHBsaWNhYmls aXR5IG9mIHRoZSB0YXJnZXQgcmVmcmVzaCBydWxlcyB0bw0KPiAgPiBpbml0aWFsIElOVklURXMu IFRoZSBydWxlcyBpbiB0aGUgZHJhZnQgY292ZXIgdGhlbSBhcyB3ZWxsIHNvIEkgZG8gDQpub3QN Cj4gID4gdGhpbmsgd2UgbmVlZCB0byBhZGQgYW55dGhpbmcgZWxzZSB0byB0aGF0IGVuZC4NCj4g ID4NCj4gID4gVGhhbmtzLA0KPiAgPg0KPiAgPiBHb256YWxvDQo+ICA+DQo+ICA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICA+IHNpcGNvcmUgbWFp bGluZyBsaXN0DQo+ICA+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+ICA+DQo+ICA+DQo+ICA+DQo+ICA+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICA+ IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyANCj4gbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9y Z2FuaXphdGlvbi4gVGhpcyBtYWlsIA0KPiBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4g UmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIA0KPiBtYWludGFpbiBzZWNy ZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhp cyANCj4gY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQo+ICA+IFRoaXMgZW1haWwgYW5kIGFueSBm aWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIA0KPiBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20g dGhleSBhcmUgDQoNCj4gYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIA0KPiBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdl LiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2UgDQoNCj4gb2Yg dGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KPiAgPiBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5l ZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIA0KPiBzeXN0ZW0uDQo+ICA+ DQo+IA0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCANCmlzIHNvbGVseSBwcm9wZXJ0 eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiAN CmlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRv IG1haW50YWluIHNlY3JlY3kgDQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhl IGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byANCm90aGVycy4NCj4gVGhpcyBlbWFp bCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQg DQppbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5 IHRvIHdob20gdGhleSBhcmUgDQphZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgDQpvcmlnaW5hdG9yIG9mIHRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2UgDQpvZiB0 aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQo+IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZv ciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0uDQo+IA0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWls aW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwY29yZQ0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGlj ZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3Bl cnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9u IGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRv IG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBj b250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQg YW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9t IHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmll d3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwg c2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNw YW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 00425A22482576AF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdvbnphbG8sPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5ZZXMsIHdlIGNhbiBkbyBp dCBpbiBkaWZmZXJlbnQgc2VxdWVuY2UuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5DaGVlcnMsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFpp cCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJy Pg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlh bmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwv Zm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Hb256 YWxvIENhbWFyaWxsbyAmbHQ7R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tJmd0OzwvYj4N CjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJz cDtzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+MjAxMC0wMS0xOCAxOTo0OTwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtnYW8ueWFuZzJAenRlLmNvbS5jbiZx dW90OyAmbHQ7Z2FvLnlhbmcyQHp0ZS5jb20uY24mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6z rcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TSVBD T1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtzaXBj b3JlXSBRdWVzdGlvbiBvbiBkcmFmdC1jYW1hcmlsbG8tc2lwY29yZS1yZWludml0ZS0wMS50eHQ8 L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRk PjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PkhpIEdhbyw8YnI+DQo8YnI+DQpsZXQncyBwcm9jZWVkIGFzIGZvbGxvd3MuIExldCdzIGZvY3Vz IG91ciBlZmZvcnRzIGluIGZpbmlzaGluZyB0aGU8YnI+DQpyZS1JTlZJVEUgZHJhZnQgZm9yIG5v dy4gT25jZSB3ZSBhcmUgZG9uZSB3aXRoIGl0LCBsZXQncyBkZWNpZGUgd2hldGhlcjxicj4NCm9y IG5vdCB3ZSB3YW50IHRvIHdvcmsgb24gY2xhcmlmeWluZyBhbGwgdGhlIG9wZW4gaXNzdWVzIHJl bGF0ZWQgdG88YnI+DQpwcmVjb25kaXRpb25zIHdlIGhhdmUgYmVlbiB0YWxraW5nIGFib3V0Ljxi cj4NCjxicj4NClRoYW5rcyw8YnI+DQo8YnI+DQpHb256YWxvPGJyPg0KPGJyPg0KZ2FvLnlhbmcy QHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpIEdvbnphbG8sPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFllcywgSSBhbHNvIGZvdW5kIHRoYXQgbm90IG1hbnkgcGVvcGxlIHNo b3dlZCBpbnRlcmVzdCBpbiBpdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgQnkgZGVlcGx5IGRpc2N1 c3Npb24gJnF1b3Q7UmUtSU5WSVRFIGhhbmRsaW5nJnF1b3Q7IGRyYWZ0IHRoZXNlIGRheXMsDQp3 ZSBmaW5kIHRoYXQgPGJyPg0KJmd0OyB3ZSBzaG91bGQgY2xhcmlmeSBob3cgbW9kaWZpZWQgbWVk aWEgY2FuL3Nob3VsZCBiZSB1c2VkLiBCdXQgaG93IDxicj4NCiZndDsgbW9kaWZpZWQgbWVkaWEg Y2FuL3Nob3VsZC9tYXkgYmUgdXNlZCBpcyBhIG1vcmUgYmFzaWMgdG9waWMuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IFRoaXMgdG9waWMgaGFzIGluZmx1ZW5jZSBvbiBvdGhlciBoaWdoZXIgbGV2ZWwg dG9waWNzLCBzdWNoIGFzIDxicj4NCiZndDsgJnF1b3Q7UmUtSU5WSVRFIGhhbmRsaW5nJnF1b3Q7 IGRyYWZ0IGFuZCBldGMuIFNvLCBJIGhvcGUgbW9yZSBwZW9wbGUNCmNvdWxkIHBheSA8YnI+DQom Z3Q7IGF0dGVudGlvbiB0byBpdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZn dDsgPGJyPg0KJmd0OyBHYW88YnI+DQomZ3Q7IDxicj4NCiZndDsgPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7IFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+ DQomZ3Q7IFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiZndDsgVGVsMiAmbmJzcDsgOigr ODYpLTAyNS01Mjg3NzIxMTxicj4NCiZndDsgZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248 YnI+DQomZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgKkdvbnphbG8gQ2FtYXJpbGxvICZsdDtHb256YWxvLkNhbWFy aWxsb0Blcmljc3Nvbi5jb20mZ3Q7Kjxicj4NCiZndDsgPGJyPg0KJmd0OyAyMDEwLTAxLTE4IDE2 OjE0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyDK1bz+yMs8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7JnF1b3Q7Z2FvLnlhbmcyQHp0ZS5jb20uY24mcXVvdDsNCiZsdDtnYW8ueWFuZzJAenRl LmNvbS5jbiZndDs8YnI+DQomZ3Q7ILOty808YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U0lQQ09SRQ0KJmx0O3Np cGNvcmVAaWV0Zi5vcmcmZ3Q7PGJyPg0KJmd0OyDW98ziPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1JlOg0KW3Np cGNvcmVdIFF1ZXN0aW9uIG9uIGRyYWZ0LWNhbWFyaWxsby1zaXBjb3JlLXJlaW52aXRlLTAxLnR4 dDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQom Z3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkgR2FvLDxi cj4NCiZndDsgPGJyPg0KJmd0OyB0aGF0IGlzIHdoeSBJIHdyb3RlIHRoZSBkcmFmdCBhYm91dCBw cmVjb25kaXRpb25zLiBIb3dldmVyLCBub3QgbWFueTxicj4NCiZndDsgcGVvcGxlIHNob3dlZCBp bnRlcmVzdCBpbiBpdCBhdCB0aGF0IHRpbWUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENoZWVycyw8 YnI+DQomZ3Q7IDxicj4NCiZndDsgR29uemFsbzxicj4NCiZndDsgPGJyPg0KJmd0OyBnYW8ueWFu ZzJAenRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNw OyZndDsgSGksPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IE1heWJl IGNsYXJpZmljYXRpb24gb2YgcHJlY29ucyBoYXMgc29tZXRoaW5nIGJleW9uZCBSZS1JTlZJVEUN CmhhbmRsaW5nPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IHRleHQuPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IEFzIFJlLUlOVklURSBoYW5kbGluZyB0ZXh0IGFpbXMgZm9y IHVwZGF0aW5nIG9mIFJGQzMyNjEsDQp3ZSBtYXkgbmVlZCBhPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 IGRldGFpbGVkIG5vcm1hdGl2ZSB0ZXh0IGZvciB1cGRhdGluZyBSRkMzMzEyICZhbXA7IFJGQzQw MzIuDQpBbmQgd2UgY2FuIHRhbGs8YnI+DQomZ3Q7ICZuYnNwOyZndDsgdG9waWNzIHJlbGF0aW5n IHRvIHByZWNvbnMgYnV0IG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mDQpSZS1JTlZJVEU8YnI+DQom Z3Q7ICZuYnNwOyZndDsgaGFuZGxpbmcgdGV4dCwgc3VjaCBhcyAmcXVvdDtyZXN1bWluZyBhbmQg c3VzcGVuZGluZyBmb3INCnNlc3Npb24gb3IgZm9yPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IHNlcGFy YXRlIHN0cmVhbSZxdW90Oy48YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZn dDsgVHdvIHNlcGFyYXRlIHRleHQgbWVhbnMgZGlmZmVyZW50IG1haW50ZW5hbmNlIHByb2Nlc3Mg YW5kDQpsaWZlY3ljbGUuIElmPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IHdlIGNhbiBndWFyYW50ZWUg dGhlIGNvbnNpc3RlbmN5IGFuZCBpbnRlZ3JhbGl0eSBvZiB0aGUNCnR3byB0ZXh0LCBJPGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7IHRoaW5rIHR3byB0ZXh0IHdvdWxkIGJlIGNsZWFyIGZvciB0d28gKHJl bGF0aW5nKSB0b3BpY3MuPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 IFRoYW5rcyw8YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsgR2FvPGJy Pg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7ID09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IFppcCAmbmJzcDsgJm5ic3A7 OiAyMTAwMTI8YnI+DQomZ3Q7ICZuYnNwOyZndDsgVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJy Pg0KJmd0OyAmbmJzcDsmZ3Q7IFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQom Z3Q7ICZuYnNwOyZndDsgZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQomZ3Q7ICZu YnNwOyZndDsgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7ICZu YnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsgKkdvbnph bG8gQ2FtYXJpbGxvICZsdDtHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20mZ3Q7Kjxicj4N CiZndDsgJm5ic3A7Jmd0OyC3orz+yMs6ICZuYnNwO3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzxi cj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyAyMDEwLTAxLTE0IDE2OjMz PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzxicj4NCiZn dDsgJm5ic3A7Jmd0OyDK1bz+yMs8YnI+DQomZ3Q7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7U0lQQ09SRSAm bHQ7c2lwY29yZUBpZXRmLm9yZyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsgs63LzTxicj4NCiZn dDsgJm5ic3A7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsg1vfM4jxicj4NCiZndDsg Jm5ic3A7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDtSZTogW3NpcGNvcmVdIFF1ZXN0aW9uIG9uIDxicj4NCiZndDsgZHJh ZnQtY2FtYXJpbGxvLXNpcGNvcmUtcmVpbnZpdGUtMDEudHh0PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzxicj4NCiZn dDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0Ozxi cj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7 Jmd0OyBIaSw8YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsgSSBoYXZl IHB1dCB0b2dldGhlciBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdDo8YnI+DQomZ3Q7ICZuYnNw OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsgPGJyPg0KJmd0OyBodHRwOi8vdXNlcnMucGl1aGEu bmV0L2dvbnphbG8vdGVtcC9kcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGUtcHJlMDFhLnR4dDxi cj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyBMZXQgbWUga25vdyBpZiB5 b3UgaGF2ZSBzb21lIGNvbW1lbnRzIGJlZm9yZSBJIHN1Ym1pdCBpdC48YnI+DQomZ3Q7ICZuYnNw OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsgUmVnYXJkaW5nIHRoZSBkZWNpc2lvbiBhYm91dCB3 aGVuIGEgZ2l2ZW4gY2hhbmdlIGluIHRoZQ0Kc2Vzc2lvbiBzdGF0ZTxicj4NCiZndDsgJm5ic3A7 Jmd0OyBoYXMgYmVlbiBleGVjdXRlZCB3aGVuIHByZWNvbmRpdGlvbnMgYXJlIHVzZWQsIEkgaGF2 ZSBhZGRlZA0KYSBwYXJhZ3JhcGg8YnI+DQomZ3Q7ICZuYnNwOyZndDsgdGhhdCBzdW1tYXJpemVz IG91ciBkaXNjdXNzaW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkcmFmdDo8YnI+DQomZ3Q7ICZuYnNw OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsgaHR0cDovL3d3dy53YXRlcnNwcmluZ3Mub3JnL3B1 Yi9pZC9kcmFmdC1jYW1hcmlsbG8tc2lwcGluZy1wcmVjb25zLTAwLnR4dDxicj4NCiZndDsgJm5i c3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyBQbGVhc2UsIHJlYWQgU2VjdGlvbiA1Ljxicj4N CiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyBTZWN0aW9ucyA3IGFuZCAxNSBj b250YWluIG5ldyBydWxlcyB0byBhdm9pZCBnbGFyZSBzaXR1YXRpb25zDQphbmQgcmFjZTxicj4N CiZndDsgJm5ic3A7Jmd0OyBjb25kaXRpb25zLiBUaGVzZSBydWxlcyBhdm9pZCBuYXN0eSBjYWxs IGZsb3dzIHRoYXQgd2VyZQ0KYWJsZSB0byBnZXQgdGhlPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IFVB cyBvdXQgb2Ygc3luY2guPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 IFNvbWUgdGltZSBhZ28sIHdlIGRpc2N1c3NlZCB3aGV0aGVyIG9yIG5vdCB1bnJlbGlhYmxlIHBy b3Zpc2lvbmFsPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IHJlc3BvbnNlcyBjb3VsZCByZWZyZXNoIHRo ZSByZW1vdGUgdGFyZ2V0LiBUaGVyZSBhcmUgc2V2ZXJhbA0KcHJvYmxlbXM8YnI+DQomZ3Q7ICZu YnNwOyZndDsgd2l0aCB1bnJlbGlhYmxlIHJlc3BvbnNlcyB1cGRhdGluZyByZW1vdGUgdGFyZ2V0 cy4gRmlyc3QsDQp3ZSB3b3VsZCBuZWVkPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IHRvIGRlZmluZSBl dmVuIG1vcmUgcnVsZXMgdG8gYXZvaWQgZ2xhcmUgc2l0dWF0aW9ucyBhbmQNCnJhY2UgY29uZGl0 aW9ucy48YnI+DQomZ3Q7ICZuYnNwOyZndDsgU2Vjb25kLCBTSVAgZG9lcyBub3QgcHJvdmlkZSBh bnkgb3JkZXJpbmcgZm9yIHVucmVsaWFibGUNCnByb3Zpc2lvbmFsPGJyPg0KJmd0OyAmbmJzcDsm Z3Q7IHJlc3BvbnNlcy4gUmVzcG9uc2VzIGFycml2aW5nIG91dCBvZiBvcmRlciBhdCB0aGUgVUFD IGNvdWxkDQplYXNpbHkgZ2V0PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IGJvdGggVUFzIG91dCBvZiBz eW5jaC4gVGhlcmVmb3JlLCBvbmx5IHJlbGlhYmxlIHJlc3BvbnNlcw0KY2FuIHJlZnJlc2g8YnI+ DQomZ3Q7ICZuYnNwOyZndDsgcmVtb3RlIHRhcmdldHMsIGFzIHdhcyBzcGVjaWZpZWQgaW4gUkZD IDMyNjEgYW55d2F5Ljxicj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyBX ZSBhbHNvIGRpc2N1c3NlZCB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUgdGFyZ2V0IHJlZnJlc2gN CnJ1bGVzIHRvPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IGluaXRpYWwgSU5WSVRFcy4gVGhlIHJ1bGVz IGluIHRoZSBkcmFmdCBjb3ZlciB0aGVtIGFzIHdlbGwNCnNvIEkgZG8gbm90PGJyPg0KJmd0OyAm bmJzcDsmZ3Q7IHRoaW5rIHdlIG5lZWQgdG8gYWRkIGFueXRoaW5nIGVsc2UgdG8gdGhhdCBlbmQu PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IFRoYW5rcyw8YnI+DQom Z3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsgR29uemFsbzxicj4NCiZndDsgJm5i c3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJm5ic3A7Jmd0OyBzaXBjb3JlIG1haWxpbmcg bGlzdDxicj4NCiZndDsgJm5ic3A7Jmd0OyBzaXBjb3JlQGlldGYub3JnPGJyPg0KJmd0OyAmbmJz cDsmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxicj4N CiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0 Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJm5ic3A7Jmd0OyBaVEUgSW5mb3JtYXRp b24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkDQppbiB0aGlzIDxi cj4NCiZndDsgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXph dGlvbi4gVGhpcyBtYWlsIDxicj4NCiZndDsgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwu IFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZA0KdG8gPGJyPg0KJmd0OyBtYWlu dGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVu dHMgb2YNCnRoaXMgPGJyPg0KJmd0OyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy48YnI+DQomZ3Q7 ICZuYnNwOyZndDsgVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQg YXJlIGNvbmZpZGVudGlhbA0KYW5kIDxicj4NCiZndDsgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg dXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkNCmFyZSA8YnI+DQom Z3Q7IGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBw bGVhc2Ugbm90aWZ5DQp0aGUgPGJyPg0KJmd0OyBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBB bnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUNCnRob3NlIDxicj4NCiZndDsg b2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLjxicj4NCiZndDsgJm5ic3A7Jmd0OyBUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUNCkFudGktU3Bh bSA8YnI+DQomZ3Q7IHN5c3RlbS48YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IFpURSBJbmZv cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cw0KbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4g VGhpcyBtYWlsIGNvbW11bmljYXRpb24NCmlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1l ZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kNCmFuZCBhcmUgbm90IHBl cm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRv DQpvdGhlcnMuPGJyPg0KJmd0OyBUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZA0KaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlDQphZGRyZXNzZWQu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvcg0Kb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjxicj4NCiZndDsg VGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRF IEFudGktU3BhbQ0Kc3lzdGVtLjxicj4NCiZndDsgPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlz dDxicj4NCnNpcGNvcmVAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NpcGNvcmU8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpU RSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5i c3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWls Jm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21t dW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNw O25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21h aW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1p dHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29m Jm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMm bmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQm bmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJz cDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJz cDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lv dSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5i c3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9y Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7 ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Ro b3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZu YnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNw O3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNw YW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 00425A22482576AF_=-- From gonzalo.camarillo@ericsson.com Mon Jan 18 05:38:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98CBF3A659C for ; Mon, 18 Jan 2010 05:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.034 X-Spam-Level: X-Spam-Status: No, score=-106.034 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAcggSF364GS for ; Mon, 18 Jan 2010 05:38:19 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9D6213A659B for ; Mon, 18 Jan 2010 05:38:19 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-3d-4b546446a80b Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id A2.02.04178.644645B4; Mon, 18 Jan 2010 14:38:14 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 14:38:14 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 14:38:14 +0100 Message-ID: <4B546445.80909@ericsson.com> Date: Mon, 18 Jan 2010 15:38:13 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2010 13:38:14.0288 (UTC) FILETIME=[7BED9900:01CA9843] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 13:38:21 -0000 Hi, we need to make sure we get the expansion of Table 2 and the IANA stuff right. We need someone to look at Section 6.1 in detail and confirm that everything is correct. Also, we need someone to do the same with Section 11. Thanks, Gonzalo Christer Holmberg wrote: > > Hi, > > Based on the WGLC comments, a new version (-05) of the info-event draft > has been submitted. > > It can also be found at: > > _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-05.txt_ > > Since there has been some e-mail editing etc, please take a look and > make sure that your comments/issues have been addressed. > > Regards, > > Christer > > From gonzalo.camarillo@ericsson.com Mon Jan 18 05:40:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61CFF3A67A5 for ; Mon, 18 Jan 2010 05:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.041 X-Spam-Level: X-Spam-Status: No, score=-106.041 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Z83z9M9Xhjy for ; Mon, 18 Jan 2010 05:40:53 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 6ACD33A676A for ; Mon, 18 Jan 2010 05:40:53 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-d9-4b5464e0309b Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 38.92.04178.0E4645B4; Mon, 18 Jan 2010 14:40:48 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 14:40:48 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 14:40:47 +0100 Message-ID: <4B5464DB.9080902@ericsson.com> Date: Mon, 18 Jan 2010 15:40:43 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4B546445.80909@ericsson.com> In-Reply-To: <4B546445.80909@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2010 13:40:48.0045 (UTC) FILETIME=[D7930DD0:01CA9843] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 13:40:58 -0000 Hi, [sorry for splitting this note into two messages, the previous one and this one] another point that has been much discussed in the past has been the ABNF syntax. If someone could do a similar review of Section 8.2, that would be appreciated. Thanks, Gonzalo Gonzalo Camarillo wrote: > Hi, > > we need to make sure we get the expansion of Table 2 and the IANA stuff > right. We need someone to look at Section 6.1 in detail and confirm that > everything is correct. Also, we need someone to do the same with Section > 11. > > Thanks, > > Gonzalo > > > Christer Holmberg wrote: >> >> Hi, >> >> Based on the WGLC comments, a new version (-05) of the info-event >> draft has been submitted. >> >> It can also be found at: >> >> _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-05.txt_ >> >> >> Since there has been some e-mail editing etc, please take a look and >> make sure that your comments/issues have been addressed. >> >> Regards, >> >> Christer >> >> > > From gonzalo.camarillo@ericsson.com Tue Jan 19 06:03:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5CD73A6949 for ; Tue, 19 Jan 2010 06:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.061 X-Spam-Level: X-Spam-Status: No, score=-106.061 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiOTPDgE21WU for ; Tue, 19 Jan 2010 06:03:26 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id BA7B03A6924 for ; Tue, 19 Jan 2010 06:03:25 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-91-4b55bba83127 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 91.75.04178.8ABB55B4; Tue, 19 Jan 2010 15:03:20 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 15:03:20 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 15:03:20 +0100 Message-ID: <4B55BBA8.8060905@ericsson.com> Date: Tue, 19 Jan 2010 16:03:20 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jan 2010 14:03:20.0308 (UTC) FILETIME=[27FFC340:01CA9910] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Submission of draft-ietf-sipcore-reinvite-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 14:03:26 -0000 Hi, I have just submitted the following draft: http://www.ietf.org/id/draft-ietf-sipcore-reinvite-01.txt This version addresses all the comments received until now. Cheers, Gonzalo From root@core3.amsl.com Tue Jan 19 06:15:02 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E1A2028C0E2; Tue, 19 Jan 2010 06:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100119141501.E1A2028C0E2@core3.amsl.com> Date: Tue, 19 Jan 2010 06:15:01 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 14:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, et al. Filename : draft-ietf-sipcore-reinvite-01.txt Pages : 24 Date : 2010-01-19 In this document, we clarify the handling of re-INVITEs in SIP. We clarify in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, we clarify issues related to target-refresh requests. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 23, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-reinvite-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-19060205.I-D@ietf.org> --NextPart-- From pkyzivat@cisco.com Tue Jan 19 06:23:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C01D23A6924 for ; Tue, 19 Jan 2010 06:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.425 X-Spam-Level: X-Spam-Status: No, score=-10.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+gwt4l8lNoA for ; Tue, 19 Jan 2010 06:23:23 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1DB7F3A67F0 for ; Tue, 19 Jan 2010 06:23:23 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFlPVUtAZnwN/2dsb2JhbADCVZUThDME X-IronPort-AV: E=Sophos;i="4.49,303,1262563200"; d="scan'208";a="80969646" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Jan 2010 14:23:19 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.172]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0JENIUP025448; Tue, 19 Jan 2010 14:23:18 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 08:23:18 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 08:23:18 -0600 Message-ID: <4B55C054.8000109@cisco.com> Date: Tue, 19 Jan 2010 09:23:16 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4B546445.80909@ericsson.com> <4B5464DB.9080902@ericsson.com> In-Reply-To: <4B5464DB.9080902@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jan 2010 14:23:18.0207 (UTC) FILETIME=[F200A4F0:01CA9912] Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 14:23:26 -0000 Gonzalo Camarillo wrote: > Hi, > > [sorry for splitting this note into two messages, the previous one and > this one] > > another point that has been much discussed in the past has been the ABNF > syntax. If someone could do a similar review of Section 8.2, that would > be appreciated. I commented already, and those comments were dealt with. I've just now looked again more carefully, and the ABNF looks ok to me. Paul > Thanks, > > Gonzalo > > Gonzalo Camarillo wrote: >> Hi, >> >> we need to make sure we get the expansion of Table 2 and the IANA >> stuff right. We need someone to look at Section 6.1 in detail and >> confirm that everything is correct. Also, we need someone to do the >> same with Section 11. >> >> Thanks, >> >> Gonzalo >> >> >> Christer Holmberg wrote: >>> >>> Hi, >>> >>> Based on the WGLC comments, a new version (-05) of the info-event >>> draft has been submitted. >>> >>> It can also be found at: >>> >>> _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-05.txt_ >>> >>> >>> Since there has been some e-mail editing etc, please take a look and >>> make sure that your comments/issues have been addressed. >>> >>> Regards, >>> >>> Christer >>> >>> >> >> > > From salvatore.loreto@ericsson.com Tue Jan 19 06:24:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A5A3A6A50 for ; Tue, 19 Jan 2010 06:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJcUn2pKYIZc for ; Tue, 19 Jan 2010 06:24:10 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 36F233A67F0 for ; Tue, 19 Jan 2010 06:24:10 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-cb-4b55c085cce1 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 8C.9A.04178.580C55B4; Tue, 19 Jan 2010 15:24:05 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 15:22:34 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 15:22:34 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 59E0324C8; Tue, 19 Jan 2010 16:22:34 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2475A21A39; Tue, 19 Jan 2010 16:22:34 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B510A219CE; Tue, 19 Jan 2010 16:22:33 +0200 (EET) Message-ID: <4B55C028.7060002@ericsson.com> Date: Tue, 19 Jan 2010 16:22:32 +0200 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Gonzalo Camarillo , Paul Kyzivat References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> <4B4FBA84.2040005@cisco.com> <4B50200B.9020806@ericsson.com> In-Reply-To: <4B50200B.9020806@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 19 Jan 2010 14:22:34.0526 (UTC) FILETIME=[D7F773E0:01CA9912] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 14:24:11 -0000 Hi Paul and Gonzalo, I completely agree with the fact that the OPTIONS method to discovery capabilities is pretty broken and then it is not useful to provide a meaningful service. In order to write down some requirements, lets consider the scenario where Alice wants to discover the Bob device capabilities - Capabilities here a first possible requirements could be: Req.: The returned capabilities to an OPTIONS request should reflect what Bob is able to communicate with Alice with respect to what are the capabilities of his fleet of devices, not just one device. at present when Alice sends a SIP OPTIONS request to discover the Bob capabilities, if Bob ha registered two or more UAs, then the OPTIONS request forks and arrive to all the registered UAs; however the proxy performing the forking forwards back to Alice only the first response it receives. Preferably the capability discovery mechanism should let Alice (or rather Alices device) know if Bob can take audio on one device, but video, video and text on his other visual friendly device. If a capability discovery mechanism is able to provide that level of granularity, it helps Alice's device understand that while on a voice session with Bob, it is no way a re-INVITE to video would work, but instead her device should send a new video-session INVITE towards Bob allowing hi to press the 'yes' button on the visual device. Thus, there would be two parallel sessions between Alice and Bob, one for voice and the second one for video/text/picture. A capability discovery mechanism like this would also provide the context for capabilities, where as Paul points out in his mail at moment with the currents OPTIONS request capabilities are context free. - Time The capabilities should not be considered stable over time, however they can be regarded as stable (but without any guarantees) if an INVITE take places within short time. The latter is often the the intent of the querying party I would assume. Thus, Alice wants to communicate with Bob "now" but first wants to check "what" Bob can do. That is why she sends an OPTIONS. Soon as she knows the capabilities, she immediately invokes a compatible (to the capabilities received) communication manner. Cheers Sal Gonzalo Camarillo wrote: > Hi Paul, > > >> I agree, but the problem is bigger than this draft. >> >> The whole concept that OPTIONS will tell you the capabilities of the UA >> is pretty broken - it assumes those are stable over time and are context >> free, which is often not the case. There are almost never any guarantees >> that the info you receive from OPTIONS will still be true if you try to >> act on it. >> >> The concept that the response code from OPTIONS should be the same as >> you would get were you to send an INVITE is even more broken. It doesn't >> work at all well for UAs that don't support INVITE. >> >> The definition of OPTIONS needs some serious rework. >> > > yes, this has come up several times in the past. When people try to use > OPTIONS to provide a meaningful service, they fairly soon notice how > broken it is. At some point, it could be interesting to gather a few > requirements and try to fix it somehow. > > Cheers, > > Gonzalo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From pkyzivat@cisco.com Tue Jan 19 08:31:07 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B007B3A6A86 for ; Tue, 19 Jan 2010 08:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.352 X-Spam-Level: X-Spam-Status: No, score=-10.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDnNxUzKCDU1 for ; Tue, 19 Jan 2010 08:31:06 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5D02B3A687B for ; Tue, 19 Jan 2010 08:31:06 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB1tVUutJV2Y/2dsb2JhbADCYJURhDME X-IronPort-AV: E=Sophos;i="4.49,304,1262563200"; d="scan'208";a="233812634" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 19 Jan 2010 16:31:02 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.172]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o0JGV23h004062; Tue, 19 Jan 2010 16:31:02 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 10:31:02 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 10:31:01 -0600 Message-ID: <4B55DE45.3040307@cisco.com> Date: Tue, 19 Jan 2010 11:31:01 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Salvatore Loreto References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> <4B4FBA84.2040005@cisco.com> <4B50200B.9020806@ericsson.com> <4B55C028.7060002@ericsson.com> In-Reply-To: <4B55C028.7060002@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jan 2010 16:31:01.0974 (UTC) FILETIME=[C9F6AF60:01CA9924] Cc: SIPCORE Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 16:31:08 -0000 Salvatore Loreto wrote: > Hi Paul and Gonzalo, > > I completely agree with the fact that the OPTIONS method to discovery > capabilities is pretty broken and then > it is not useful to provide a meaningful service. > > In order to write down some requirements, lets consider the scenario > where Alice wants to discover the Bob device capabilities > > > - Capabilities > here a first possible requirements could be: > > Req.: The returned capabilities to an OPTIONS request should reflect > what Bob is able to communicate with Alice with respect > to what are the capabilities of his fleet of devices, not just > one device. That may be in conflict with the original intent and design of OPTIONS. Note that one of the things you are explicitly permitted to do is restrict the hop count so that OPTIONS stops before reaching its final address. In that case, whatever has it when it runs out of hops is supposed to answer. That says to me that whoever does respond to OPTIONS should be responding for itself. In the case where the request is addressed to an AOR, and there is a proxy responsible for that AOR, that will typically route requests via contact routing, its not entirely clear what it means to answer for itself. > at present when Alice sends a SIP OPTIONS request to discover the Bob > capabilities, > if Bob ha registered two or more UAs, then the OPTIONS request forks and > arrive to all the registered UAs; > however the proxy performing the forking forwards back to Alice only the > first response it receives. That *may* be what happens. > Preferably the capability discovery mechanism should let Alice (or > rather Alices device) know if Bob can take audio on one device, > but video, video and text on his other visual friendly device. That would be a nice thing to be able to learn. Whether OPTIONS is the way to achieve that is an entirely different question. What would you do? Have the proxy send *new* OPTIONS to each registered device and then consolidate the results? Would that entail a multipart/alternative containing SDP from each contact? > If a capability discovery mechanism is able to provide that level of > granularity, it helps Alice's device understand that while on a > voice session with Bob, it is no way a re-INVITE to video would work, > but instead her device should send a new video-session INVITE > towards Bob allowing hi to press the 'yes' button on the visual device. I think Alice needs more information before concluding that. It may be that those two devices reside in Bob's multiple offices, one in Boston and the other in San Jose. Also, Alice then needs a way of directing the new INVITE to the intended destination. (Perhaps callerprefs would meet this need, perhaps not.) > Thus, there would be two parallel sessions between Alice and Bob, > one for voice and the second one for video/text/picture. > A capability discovery mechanism like this would also provide the > context for capabilities, where as Paul points out in his mail at moment > with the currents OPTIONS request capabilities are context free. If people think this is worth doing, we could no doubt come up with a way of doing it. But it seems unlikely that OPTIONS would be the whole answer. (Realistically it probably makes more sense to leave OPTIONS alone and create something new.) > - Time > The capabilities should not be considered stable over time, however they > can be regarded as stable (but without any guarantees) if an INVITE take > places within short time. > The latter is often the the intent of the querying party I would assume. > Thus, Alice wants to communicate with Bob "now" but first wants to check > "what" Bob can do. That is why she sends an OPTIONS. Soon as she knows > the capabilities, she immediately invokes a compatible (to the > capabilities received) > communication manner. That may be a reasonable goal. But it probably requires some more examination into the reasons that capabilities might change over time. For instance, if Bob's device is handling a call when it receives the query, does the response reflect what it can do concurrently with that call, or what it will be able to do once that call has ended? (Both may be useful pieces of information.) Thanks, Paul > Cheers > Sal > > > Gonzalo Camarillo wrote: >> Hi Paul, >> >> >>> I agree, but the problem is bigger than this draft. >>> >>> The whole concept that OPTIONS will tell you the capabilities of the >>> UA is pretty broken - it assumes those are stable over time and are >>> context free, which is often not the case. There are almost never any >>> guarantees that the info you receive from OPTIONS will still be true >>> if you try to act on it. >>> >>> The concept that the response code from OPTIONS should be the same as >>> you would get were you to send an INVITE is even more broken. It >>> doesn't work at all well for UAs that don't support INVITE. >>> >>> The definition of OPTIONS needs some serious rework. >>> >> >> yes, this has come up several times in the past. When people try to >> use OPTIONS to provide a meaningful service, they fairly soon notice >> how broken it is. At some point, it could be interesting to gather a >> few requirements and try to fix it somehow. >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > > From brian@estacado.net Tue Jan 19 11:18:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27EC3A6407 for ; Tue, 19 Jan 2010 11:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYx+p5a9VJsQ for ; Tue, 19 Jan 2010 11:18:11 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 689AE3A67F7 for ; Tue, 19 Jan 2010 11:18:05 -0800 (PST) Received: from [192.168.1.106] (cpe-76-182-241-151.tx.res.rr.com [76.182.241.151]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o0JJGVeS052571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Jan 2010 13:16:35 -0600 (CST) (envelope-from brian@estacado.net) Message-Id: <126F4C63-8C3D-4131-8FA4-B8EBC0B7C804@estacado.net> From: Brian Hibbard To: Cullen Jennings In-Reply-To: <85C804CE-610E-42E9-86FD-F8FED9620E29@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 19 Jan 2010 13:16:30 -0600 References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <85C804CE-610E-42E9-86FD-F8FED9620E29@cisco.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 19:18:12 -0000 On Dec 10, 2009, at 12:44 AM, Cullen Jennings wrote: > > On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote: > >> We should probably say something about CRLs. We need to get >> consensus on whether we want to recommend a method for retrieving >> CRLs. > > I predict we will never get consensus on which way one should check > CRLs thus I favor avoiding the CRL discussion but if others feel > differently I don't care one way or the other. We should probably say something, because we mention revocation in Section "Additional Test Scenarios". I think it could be helpful to point out that there is such a thing as revocation status and that for PKI to work in the real world, certificate revocation status needs to be checked. How this is done has little impact on interoperability or implementation. As for how to check revocation status, you're almost certainly right about whether we can get agreement. We could refer them to section 3.3 of RFC 5280 and leave it at that. Unless someone feels strongly one way or another, I'll go ahead and add a blurb in section "Security Considerations" effecting the above, and close that issue. From rjsparks@nostrum.com Tue Jan 19 13:36:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 386393A67E2 for ; Tue, 19 Jan 2010 13:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbvDP-eBNuzv for ; Tue, 19 Jan 2010 13:35:59 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id F00CD3A67DB for ; Tue, 19 Jan 2010 13:35:58 -0800 (PST) Received: from [192.168.2.2] (pool-173-71-49-137.dllstx.fios.verizon.net [173.71.49.137]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0JLZXwv066129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Jan 2010 15:35:33 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> From: Robert Sparks To: Christer Holmberg In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-63-14407838 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 19 Jan 2010 15:35:32 -0600 References: X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 173.71.49.137 is authenticated by a trusted mechanism) Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 21:36:00 -0000 --Apple-Mail-63-14407838 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I would also have removed " The reviewer does not consider the applicability of the Info Package The reviewer does not consider the applicability of the Info Package for the usage for which it is defined." RjS On Jan 18, 2010, at 12:56 AM, Christer Holmberg wrote: > > Hi, > > Based on the WGLC comments, a new version (-05) of the info-event > draft has been submitted. > > It can also be found at: > > http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-05.txt > > Since there has been some e-mail editing etc, please take a look and > make sure that your comments/issues have been addressed. > > Regards, > > Christer > > --Apple-Mail-63-14407838 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I would also have removed
" = The reviewer does not consider the applicability of the Info Package = The reviewer does not consider the applicability of the Info Package for the usage for which it is = defined."

RjS

On Jan = 18, 2010, at 12:56 AM, Christer Holmberg wrote:

 
Hi,
 
Based on the WGLC = comments, a new version (-05) of the info-event draft has been = submitted.
 
It can also be found at:
 
 
Since there has been = some e-mail editing etc, please take a look and make sure that your = comments/issues have been addressed.
 
Regards,
 
Christer
 
 

= --Apple-Mail-63-14407838-- From dean.willis@softarmor.com Tue Jan 19 22:00:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA24D3A67F5 for ; Tue, 19 Jan 2010 22:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbxSIr6ZKPP9 for ; Tue, 19 Jan 2010 22:00:15 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 94E163A635F for ; Tue, 19 Jan 2010 22:00:14 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0K604Uj006348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Jan 2010 00:00:06 -0600 Message-Id: From: Dean Willis To: Robert Sparks In-Reply-To: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 19 Jan 2010 23:59:59 -0600 References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 06:00:18 -0000 On Jan 19, 2010, at 3:35 PM, Robert Sparks wrote: > I would also have removed > " The reviewer does not consider the applicability of the Info > Package The reviewer does not consider the applicability of the Info > Package for the usage for which it is defined." While the language is broken, the intent is that the reviewer not say "This is a silly thing to do with an INFO package. Why, we should be doing this with SOAP (or insert your favorite modality) instead." As a group, we tend to review SIP extensions through something of a religious lens, to say "But that usage isn't the intent of SIP; SIP is only for (insert favorite thing here)!" The goals of an INFO package reviewer should be to be to 1) verify that the document exists and actually specifies an INFO package, not something completely different (like say, a recipe for cheese dip), 2) verify that the INFO package name is unique, and 3) confirm that the INFO package is not trying to sneak modifications of the SIP State machine into the specification family; there MUST be no normative language that alters the SIP state machine functionality. If somebody wants "INFO for lightbulbs", that's OK. If they want "INFO for remote procedure calls", that's OK too. Neither may be a particularly smart usage of SIP, but they don't break the SIP protocol, and that's all the reviewer should care about. -- Dean From christer.holmberg@ericsson.com Tue Jan 19 22:38:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671333A6359 for ; Tue, 19 Jan 2010 22:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-ImufY1yRbd for ; Tue, 19 Jan 2010 22:38:50 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 5DC7A3A695C for ; Tue, 19 Jan 2010 22:38:49 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-8f-4b56a4f35aca Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 13.8D.04178.3F4A65B4; Wed, 20 Jan 2010 07:38:43 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 20 Jan 2010 07:38:43 +0100 From: Christer Holmberg To: Dean Willis , Robert Sparks Date: Wed, 20 Jan 2010 07:38:42 +0100 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 Thread-Index: AcqZldPEvqQbcJgMQ7iwnFCwkdNHKAABVLPQ Message-ID: References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 06:38:52 -0000 Hi Dean, So, you want to keep the text? Regards, Christer=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 20. tammikuuta 2010 8:00 > To: Robert Sparks > Cc: Christer Holmberg; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > Subject: Re: [sipcore] Draft new version:=20 > draft-ietf-sipcore-info-events-05 >=20 >=20 > On Jan 19, 2010, at 3:35 PM, Robert Sparks wrote: >=20 > > I would also have removed > > " The reviewer does not consider the applicability of the=20 > Info Package=20 > > The reviewer does not consider the applicability of the=20 > Info Package=20 > > for the usage for which it is defined." >=20 > While the language is broken, the intent is that the reviewer=20 > not say "This is a silly thing to do with an INFO package.=20 > Why, we should be doing this with SOAP (or insert your=20 > favorite modality) instead." As a group, we tend to review=20 > SIP extensions through something of a religious lens, to say=20 > "But that usage isn't the intent of SIP; SIP is only for=20 > (insert favorite thing here)!" >=20 > The goals of an INFO package reviewer should be to be to 1)=20 > verify that the document exists and actually specifies an=20 > INFO package, not something completely different (like say, a=20 > recipe for cheese dip), 2) verify that the INFO package name=20 > is unique, and 3) confirm that the INFO package is not trying=20 > to sneak modifications of the SIP State machine into the=20 > specification family; there MUST be no normative language=20 > that alters the SIP state machine functionality. >=20 >=20 > If somebody wants "INFO for lightbulbs", that's OK. If they=20 > want "INFO for remote procedure calls", that's OK too.=20 > Neither may be a particularly smart usage of SIP, but they=20 > don't break the SIP protocol, and that's all the reviewer=20 > should care about. >=20 > -- > Dean > = From christer.holmberg@ericsson.com Tue Jan 19 22:39:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF5E63A6359 for ; Tue, 19 Jan 2010 22:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxYB-u4mZSTL for ; Tue, 19 Jan 2010 22:39:50 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id B69253A695C for ; Tue, 19 Jan 2010 22:39:49 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-61-4b56a5302225 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id B3.AD.04178.035A65B4; Wed, 20 Jan 2010 07:39:44 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 20 Jan 2010 07:39:44 +0100 From: Christer Holmberg To: Christer Holmberg , Dean Willis , Robert Sparks Date: Wed, 20 Jan 2010 07:39:43 +0100 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 Thread-Index: AcqZldPEvqQbcJgMQ7iwnFCwkdNHKAABVLPQAAAJahA= Message-ID: References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 06:39:52 -0000 Hi, A possible comprimise would be to keep the text, but make it into a note. Regards, Christer=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 20. tammikuuta 2010 8:39 > To: Dean Willis; Robert Sparks > Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > Subject: Re: [sipcore] Draft new version:=20 > draft-ietf-sipcore-info-events-05 >=20 >=20 > Hi Dean, >=20 > So, you want to keep the text? >=20 > Regards, >=20 > Christer=20 >=20 > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: 20. tammikuuta 2010 8:00 > > To: Robert Sparks > > Cc: Christer Holmberg; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > > Subject: Re: [sipcore] Draft new version:=20 > > draft-ietf-sipcore-info-events-05 > >=20 > >=20 > > On Jan 19, 2010, at 3:35 PM, Robert Sparks wrote: > >=20 > > > I would also have removed > > > " The reviewer does not consider the applicability of the > > Info Package > > > The reviewer does not consider the applicability of the > > Info Package > > > for the usage for which it is defined." > >=20 > > While the language is broken, the intent is that the=20 > reviewer not say=20 > > "This is a silly thing to do with an INFO package. > > Why, we should be doing this with SOAP (or insert your favorite=20 > > modality) instead." As a group, we tend to review SIP extensions=20 > > through something of a religious lens, to say "But that usage isn't=20 > > the intent of SIP; SIP is only for (insert favorite thing here)!" > >=20 > > The goals of an INFO package reviewer should be to be to 1) verify=20 > > that the document exists and actually specifies an INFO=20 > package, not=20 > > something completely different (like say, a recipe for=20 > cheese dip), 2)=20 > > verify that the INFO package name is unique, and 3) confirm=20 > that the=20 > > INFO package is not trying to sneak modifications of the SIP State=20 > > machine into the specification family; there MUST be no normative=20 > > language that alters the SIP state machine functionality. > >=20 > >=20 > > If somebody wants "INFO for lightbulbs", that's OK. If they=20 > > want "INFO for remote procedure calls", that's OK too.=20 > > Neither may be a particularly smart usage of SIP, but they=20 > > don't break the SIP protocol, and that's all the reviewer=20 > > should care about. > >=20 > > -- > > Dean > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Tue Jan 19 14:22:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FA503A6A6E for ; Tue, 19 Jan 2010 14:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Av7bpx6cqhVy for ; Tue, 19 Jan 2010 14:22:46 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 78E923A696B for ; Tue, 19 Jan 2010 14:22:46 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-42-4b5630b008dd Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 8F.03.04178.0B0365B4; Tue, 19 Jan 2010 23:22:41 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 19 Jan 2010 23:22:40 +0100 From: Christer Holmberg To: Robert Sparks Date: Tue, 19 Jan 2010 23:21:43 +0100 Thread-Topic: Draft new version: draft-ietf-sipcore-info-events-05 Thread-Index: AcqZT2D94tdz7YnWTSWexgdr+XbJGAABmcG+ Message-ID: References: , <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> In-Reply-To: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Tue, 19 Jan 2010 22:42:50 -0800 Cc: Gonzalo, SIPCORE , Camarillo , Hadriel Kaplan , Paul Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 22:22:47 -0000 Hi, >I would also have removed >" The reviewer does not consider the applicability of the Info Package The= reviewer does not consider the >applicability of the Info Package for the = usage for which it is defined." That's a misstake. The intention was to remove it. I'll fix it. Thanks! Christer From rjsparks@nostrum.com Tue Jan 19 22:56:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88283A6A22 for ; Tue, 19 Jan 2010 22:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-u740w+Nm8T for ; Tue, 19 Jan 2010 22:56:39 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 87A863A6A1C for ; Tue, 19 Jan 2010 22:56:38 -0800 (PST) Received: from [192.168.2.2] (pool-173-71-49-137.dllstx.fios.verizon.net [173.71.49.137]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0K6uTt6069234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Jan 2010 00:56:30 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <0309D74A-996B-49C1-B6CE-620459683C75@nostrum.com> From: Robert Sparks To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 20 Jan 2010 00:56:29 -0600 References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 173.71.49.137 is authenticated by a trusted mechanism) Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 06:56:40 -0000 I don't think we need to keep the text - that's already what Specification Required says. RjS On Jan 20, 2010, at 12:39 AM, Christer Holmberg wrote: > > Hi, > > A possible comprimise would be to keep the text, but make it into a > note. > > Regards, > > Christer > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 20. tammikuuta 2010 8:39 >> To: Dean Willis; Robert Sparks >> Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan >> Subject: Re: [sipcore] Draft new version: >> draft-ietf-sipcore-info-events-05 >> >> >> Hi Dean, >> >> So, you want to keep the text? >> >> Regards, >> >> Christer >> >>> -----Original Message----- >>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>> Sent: 20. tammikuuta 2010 8:00 >>> To: Robert Sparks >>> Cc: Christer Holmberg; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan >>> Subject: Re: [sipcore] Draft new version: >>> draft-ietf-sipcore-info-events-05 >>> >>> >>> On Jan 19, 2010, at 3:35 PM, Robert Sparks wrote: >>> >>>> I would also have removed >>>> " The reviewer does not consider the applicability of the >>> Info Package >>>> The reviewer does not consider the applicability of the >>> Info Package >>>> for the usage for which it is defined." >>> >>> While the language is broken, the intent is that the >> reviewer not say >>> "This is a silly thing to do with an INFO package. >>> Why, we should be doing this with SOAP (or insert your favorite >>> modality) instead." As a group, we tend to review SIP extensions >>> through something of a religious lens, to say "But that usage isn't >>> the intent of SIP; SIP is only for (insert favorite thing here)!" >>> >>> The goals of an INFO package reviewer should be to be to 1) verify >>> that the document exists and actually specifies an INFO >> package, not >>> something completely different (like say, a recipe for >> cheese dip), 2) >>> verify that the INFO package name is unique, and 3) confirm >> that the >>> INFO package is not trying to sneak modifications of the SIP State >>> machine into the specification family; there MUST be no normative >>> language that alters the SIP state machine functionality. >>> >>> >>> If somebody wants "INFO for lightbulbs", that's OK. If they >>> want "INFO for remote procedure calls", that's OK too. >>> Neither may be a particularly smart usage of SIP, but they >>> don't break the SIP protocol, and that's all the reviewer >>> should care about. >>> >>> -- >>> Dean >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From courettabt@gmail.com Wed Jan 20 05:46:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9813A691D for ; Wed, 20 Jan 2010 05:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaybWyZajLEm for ; Wed, 20 Jan 2010 05:46:45 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 8BB883A6905 for ; Wed, 20 Jan 2010 05:46:45 -0800 (PST) Received: by fxm7 with SMTP id 7so731683fxm.28 for ; Wed, 20 Jan 2010 05:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=6LLtInaPOp/LQlttHj2MtELdjPBMHAij/T+cVMLXoK8=; b=Ry9NQZGZc8e/zjlj80+l6wRbJleQSn4wrZBegjMRZjUuOq6nNkNC09v77nCgT6lRJD rzRmCDiqO32/R59fscbcu3iULr3Trp6WoNHvzQGy+ykHw3ubH4yQtV3eSmgJOTiqZ3Ec kJ7pxUVCob/L7OSE9RCJY/Oj3eN3iyrkbndVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=kxtWjj+GI7E6AWZqzjhJftguIxFIwxhOESkSeAbNf0kiAwr77vkHxKCrGaQ4EFmVIq pd24QjgdoVs0JbyD9tkxWWrfH5CECy43j7s7W8xscUOn4+1FVg7+adCFzY03lCGS/VKQ k764bT4sTp8X9FiXw6Zz60v2muOWfjYUhCwuo= MIME-Version: 1.0 Received: by 10.239.186.20 with SMTP id e20mr334886hbh.137.1263995197467; Wed, 20 Jan 2010 05:46:37 -0800 (PST) Date: Wed, 20 Jan 2010 22:46:37 +0900 Message-ID: <13bdfb281001200546k4a6ff717t33020e1d7efd5182@mail.gmail.com> From: Couret Tabt To: sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sipcore] SIP Authentication Mechanism in Intra-Domain X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 13:46:46 -0000 Dear folks, I have a question below: Do you know SIP Authentication Mechanism in Intra-Domain except for using REGISTER. REGISTER is used in user registration at first time, but this mean more frequent receiver authentication as using at every INVITE. It is used to prevent spoofing of a receiver. Do you know Intra-Domain (especially Receiver-side domain) Authentication Mechanism in SIP? If you know it, please let me know and is it appropriate that I post this type of topic to this mailing list? Thanks, Tabt From christer.holmberg@ericsson.com Wed Jan 20 09:52:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314863A6821 for ; Wed, 20 Jan 2010 09:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaK+cWEsP8Aw for ; Wed, 20 Jan 2010 09:52:44 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 03A223A6403 for ; Wed, 20 Jan 2010 09:52:43 -0800 (PST) X-AuditID: c1b4fb24-b7c57ae000002bb1-dc-4b5742e6bda5 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 77.BF.11185.6E2475B4; Wed, 20 Jan 2010 18:52:38 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 20 Jan 2010 18:52:38 +0100 From: Christer Holmberg To: Robert Sparks Date: Wed, 20 Jan 2010 18:50:27 +0100 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 Thread-Index: AcqZnbPLwqH7F55BRmGHj92KtG339AAW1lga Message-ID: References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> , <0309D74A-996B-49C1-B6CE-620459683C75@nostrum.com> In-Reply-To: <0309D74A-996B-49C1-B6CE-620459683C75@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 17:52:45 -0000 Hi, Earlier we had a rather lenghty discussion about this, I believe all text w= as presented on the list before added to the draft, and nobody objected... Anyway, does anyone object if I now remove the text? Regards, Christer ________________________________________ From: Robert Sparks [rjsparks@nostrum.com] Sent: Wednesday, January 20, 2010 8:56 AM To: Christer Holmberg Cc: Dean Willis; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 I don't think we need to keep the text - that's already what Specification Required says. RjS On Jan 20, 2010, at 12:39 AM, Christer Holmberg wrote: > > Hi, > > A possible comprimise would be to keep the text, but make it into a > note. > > Regards, > > Christer > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 20. tammikuuta 2010 8:39 >> To: Dean Willis; Robert Sparks >> Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan >> Subject: Re: [sipcore] Draft new version: >> draft-ietf-sipcore-info-events-05 >> >> >> Hi Dean, >> >> So, you want to keep the text? >> >> Regards, >> >> Christer >> >>> -----Original Message----- >>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>> Sent: 20. tammikuuta 2010 8:00 >>> To: Robert Sparks >>> Cc: Christer Holmberg; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan >>> Subject: Re: [sipcore] Draft new version: >>> draft-ietf-sipcore-info-events-05 >>> >>> >>> On Jan 19, 2010, at 3:35 PM, Robert Sparks wrote: >>> >>>> I would also have removed >>>> " The reviewer does not consider the applicability of the >>> Info Package >>>> The reviewer does not consider the applicability of the >>> Info Package >>>> for the usage for which it is defined." >>> >>> While the language is broken, the intent is that the >> reviewer not say >>> "This is a silly thing to do with an INFO package. >>> Why, we should be doing this with SOAP (or insert your favorite >>> modality) instead." As a group, we tend to review SIP extensions >>> through something of a religious lens, to say "But that usage isn't >>> the intent of SIP; SIP is only for (insert favorite thing here)!" >>> >>> The goals of an INFO package reviewer should be to be to 1) verify >>> that the document exists and actually specifies an INFO >> package, not >>> something completely different (like say, a recipe for >> cheese dip), 2) >>> verify that the INFO package name is unique, and 3) confirm >> that the >>> INFO package is not trying to sneak modifications of the SIP State >>> machine into the specification family; there MUST be no normative >>> language that alters the SIP state machine functionality. >>> >>> >>> If somebody wants "INFO for lightbulbs", that's OK. If they >>> want "INFO for remote procedure calls", that's OK too. >>> Neither may be a particularly smart usage of SIP, but they >>> don't break the SIP protocol, and that's all the reviewer >>> should care about. >>> >>> -- >>> Dean >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>= From drage@alcatel-lucent.com Wed Jan 20 17:07:34 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E1DF28C111 for ; Wed, 20 Jan 2010 17:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCSjJy39q11E for ; Wed, 20 Jan 2010 17:07:33 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id E921D3A685A for ; Wed, 20 Jan 2010 17:07:32 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o0L17KQ6001393 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Jan 2010 02:07:20 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 21 Jan 2010 02:07:20 +0100 From: "DRAGE, Keith (Keith)" To: Dean Willis , Robert Sparks Date: Thu, 21 Jan 2010 02:07:19 +0100 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 Thread-Index: AcqZldmmGrExzdEiRnWhompboQyR5AAoB+lw Message-ID: References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 01:07:34 -0000 +1 to Dean's comments. I would also add that this issue got extensive discussion on the list when = these words were inserted. regards Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis > Sent: Wednesday, January 20, 2010 6:00 AM > To: Robert Sparks > Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > Subject: Re: [sipcore] Draft new version:=20 > draft-ietf-sipcore-info-events-05 >=20 >=20 > On Jan 19, 2010, at 3:35 PM, Robert Sparks wrote: >=20 > > I would also have removed > > " The reviewer does not consider the applicability of the=20 > Info Package=20 > > The reviewer does not consider the applicability of the=20 > Info Package=20 > > for the usage for which it is defined." >=20 > While the language is broken, the intent is that the reviewer=20 > not say "This is a silly thing to do with an INFO package.=20 > Why, we should be doing this with SOAP (or insert your=20 > favorite modality) instead." As a group, we tend to review=20 > SIP extensions through something of a religious lens, to say=20 > "But that usage isn't the intent of SIP; SIP is only for=20 > (insert favorite thing here)!" >=20 > The goals of an INFO package reviewer should be to be to 1)=20 > verify that the document exists and actually specifies an=20 > INFO package, not something completely different (like say, a=20 > recipe for cheese dip), 2) verify that the INFO package name=20 > is unique, and 3) confirm that the INFO package is not trying=20 > to sneak modifications of the SIP State machine into the=20 > specification family; there MUST be no normative language=20 > that alters the SIP state machine functionality. >=20 >=20 > If somebody wants "INFO for lightbulbs", that's OK. If they=20 > want "INFO for remote procedure calls", that's OK too.=20 > Neither may be a particularly smart usage of SIP, but they=20 > don't break the SIP protocol, and that's all the reviewer=20 > should care about. >=20 > -- > Dean > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From dean.willis@softarmor.com Wed Jan 20 20:37:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE6983A68CB for ; Wed, 20 Jan 2010 20:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKCFdgKZXx4J for ; Wed, 20 Jan 2010 20:37:21 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1D9E53A6927 for ; Wed, 20 Jan 2010 20:37:21 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0L4b9Bb018712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Jan 2010 22:37:12 -0600 Message-Id: <07C4CC96-ACE3-4871-A1DB-F6C649025639@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 20 Jan 2010 22:37:04 -0600 References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 04:37:21 -0000 On Jan 20, 2010, at 12:38 AM, Christer Holmberg wrote: > > Hi Dean, > > So, you want to keep the text? Well, I suspect that the text could be better worded, perhaps even written in proper English. But I think I agree with the intent. -- dean From christer.holmberg@ericsson.com Wed Jan 20 22:48:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119333A696D for ; Wed, 20 Jan 2010 22:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.131 X-Spam-Level: X-Spam-Status: No, score=-6.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMt+Re7zdR7J for ; Wed, 20 Jan 2010 22:48:24 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 0BE283A6359 for ; Wed, 20 Jan 2010 22:48:23 -0800 (PST) X-AuditID: c1b4fb24-b7c57ae000002bb1-39-4b57f8b2a6a1 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 18.CA.11185.2B8F75B4; Thu, 21 Jan 2010 07:48:18 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 21 Jan 2010 07:48:17 +0100 From: Christer Holmberg To: Dean Willis Date: Thu, 21 Jan 2010 07:48:17 +0100 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 Thread-Index: AcqaU2kzUTNnpMMHSlKhJVQfjUimiAAEjdGQ Message-ID: References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> <07C4CC96-ACE3-4871-A1DB-F6C649025639@softarmor.com> In-Reply-To: <07C4CC96-ACE3-4871-A1DB-F6C649025639@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Hadriel Kaplan , SIPCORE , Gonzalo, Camarillo Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 06:48:25 -0000 Hi, >>So, you want to keep the text? >=20 >Well, I suspect that the text could be better worded, perhaps=20 >even written in proper English. But I think I agree with the intent. Feel free to propose some properly written text :) Regards, Christer From drage@alcatel-lucent.com Thu Jan 21 03:47:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1713A67E9 for ; Thu, 21 Jan 2010 03:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[AWL=1.048, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+DuyF-f4dvA for ; Thu, 21 Jan 2010 03:47:22 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id B2F3F3A6A34 for ; Thu, 21 Jan 2010 03:47:21 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o0LBlDDB003421 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Jan 2010 12:47:13 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 21 Jan 2010 12:47:13 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Robert Sparks Date: Thu, 21 Jan 2010 12:47:12 +0100 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 Thread-Index: AcqZnbPLwqH7F55BRmGHj92KtG339AAW1lgaACWP1NA= Message-ID: References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> , <0309D74A-996B-49C1-B6CE-620459683C75@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 11:47:23 -0000 I do not want to remove the text - and Dean has explained exactly why in be= tter words than I can. I am happy to look at rewordings, but we have had too many instances where = expert review has gone into considerable detail, and that we have consensus= on is not meant here. Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Wednesday, January 20, 2010 5:50 PM > To: Robert Sparks > Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > Subject: Re: [sipcore] Draft new version:=20 > draft-ietf-sipcore-info-events-05 >=20 > Hi, >=20 > Earlier we had a rather lenghty discussion about this, I=20 > believe all text was presented on the list before added to=20 > the draft, and nobody objected... >=20 > Anyway, does anyone object if I now remove the text? >=20 > Regards, >=20 > Christer >=20 > ________________________________________ > From: Robert Sparks [rjsparks@nostrum.com] > Sent: Wednesday, January 20, 2010 8:56 AM > To: Christer Holmberg > Cc: Dean Willis; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > Subject: Re: [sipcore] Draft new version:=20 > draft-ietf-sipcore-info-events-05 >=20 > I don't think we need to keep the text - that's already what=20 > Specification Required says. >=20 > RjS >=20 > On Jan 20, 2010, at 12:39 AM, Christer Holmberg wrote: >=20 > > > > Hi, > > > > A possible comprimise would be to keep the text, but make it into a=20 > > note. > > > > Regards, > > > > Christer > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > >> Sent: 20. tammikuuta 2010 8:39 > >> To: Dean Willis; Robert Sparks > >> Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > >> Subject: Re: [sipcore] Draft new version: > >> draft-ietf-sipcore-info-events-05 > >> > >> > >> Hi Dean, > >> > >> So, you want to keep the text? > >> > >> Regards, > >> > >> Christer > >> > >>> -----Original Message----- > >>> From: Dean Willis [mailto:dean.willis@softarmor.com] > >>> Sent: 20. tammikuuta 2010 8:00 > >>> To: Robert Sparks > >>> Cc: Christer Holmberg; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > >>> Subject: Re: [sipcore] Draft new version: > >>> draft-ietf-sipcore-info-events-05 > >>> > >>> > >>> On Jan 19, 2010, at 3:35 PM, Robert Sparks wrote: > >>> > >>>> I would also have removed > >>>> " The reviewer does not consider the applicability of the > >>> Info Package > >>>> The reviewer does not consider the applicability of the > >>> Info Package > >>>> for the usage for which it is defined." > >>> > >>> While the language is broken, the intent is that the > >> reviewer not say > >>> "This is a silly thing to do with an INFO package. > >>> Why, we should be doing this with SOAP (or insert your favorite > >>> modality) instead." As a group, we tend to review SIP extensions=20 > >>> through something of a religious lens, to say "But that=20 > usage isn't=20 > >>> the intent of SIP; SIP is only for (insert favorite thing here)!" > >>> > >>> The goals of an INFO package reviewer should be to be to=20 > 1) verify=20 > >>> that the document exists and actually specifies an INFO > >> package, not > >>> something completely different (like say, a recipe for > >> cheese dip), 2) > >>> verify that the INFO package name is unique, and 3) confirm > >> that the > >>> INFO package is not trying to sneak modifications of the=20 > SIP State=20 > >>> machine into the specification family; there MUST be no normative=20 > >>> language that alters the SIP state machine functionality. > >>> > >>> > >>> If somebody wants "INFO for lightbulbs", that's OK. If they want=20 > >>> "INFO for remote procedure calls", that's OK too. > >>> Neither may be a particularly smart usage of SIP, but they don't=20 > >>> break the SIP protocol, and that's all the reviewer should care=20 > >>> about. > >>> > >>> -- > >>> Dean > >>> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From salvatore.loreto@ericsson.com Thu Jan 21 05:18:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9549E3A69EF for ; Thu, 21 Jan 2010 05:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXaHztKSKRpn for ; Thu, 21 Jan 2010 05:18:24 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E0F6E3A67DD for ; Thu, 21 Jan 2010 05:18:23 -0800 (PST) X-AuditID: c1b4fb24-b7c57ae000002bb1-97-4b58541aed21 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id F6.C1.11185.A14585B4; Thu, 21 Jan 2010 14:18:18 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 14:17:40 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 14:17:38 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 97164244F; Thu, 21 Jan 2010 15:17:38 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 618BE21A39; Thu, 21 Jan 2010 15:17:38 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0BC5D219CE; Thu, 21 Jan 2010 15:17:38 +0200 (EET) Message-ID: <4B5853F1.4050303@ericsson.com> Date: Thu, 21 Jan 2010 15:17:37 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: Paul Kyzivat References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> <4B4FBA84.2040005@cisco.com> <4B50200B.9020806@ericsson.com> <4B55C028.7060002@ericsson.com> <4B55DE45.3040307@cisco.com> In-Reply-To: <4B55DE45.3040307@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 21 Jan 2010 13:17:38.0566 (UTC) FILETIME=[1A9EA260:01CA9A9C] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 13:18:25 -0000 Hi Paul, thanks for the answer and the useful comments. I'll try to write down a mail for Dispatch wg, to check what people would like to do: put some serious effort to better specify the definition of OPTIONS method, or if for them make more sense to leave OPTIONS alone and create something new. cheers Sal On 01/19/2010 06:31 PM, Paul Kyzivat wrote: > > Salvatore Loreto wrote: > >> Hi Paul and Gonzalo, >> >> I completely agree with the fact that the OPTIONS method to discovery >> capabilities is pretty broken and then >> it is not useful to provide a meaningful service. >> >> In order to write down some requirements, lets consider the scenario >> where Alice wants to discover the Bob device capabilities >> >> >> - Capabilities >> here a first possible requirements could be: >> >> Req.: The returned capabilities to an OPTIONS request should reflect >> what Bob is able to communicate with Alice with respect >> to what are the capabilities of his fleet of devices, not just >> one device. >> > That may be in conflict with the original intent and design of OPTIONS. > Note that one of the things you are explicitly permitted to do is > restrict the hop count so that OPTIONS stops before reaching its final > address. In that case, whatever has it when it runs out of hops is > supposed to answer. > > That says to me that whoever does respond to OPTIONS should be > responding for itself. > > In the case where the request is addressed to an AOR, and there is a > proxy responsible for that AOR, that will typically route requests via > contact routing, its not entirely clear what it means to answer for itself. > > >> at present when Alice sends a SIP OPTIONS request to discover the Bob >> capabilities, >> if Bob ha registered two or more UAs, then the OPTIONS request forks and >> arrive to all the registered UAs; >> however the proxy performing the forking forwards back to Alice only the >> first response it receives. >> > That *may* be what happens. > > >> Preferably the capability discovery mechanism should let Alice (or >> rather Alices device) know if Bob can take audio on one device, >> but video, video and text on his other visual friendly device. >> > That would be a nice thing to be able to learn. > Whether OPTIONS is the way to achieve that is an entirely different > question. > > What would you do? Have the proxy send *new* OPTIONS to each registered > device and then consolidate the results? Would that entail a > multipart/alternative containing SDP from each contact? > > >> If a capability discovery mechanism is able to provide that level of >> granularity, it helps Alice's device understand that while on a >> voice session with Bob, it is no way a re-INVITE to video would work, >> but instead her device should send a new video-session INVITE >> towards Bob allowing hi to press the 'yes' button on the visual device. >> > I think Alice needs more information before concluding that. > It may be that those two devices reside in Bob's multiple offices, one > in Boston and the other in San Jose. > > Also, Alice then needs a way of directing the new INVITE to the intended > destination. (Perhaps callerprefs would meet this need, perhaps not.) > > >> Thus, there would be two parallel sessions between Alice and Bob, >> one for voice and the second one for video/text/picture. >> A capability discovery mechanism like this would also provide the >> context for capabilities, where as Paul points out in his mail at moment >> with the currents OPTIONS request capabilities are context free. >> > If people think this is worth doing, we could no doubt come up with a > way of doing it. But it seems unlikely that OPTIONS would be the whole > answer. (Realistically it probably makes more sense to leave OPTIONS > alone and create something new.) > > >> - Time >> The capabilities should not be considered stable over time, however they >> can be regarded as stable (but without any guarantees) if an INVITE take >> places within short time. >> The latter is often the the intent of the querying party I would assume. >> Thus, Alice wants to communicate with Bob "now" but first wants to check >> "what" Bob can do. That is why she sends an OPTIONS. Soon as she knows >> the capabilities, she immediately invokes a compatible (to the >> capabilities received) >> communication manner. >> > That may be a reasonable goal. But it probably requires some more > examination into the reasons that capabilities might change over time. > For instance, if Bob's device is handling a call when it receives the > query, does the response reflect what it can do concurrently with that > call, or what it will be able to do once that call has ended? (Both may > be useful pieces of information.) > > Thanks, > Paul > > >> Cheers >> Sal >> >> >> Gonzalo Camarillo wrote: >> >>> Hi Paul, >>> >>> >>> >>>> I agree, but the problem is bigger than this draft. >>>> >>>> The whole concept that OPTIONS will tell you the capabilities of the >>>> UA is pretty broken - it assumes those are stable over time and are >>>> context free, which is often not the case. There are almost never any >>>> guarantees that the info you receive from OPTIONS will still be true >>>> if you try to act on it. >>>> >>>> The concept that the response code from OPTIONS should be the same as >>>> you would get were you to send an INVITE is even more broken. It >>>> doesn't work at all well for UAs that don't support INVITE. >>>> >>>> The definition of OPTIONS needs some serious rework. >>>> >>>> >>> yes, this has come up several times in the past. When people try to >>> use OPTIONS to provide a meaningful service, they fairly soon notice >>> how broken it is. At some point, it could be interesting to gather a >>> few requirements and try to fix it somehow. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >>> >> >> From christer.holmberg@ericsson.com Thu Jan 21 05:43:53 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E65F28C13F for ; Thu, 21 Jan 2010 05:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.133 X-Spam-Level: X-Spam-Status: No, score=-6.133 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPHZosRsmQkE for ; Thu, 21 Jan 2010 05:43:51 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id DE0713A6A44 for ; Thu, 21 Jan 2010 05:43:49 -0800 (PST) X-AuditID: c1b4fb24-b7c57ae000002bb1-e7-4b585a10f5d0 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id E0.B4.11185.01A585B4; Thu, 21 Jan 2010 14:43:44 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.83) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 21 Jan 2010 14:43:43 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Thu, 21 Jan 2010 14:43:43 +0100 From: Christer Holmberg To: Salvatore Loreto , Paul Kyzivat Date: Thu, 21 Jan 2010 14:43:42 +0100 Thread-Topic: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) Thread-Index: AcqanDbtVFHVXjaBSu+CpfHixN9xDQAA1JoA Message-ID: References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> <4B4FBA84.2040005@cisco.com> <4B50200B.9020806@ericsson.com> <4B55C028.7060002@ericsson.com> <4B55DE45.3040307@cisco.com> <4B5853F1.4050303@ericsson.com> In-Reply-To: <4B5853F1.4050303@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 13:43:53 -0000 Hi, We can of course clarify the generic procedures for OPTIONS. But, I think t= here is always going to be a need to describe how OPTIONS is applied to spe= cific header fields, message body MIMEs etc, as I tried to do in the Info d= raft. Regards, Christer=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Salvatore Loreto > Sent: 21. tammikuuta 2010 15:18 > To: Paul Kyzivat > Cc: SIPCORE; Gonzalo Camarillo > Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting=20 > the publication of the draft-ietf-sipcore-info-events) >=20 > Hi Paul, >=20 > thanks for the answer and the useful comments. > I'll try to write down a mail for Dispatch wg, to check what=20 > people would like to do: > put some serious effort to better specify the definition of=20 > OPTIONS method, or if for them make more sense to leave=20 > OPTIONS alone and create something new. >=20 > cheers > Sal >=20 >=20 > On 01/19/2010 06:31 PM, Paul Kyzivat wrote: > > > > Salvatore Loreto wrote: > > =20 > >> Hi Paul and Gonzalo, > >> > >> I completely agree with the fact that the OPTIONS method=20 > to discovery=20 > >> capabilities is pretty broken and then it is not useful to=20 > provide a=20 > >> meaningful service. > >> > >> In order to write down some requirements, lets consider=20 > the scenario=20 > >> where Alice wants to discover the Bob device capabilities > >> > >> > >> - Capabilities > >> here a first possible requirements could be: > >> > >> Req.: The returned capabilities to an OPTIONS request=20 > should reflect > >> what Bob is able to communicate with Alice with respect > >> to what are the capabilities of his fleet of=20 > devices, not just > >> one device. > >> =20 > > That may be in conflict with the original intent and design=20 > of OPTIONS. > > Note that one of the things you are explicitly permitted to do is=20 > > restrict the hop count so that OPTIONS stops before=20 > reaching its final=20 > > address. In that case, whatever has it when it runs out of hops is=20 > > supposed to answer. > > > > That says to me that whoever does respond to OPTIONS should be=20 > > responding for itself. > > > > In the case where the request is addressed to an AOR, and=20 > there is a=20 > > proxy responsible for that AOR, that will typically route=20 > requests via=20 > > contact routing, its not entirely clear what it means to=20 > answer for itself. > > > > =20 > >> at present when Alice sends a SIP OPTIONS request to=20 > discover the Bob=20 > >> capabilities, if Bob ha registered two or more UAs, then=20 > the OPTIONS=20 > >> request forks and arrive to all the registered UAs;=20 > however the proxy=20 > >> performing the forking forwards back to Alice only the=20 > first response=20 > >> it receives. > >> =20 > > That *may* be what happens. > > > > =20 > >> Preferably the capability discovery mechanism should let=20 > Alice (or=20 > >> rather Alices device) know if Bob can take audio on one=20 > device, but=20 > >> video, video and text on his other visual friendly device. > >> =20 > > That would be a nice thing to be able to learn. > > Whether OPTIONS is the way to achieve that is an entirely different=20 > > question. > > > > What would you do? Have the proxy send *new* OPTIONS to each=20 > > registered device and then consolidate the results? Would=20 > that entail=20 > > a multipart/alternative containing SDP from each contact? > > > > =20 > >> If a capability discovery mechanism is able to provide=20 > that level of=20 > >> granularity, it helps Alice's device understand that while=20 > on a voice=20 > >> session with Bob, it is no way a re-INVITE to video would=20 > work, but=20 > >> instead her device should send a new video-session INVITE=20 > towards Bob=20 > >> allowing hi to press the 'yes' button on the visual device. > >> =20 > > I think Alice needs more information before concluding that. > > It may be that those two devices reside in Bob's multiple=20 > offices, one=20 > > in Boston and the other in San Jose. > > > > Also, Alice then needs a way of directing the new INVITE to the=20 > > intended destination. (Perhaps callerprefs would meet this need,=20 > > perhaps not.) > > > > =20 > >> Thus, there would be two parallel sessions between Alice=20 > and Bob, one=20 > >> for voice and the second one for video/text/picture. > >> A capability discovery mechanism like this would also provide the=20 > >> context for capabilities, where as Paul points out in his mail at=20 > >> moment with the currents OPTIONS request capabilities are=20 > context free. > >> =20 > > If people think this is worth doing, we could no doubt come=20 > up with a=20 > > way of doing it. But it seems unlikely that OPTIONS would=20 > be the whole=20 > > answer. (Realistically it probably makes more sense to=20 > leave OPTIONS=20 > > alone and create something new.) > > > > =20 > >> - Time > >> The capabilities should not be considered stable over=20 > time, however=20 > >> they can be regarded as stable (but without any guarantees) if an=20 > >> INVITE take places within short time. > >> The latter is often the the intent of the querying party I=20 > would assume. > >> Thus, Alice wants to communicate with Bob "now" but first wants to=20 > >> check "what" Bob can do. That is why she sends an OPTIONS. Soon as=20 > >> she knows the capabilities, she immediately invokes a=20 > compatible (to=20 > >> the capabilities received) communication manner. > >> =20 > > That may be a reasonable goal. But it probably requires some more=20 > > examination into the reasons that capabilities might change=20 > over time. > > For instance, if Bob's device is handling a call when it=20 > receives the=20 > > query, does the response reflect what it can do=20 > concurrently with that=20 > > call, or what it will be able to do once that call has ended? (Both=20 > > may be useful pieces of information.) > > > > Thanks, > > Paul > > > > =20 > >> Cheers > >> Sal > >> > >> > >> Gonzalo Camarillo wrote: > >> =20 > >>> Hi Paul, > >>> > >>> > >>> =20 > >>>> I agree, but the problem is bigger than this draft. > >>>> > >>>> The whole concept that OPTIONS will tell you the capabilities of=20 > >>>> the UA is pretty broken - it assumes those are stable=20 > over time and=20 > >>>> are context free, which is often not the case. There are almost=20 > >>>> never any guarantees that the info you receive from OPTIONS will=20 > >>>> still be true if you try to act on it. > >>>> > >>>> The concept that the response code from OPTIONS should=20 > be the same=20 > >>>> as you would get were you to send an INVITE is even more=20 > broken. It=20 > >>>> doesn't work at all well for UAs that don't support INVITE. > >>>> > >>>> The definition of OPTIONS needs some serious rework. > >>>> > >>>> =20 > >>> yes, this has come up several times in the past. When=20 > people try to=20 > >>> use OPTIONS to provide a meaningful service, they fairly=20 > soon notice=20 > >>> how broken it is. At some point, it could be interesting=20 > to gather a=20 > >>> few requirements and try to fix it somehow. > >>> > >>> Cheers, > >>> > >>> Gonzalo > >>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >>> > >>> =20 > >> > >> =20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Thu Jan 21 06:15:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391383A68F4 for ; Thu, 21 Jan 2010 06:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEoD5dusg-3u for ; Thu, 21 Jan 2010 06:15:36 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C31623A6890 for ; Thu, 21 Jan 2010 06:15:36 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG/wV0utJV2Z/2dsb2JhbADDGpVZhDwE X-IronPort-AV: E=Sophos;i="4.49,317,1262563200"; d="scan'208";a="234394873" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-2.cisco.com with ESMTP; 21 Jan 2010 14:15:32 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.173]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o0LEFWL8030970; Thu, 21 Jan 2010 14:15:32 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 08:15:32 -0600 Received: from [10.86.250.155] ([10.86.250.155]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 08:15:31 -0600 Message-ID: <4B586180.7030308@cisco.com> Date: Thu, 21 Jan 2010 09:15:28 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B4EFFF9.1030705@ericsson.com> <32A90B8E-71D4-4A34-83DB-EEDA5517D214@nostrum.com> <4B4FBA84.2040005@cisco.com> <4B50200B.9020806@ericsson.com> <4B55C028.7060002@ericsson.com> <4B55DE45.3040307@cisco.com> <4B5853F1.4050303@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2010 14:15:31.0966 (UTC) FILETIME=[30ED69E0:01CA9AA4] Cc: SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting the publication of the draft-ietf-sipcore-info-events) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 14:15:38 -0000 Christer, I agree with you that there is need to specify the handling of specific headers, etc. in OPTIONS. But that ought to be consistent with a general philosophy of how OPTIONS is intended to work. It seems that philosophy is currently inadequate. Thanks, Paul Christer Holmberg wrote: > Hi, > > We can of course clarify the generic procedures for OPTIONS. But, I think there is always going to be a need to describe how OPTIONS is applied to specific header fields, message body MIMEs etc, as I tried to do in the Info draft. > > Regards, > > Christer > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Salvatore Loreto >> Sent: 21. tammikuuta 2010 15:18 >> To: Paul Kyzivat >> Cc: SIPCORE; Gonzalo Camarillo >> Subject: Re: [sipcore] OPTIONS requests WAS (Re: Requesting >> the publication of the draft-ietf-sipcore-info-events) >> >> Hi Paul, >> >> thanks for the answer and the useful comments. >> I'll try to write down a mail for Dispatch wg, to check what >> people would like to do: >> put some serious effort to better specify the definition of >> OPTIONS method, or if for them make more sense to leave >> OPTIONS alone and create something new. >> >> cheers >> Sal >> >> >> On 01/19/2010 06:31 PM, Paul Kyzivat wrote: >>> Salvatore Loreto wrote: >>> >>>> Hi Paul and Gonzalo, >>>> >>>> I completely agree with the fact that the OPTIONS method >> to discovery >>>> capabilities is pretty broken and then it is not useful to >> provide a >>>> meaningful service. >>>> >>>> In order to write down some requirements, lets consider >> the scenario >>>> where Alice wants to discover the Bob device capabilities >>>> >>>> >>>> - Capabilities >>>> here a first possible requirements could be: >>>> >>>> Req.: The returned capabilities to an OPTIONS request >> should reflect >>>> what Bob is able to communicate with Alice with respect >>>> to what are the capabilities of his fleet of >> devices, not just >>>> one device. >>>> >>> That may be in conflict with the original intent and design >> of OPTIONS. >>> Note that one of the things you are explicitly permitted to do is >>> restrict the hop count so that OPTIONS stops before >> reaching its final >>> address. In that case, whatever has it when it runs out of hops is >>> supposed to answer. >>> >>> That says to me that whoever does respond to OPTIONS should be >>> responding for itself. >>> >>> In the case where the request is addressed to an AOR, and >> there is a >>> proxy responsible for that AOR, that will typically route >> requests via >>> contact routing, its not entirely clear what it means to >> answer for itself. >>> >>>> at present when Alice sends a SIP OPTIONS request to >> discover the Bob >>>> capabilities, if Bob ha registered two or more UAs, then >> the OPTIONS >>>> request forks and arrive to all the registered UAs; >> however the proxy >>>> performing the forking forwards back to Alice only the >> first response >>>> it receives. >>>> >>> That *may* be what happens. >>> >>> >>>> Preferably the capability discovery mechanism should let >> Alice (or >>>> rather Alices device) know if Bob can take audio on one >> device, but >>>> video, video and text on his other visual friendly device. >>>> >>> That would be a nice thing to be able to learn. >>> Whether OPTIONS is the way to achieve that is an entirely different >>> question. >>> >>> What would you do? Have the proxy send *new* OPTIONS to each >>> registered device and then consolidate the results? Would >> that entail >>> a multipart/alternative containing SDP from each contact? >>> >>> >>>> If a capability discovery mechanism is able to provide >> that level of >>>> granularity, it helps Alice's device understand that while >> on a voice >>>> session with Bob, it is no way a re-INVITE to video would >> work, but >>>> instead her device should send a new video-session INVITE >> towards Bob >>>> allowing hi to press the 'yes' button on the visual device. >>>> >>> I think Alice needs more information before concluding that. >>> It may be that those two devices reside in Bob's multiple >> offices, one >>> in Boston and the other in San Jose. >>> >>> Also, Alice then needs a way of directing the new INVITE to the >>> intended destination. (Perhaps callerprefs would meet this need, >>> perhaps not.) >>> >>> >>>> Thus, there would be two parallel sessions between Alice >> and Bob, one >>>> for voice and the second one for video/text/picture. >>>> A capability discovery mechanism like this would also provide the >>>> context for capabilities, where as Paul points out in his mail at >>>> moment with the currents OPTIONS request capabilities are >> context free. >>>> >>> If people think this is worth doing, we could no doubt come >> up with a >>> way of doing it. But it seems unlikely that OPTIONS would >> be the whole >>> answer. (Realistically it probably makes more sense to >> leave OPTIONS >>> alone and create something new.) >>> >>> >>>> - Time >>>> The capabilities should not be considered stable over >> time, however >>>> they can be regarded as stable (but without any guarantees) if an >>>> INVITE take places within short time. >>>> The latter is often the the intent of the querying party I >> would assume. >>>> Thus, Alice wants to communicate with Bob "now" but first wants to >>>> check "what" Bob can do. That is why she sends an OPTIONS. Soon as >>>> she knows the capabilities, she immediately invokes a >> compatible (to >>>> the capabilities received) communication manner. >>>> >>> That may be a reasonable goal. But it probably requires some more >>> examination into the reasons that capabilities might change >> over time. >>> For instance, if Bob's device is handling a call when it >> receives the >>> query, does the response reflect what it can do >> concurrently with that >>> call, or what it will be able to do once that call has ended? (Both >>> may be useful pieces of information.) >>> >>> Thanks, >>> Paul >>> >>> >>>> Cheers >>>> Sal >>>> >>>> >>>> Gonzalo Camarillo wrote: >>>> >>>>> Hi Paul, >>>>> >>>>> >>>>> >>>>>> I agree, but the problem is bigger than this draft. >>>>>> >>>>>> The whole concept that OPTIONS will tell you the capabilities of >>>>>> the UA is pretty broken - it assumes those are stable >> over time and >>>>>> are context free, which is often not the case. There are almost >>>>>> never any guarantees that the info you receive from OPTIONS will >>>>>> still be true if you try to act on it. >>>>>> >>>>>> The concept that the response code from OPTIONS should >> be the same >>>>>> as you would get were you to send an INVITE is even more >> broken. It >>>>>> doesn't work at all well for UAs that don't support INVITE. >>>>>> >>>>>> The definition of OPTIONS needs some serious rework. >>>>>> >>>>>> >>>>> yes, this has come up several times in the past. When >> people try to >>>>> use OPTIONS to provide a meaningful service, they fairly >> soon notice >>>>> how broken it is. At some point, it could be interesting >> to gather a >>>>> few requirements and try to fix it somehow. >>>>> >>>>> Cheers, >>>>> >>>>> Gonzalo >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>>> >>>>> >>>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From rjsparks@nostrum.com Thu Jan 21 07:27:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138853A690D for ; Thu, 21 Jan 2010 07:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3K2qEDgc2um2 for ; Thu, 21 Jan 2010 07:27:51 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A012C3A68FE for ; Thu, 21 Jan 2010 07:27:50 -0800 (PST) Received: from dn3-173.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0LFRehp016817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Jan 2010 09:27:40 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: "DRAGE, Keith (Keith)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 21 Jan 2010 09:27:39 -0600 References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> , <0309D74A-996B-49C1-B6CE-620459683C75@nostrum.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 15:27:52 -0000 I think what its trying to say is exactly what 5226 says in its definition of Specification Required and that we run the risk of introducing ambiguity and confusion by trying to duplicate what's said there. I don't think we're trying to modify that definition and that the pressure you're trying to put on it would be clarifying pressure. There might be better text that could do that without introducing ambiguity, but we've noted the current text isn't it. My proposed alternate text is the empty string. If we _are_ trying to modify that definition, then we need quite a bit of different, and very explicit, text. RjS On Jan 21, 2010, at 5:47 AM, DRAGE, Keith (Keith) wrote: > I do not want to remove the text - and Dean has explained exactly > why in better words than I can. > > I am happy to look at rewordings, but we have had too many instances > where expert review has gone into considerable detail, and that we > have consensus on is not meant here. > > Keith > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: Wednesday, January 20, 2010 5:50 PM >> To: Robert Sparks >> Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan >> Subject: Re: [sipcore] Draft new version: >> draft-ietf-sipcore-info-events-05 >> >> Hi, >> >> Earlier we had a rather lenghty discussion about this, I >> believe all text was presented on the list before added to >> the draft, and nobody objected... >> >> Anyway, does anyone object if I now remove the text? >> >> Regards, >> >> Christer >> >> ________________________________________ >> From: Robert Sparks [rjsparks@nostrum.com] >> Sent: Wednesday, January 20, 2010 8:56 AM >> To: Christer Holmberg >> Cc: Dean Willis; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan >> Subject: Re: [sipcore] Draft new version: >> draft-ietf-sipcore-info-events-05 >> >> I don't think we need to keep the text - that's already what >> Specification Required says. >> >> RjS >> >> On Jan 20, 2010, at 12:39 AM, Christer Holmberg wrote: >> >>> >>> Hi, >>> >>> A possible comprimise would be to keep the text, but make it into a >>> note. >>> >>> Regards, >>> >>> Christer >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >>>> Sent: 20. tammikuuta 2010 8:39 >>>> To: Dean Willis; Robert Sparks >>>> Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan >>>> Subject: Re: [sipcore] Draft new version: >>>> draft-ietf-sipcore-info-events-05 >>>> >>>> >>>> Hi Dean, >>>> >>>> So, you want to keep the text? >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>>> -----Original Message----- >>>>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>>>> Sent: 20. tammikuuta 2010 8:00 >>>>> To: Robert Sparks >>>>> Cc: Christer Holmberg; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan >>>>> Subject: Re: [sipcore] Draft new version: >>>>> draft-ietf-sipcore-info-events-05 >>>>> >>>>> >>>>> On Jan 19, 2010, at 3:35 PM, Robert Sparks wrote: >>>>> >>>>>> I would also have removed >>>>>> " The reviewer does not consider the applicability of the >>>>> Info Package >>>>>> The reviewer does not consider the applicability of the >>>>> Info Package >>>>>> for the usage for which it is defined." >>>>> >>>>> While the language is broken, the intent is that the >>>> reviewer not say >>>>> "This is a silly thing to do with an INFO package. >>>>> Why, we should be doing this with SOAP (or insert your favorite >>>>> modality) instead." As a group, we tend to review SIP extensions >>>>> through something of a religious lens, to say "But that >> usage isn't >>>>> the intent of SIP; SIP is only for (insert favorite thing here)!" >>>>> >>>>> The goals of an INFO package reviewer should be to be to >> 1) verify >>>>> that the document exists and actually specifies an INFO >>>> package, not >>>>> something completely different (like say, a recipe for >>>> cheese dip), 2) >>>>> verify that the INFO package name is unique, and 3) confirm >>>> that the >>>>> INFO package is not trying to sneak modifications of the >> SIP State >>>>> machine into the specification family; there MUST be no normative >>>>> language that alters the SIP state machine functionality. >>>>> >>>>> >>>>> If somebody wants "INFO for lightbulbs", that's OK. If they want >>>>> "INFO for remote procedure calls", that's OK too. >>>>> Neither may be a particularly smart usage of SIP, but they don't >>>>> break the SIP protocol, and that's all the reviewer should care >>>>> about. >>>>> >>>>> -- >>>>> Dean >>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From christer.holmberg@ericsson.com Fri Jan 22 06:16:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3B13A67CC for ; Fri, 22 Jan 2010 06:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.143 X-Spam-Level: X-Spam-Status: No, score=-6.143 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Qr1o7iZO9Ak for ; Fri, 22 Jan 2010 06:16:07 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 8E7FA3A67BD for ; Fri, 22 Jan 2010 06:16:06 -0800 (PST) X-AuditID: c1b4fb24-b7c57ae000002bb1-d8-4b59b320efb9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 8F.F7.11185.023B95B4; Fri, 22 Jan 2010 15:16:00 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 22 Jan 2010 15:16:00 +0100 From: Christer Holmberg To: Robert Sparks , "DRAGE, Keith (Keith)" Date: Fri, 22 Jan 2010 15:15:59 +0100 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 Thread-Index: Acqarkj1btXEc/8oQ2aL0vgbFWoBhgAvYbLQ Message-ID: References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> , <0309D74A-996B-49C1-B6CE-620459683C75@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 14:16:08 -0000 We can always say "according to RFC 5226, blah blah blah". The -v5 text says: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "The registration policy for the registry is Specification Required [RFC5226]. The reviewer does not consider the applicability of the Info Package for the usage for which it is defined." In any case, if we go forward with this, it needs to be modified, because n= ow "reviewer" seems to come out of the blue. The -v4 text says: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "Based on [RFC5226], IANA assigns an expert in order to review an Info Package which is to be registered. The Info Package specification is provided to the reviewer, who ensures that the Info Package is described in a proper way. The reviewer does not consider the applicability of the Info Package for the usage for which it is defined." In any case, if we go forward with this, it needs to be modified, because I= think "Specification Required" should be mentioned. Now, a compromise could be: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D "The registration policy for the registry is Specification Required [RFC522= 6]. According to [RFC5226], IANA assigns an expert in order to review an Info P= ackage=20 which is to be registered. The reviewer ensures that the Info Package is de= fined=20 in a proper way, but does not consider the applicability of the usage for w= hich=20 the Info Package is defined." Regards, Christer > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: 21. tammikuuta 2010 17:28 > To: DRAGE, Keith (Keith) > Cc: Christer Holmberg; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > Subject: Re: [sipcore] Draft new version:=20 > draft-ietf-sipcore-info-events-05 >=20 > I think what its trying to say is exactly what 5226 says in=20 > its definition of Specification Required and that we run the=20 > risk of introducing ambiguity and confusion by trying to=20 > duplicate what's said there. >=20 > I don't think we're trying to modify that definition and that=20 > the pressure you're trying to put on it would be clarifying=20 > pressure. There might be better text that could do that=20 > without introducing ambiguity, but we've noted the current=20 > text isn't it. My proposed alternate text is the empty string. >=20 > If we _are_ trying to modify that definition, then we need=20 > quite a bit of different, and very explicit, text. >=20 > RjS >=20 > On Jan 21, 2010, at 5:47 AM, DRAGE, Keith (Keith) wrote: >=20 > > I do not want to remove the text - and Dean has explained=20 > exactly why=20 > > in better words than I can. > > > > I am happy to look at rewordings, but we have had too many=20 > instances=20 > > where expert review has gone into considerable detail, and that we=20 > > have consensus on is not meant here. > > > > Keith > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > >> Sent: Wednesday, January 20, 2010 5:50 PM > >> To: Robert Sparks > >> Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > >> Subject: Re: [sipcore] Draft new version: > >> draft-ietf-sipcore-info-events-05 > >> > >> Hi, > >> > >> Earlier we had a rather lenghty discussion about this, I=20 > believe all=20 > >> text was presented on the list before added to the draft,=20 > and nobody=20 > >> objected... > >> > >> Anyway, does anyone object if I now remove the text? > >> > >> Regards, > >> > >> Christer > >> > >> ________________________________________ > >> From: Robert Sparks [rjsparks@nostrum.com] > >> Sent: Wednesday, January 20, 2010 8:56 AM > >> To: Christer Holmberg > >> Cc: Dean Willis; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > >> Subject: Re: [sipcore] Draft new version: > >> draft-ietf-sipcore-info-events-05 > >> > >> I don't think we need to keep the text - that's already what=20 > >> Specification Required says. > >> > >> RjS > >> > >> On Jan 20, 2010, at 12:39 AM, Christer Holmberg wrote: > >> > >>> > >>> Hi, > >>> > >>> A possible comprimise would be to keep the text, but make=20 > it into a=20 > >>> note. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>>> -----Original Message----- > >>>> From: sipcore-bounces@ietf.org > >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > >>>> Sent: 20. tammikuuta 2010 8:39 > >>>> To: Dean Willis; Robert Sparks > >>>> Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > >>>> Subject: Re: [sipcore] Draft new version: > >>>> draft-ietf-sipcore-info-events-05 > >>>> > >>>> > >>>> Hi Dean, > >>>> > >>>> So, you want to keep the text? > >>>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>>> -----Original Message----- > >>>>> From: Dean Willis [mailto:dean.willis@softarmor.com] > >>>>> Sent: 20. tammikuuta 2010 8:00 > >>>>> To: Robert Sparks > >>>>> Cc: Christer Holmberg; SIPCORE; Gonzalo Camarillo;=20 > Hadriel Kaplan > >>>>> Subject: Re: [sipcore] Draft new version: > >>>>> draft-ietf-sipcore-info-events-05 > >>>>> > >>>>> > >>>>> On Jan 19, 2010, at 3:35 PM, Robert Sparks wrote: > >>>>> > >>>>>> I would also have removed > >>>>>> " The reviewer does not consider the applicability of the > >>>>> Info Package > >>>>>> The reviewer does not consider the applicability of the > >>>>> Info Package > >>>>>> for the usage for which it is defined." > >>>>> > >>>>> While the language is broken, the intent is that the > >>>> reviewer not say > >>>>> "This is a silly thing to do with an INFO package. > >>>>> Why, we should be doing this with SOAP (or insert your favorite > >>>>> modality) instead." As a group, we tend to review SIP=20 > extensions=20 > >>>>> through something of a religious lens, to say "But that > >> usage isn't > >>>>> the intent of SIP; SIP is only for (insert favorite=20 > thing here)!" > >>>>> > >>>>> The goals of an INFO package reviewer should be to be to > >> 1) verify > >>>>> that the document exists and actually specifies an INFO > >>>> package, not > >>>>> something completely different (like say, a recipe for > >>>> cheese dip), 2) > >>>>> verify that the INFO package name is unique, and 3) confirm > >>>> that the > >>>>> INFO package is not trying to sneak modifications of the > >> SIP State > >>>>> machine into the specification family; there MUST be no=20 > normative=20 > >>>>> language that alters the SIP state machine functionality. > >>>>> > >>>>> > >>>>> If somebody wants "INFO for lightbulbs", that's OK. If=20 > they want=20 > >>>>> "INFO for remote procedure calls", that's OK too. > >>>>> Neither may be a particularly smart usage of SIP, but=20 > they don't=20 > >>>>> break the SIP protocol, and that's all the reviewer should care=20 > >>>>> about. > >>>>> > >>>>> -- > >>>>> Dean > >>>>> > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> >=20 > = From dean.willis@softarmor.com Fri Jan 22 07:55:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5943E3A6949 for ; Fri, 22 Jan 2010 07:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG5ZvS5nJPMz for ; Fri, 22 Jan 2010 07:55:23 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4095E3A6812 for ; Fri, 22 Jan 2010 07:55:23 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0MFt751006237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2010 09:55:09 -0600 Message-Id: <6E2E1A30-72B6-4B8A-8EDA-51AFBF447588@softarmor.com> From: Dean Willis To: Robert Sparks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Jan 2010 09:55:01 -0600 References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> , <0309D74A-996B-49C1-B6CE-620459683C75@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 15:55:24 -0000 On Jan 21, 2010, at 9:27 AM, Robert Sparks wrote: > I think what its trying to say is exactly what 5226 says in its > definition of > Specification Required and that we run the risk of introducing > ambiguity > and confusion by trying to duplicate what's said there. > > I don't think we're trying to modify that definition and that the > pressure > you're trying to put on it would be clarifying pressure. There might > be > better text that could do that without introducing ambiguity, but > we've > noted the current text isn't it. My proposed alternate text is the > empty string. > > If we _are_ trying to modify that definition, then we need quite a bit > of different, and very explicit, text. 5226 says: "Specification Required - Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path. For RFC publication, the normal RFC review process is expected to provide the necessary review for interoperability, though the Designated Expert may be a particularly well-qualified person to perform such a review." The problem the text was trying to resolve is that we (the SIP community in IETF) have a strong history of being fussy about SIP extensions. We don't really know how to live within the implications of "Specification Required" and were trying to leave ourselves a note reminding us how to do our jobs, so that when it comes up (and it well) the argumentation is there to fall back on. But there is a certain critical element of "fussiness" that we wish to preserve; the INFO package being defined MAY be silly, but it MUST NOT functionally change the SIP protocol or state machine. INFO is a pure-and-simple use of SIP for transport, and just as we wouldn't define an HTTP extension that says "If the result of the GET is a MIME object of type foo/bar, then the browser MUST terminate immediately without properly closing the TCP connection", we wouldn't do something equally destructive to SIP in an INFO package (although I'm not sure we won't do something that crazy on the standards track!). Let me propose some alternate text: Note to Reviewers The policy for review of INFO packages is "Specification Required" as in RFC 5226. This policy was selected because INFO packages re-use an existing mechanism for transport of arbitrary session-associated data within SIP, and therefore new INFO packages do not require the more extensive review required by specifications that make fundamental protocol changes. However, the reviewer is expected to verify that each INFO package registration is in fact consistent with this definition. Changes to the SIP protocol and state machine are outside of the allowable scope for an INFO package and are governed by other procedures including RFC 3427 and its successors, if any. -- Dean From rjsparks@nostrum.com Fri Jan 22 10:24:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90C93A6A6F for ; Fri, 22 Jan 2010 10:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF4f9KT9hogw for ; Fri, 22 Jan 2010 10:24:51 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 024683A6AAE for ; Fri, 22 Jan 2010 10:24:49 -0800 (PST) Received: from 61.46.240.10.in-addr.arpa (m2d5736d0.tmodns.net [208.54.87.45]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0MIOcNo018155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Jan 2010 12:24:39 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Dean Willis In-Reply-To: <6E2E1A30-72B6-4B8A-8EDA-51AFBF447588@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Jan 2010 13:24:33 -0500 References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> , <0309D74A-996B-49C1-B6CE-620459683C75@nostrum.com> <6E2E1A30-72B6-4B8A-8EDA-51AFBF447588@softarmor.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 208.54.87.45 is authenticated by a trusted mechanism) Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 18:24:56 -0000 I'd be ok with that text. Just to make sure we're explicit, do you think this absolves the reviewer of making sure the specification meets the requirements that this new RFC would put on any new package? We had a long conversation essentially about whether a blank, but stable, document satisfied specification required. I want to make sure we don't regress and lose where that conversation ended. RjS On Jan 22, 2010, at 10:55 AM, Dean Willis wrote: > > On Jan 21, 2010, at 9:27 AM, Robert Sparks wrote: > >> I think what its trying to say is exactly what 5226 says in its >> definition of >> Specification Required and that we run the risk of introducing >> ambiguity >> and confusion by trying to duplicate what's said there. >> >> I don't think we're trying to modify that definition and that the >> pressure >> you're trying to put on it would be clarifying pressure. There >> might be >> better text that could do that without introducing ambiguity, but >> we've >> noted the current text isn't it. My proposed alternate text is the >> empty string. >> >> If we _are_ trying to modify that definition, then we need quite a >> bit >> of different, and very explicit, text. > > > 5226 says: > > "Specification Required - Values and their meanings must be > documented in a permanent and readily available public > specification, in sufficient detail so that interoperability between > independent implementations is possible. When used, Specification > Required also implies use of a Designated Expert, who will review > the public specification and evaluate whether it is sufficiently > clear to allow interoperable implementations. The intention behind > "permanent and readily available" is that a document can reasonably > be expected to be findable and retrievable long after IANA > assignment of the requested value. Publication of an RFC is an ideal > means of achieving this requirement, but Specification Required is > intended to also cover the case of a document published outside of > the RFC path. For RFC publication, the normal RFC review process is > expected to provide the necessary review for interoperability, > though the Designated Expert may be a particularly well-qualified > person to perform such a review." > > The problem the text was trying to resolve is that we (the SIP > community in IETF) have a strong history of being fussy about SIP > extensions. We don't really know how to live within the implications > of "Specification Required" and were trying to leave ourselves a > note reminding us how to do our jobs, so that when it comes up (and > it well) the argumentation is there to fall back on. But there is a > certain critical element of "fussiness" that we wish to preserve; > the INFO package being defined MAY be silly, but it MUST NOT > functionally change the SIP protocol or state machine. INFO is a > pure-and-simple use of SIP for transport, and just as we wouldn't > define an HTTP extension that says "If the result of the GET is a > MIME object of type foo/bar, then the browser MUST terminate > immediately without properly closing the TCP connection", we > wouldn't do something equally destructive to SIP in an INFO package > (although I'm not sure we won't do something that crazy on the > standards track!). > > Let me propose some alternate text: > > > Note to Reviewers > > The policy for review of INFO packages is "Specification Required" > as in RFC 5226. This policy was selected because INFO packages re- > use an existing mechanism for transport of arbitrary session- > associated data within SIP, and therefore new INFO packages do not > require the more extensive review required by specifications that > make fundamental protocol changes. However, the reviewer is expected > to verify that each INFO package registration is in fact consistent > with this definition. Changes to the SIP protocol and state machine > are outside of the allowable scope for an INFO package and are > governed by other procedures including RFC 3427 and its successors, > if any. > > > -- > Dean From root@core3.amsl.com Fri Jan 22 13:15:01 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CFB4A3A69F5; Fri, 22 Jan 2010 13:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100122211501.CFB4A3A69F5@core3.amsl.com> Date: Fri, 22 Jan 2010 13:15:01 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-sec-flows-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 21:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Example call flows using Session Initiation Protocol (SIP) security mechanisms Author(s) : C. Jennings, et al. Filename : draft-ietf-sipcore-sec-flows-02.txt Pages : 62 Date : 2010-01-22 This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-sec-flows-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-22131020.I-D@ietf.org> --NextPart-- From brian@estacado.net Fri Jan 22 13:16:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8840B3A6944 for ; Fri, 22 Jan 2010 13:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiwfG30bRTv1 for ; Fri, 22 Jan 2010 13:16:42 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 31F9A3A68C1 for ; Fri, 22 Jan 2010 13:16:41 -0800 (PST) Received: from dn3-229.estacado.net (dn3-229.estacado.net [172.16.3.229]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o0MLGavh048520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 22 Jan 2010 15:16:36 -0600 (CST) (envelope-from brian@estacado.net) Message-Id: <25A4765F-7DE3-46A7-903A-C0753206FDF4@estacado.net> From: Brian Hibbard To: SIPCORE Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Jan 2010 15:16:30 -0600 X-Mailer: Apple Mail (2.936) Subject: [sipcore] Draft new version: draft-ietf-sipcore-sec-flows-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 21:16:43 -0000 Greetings, A new version of the Sec Flows draft is now available. Below is a summary of the remaining OPEN ISSUES and TODO items, each by section. =========== OPEN ISSUES =========== 3.2. MESSAGE Message Over TLS OPEN ISSUE: There should be some more information about how this MESSAGE is associated with the handshake example. The dump in Section 3.1 is slightly confusing in that example.com and example.net both resolved to the same address, so reverse lookup shows both domains as example.com. 6. Additional Test Scenarios OPEN ISSUE: From first bullet, "peer's URI"...What URI? An AoR for the user? From or To values? Contacts? Request-URIs? For request URIs, do we need to discuss the effects of retargeting? Do we need to consider some of the current History-Info discussions? OPEN ISSUE: From second bullet: What if all you've got is an IP address? Do we disallow IPAddress entries in subjectAltName? IP addresses can appear in the subjectAltName (rfc5280 says so.) Their handling is specified in domain-certs (I believe they will appear as "DNS:192.168.0.1"; we need to have someone -- from pkix? -- ascertain this. If this is the case, then their handling is specified in S7.1 of domain-certs. OPEN ISSUE: First sub-bullet (Wildcard matching is not allowed against these dNSName entries): Is there something that can be referenced here? In particular, RFC2818 explicitly allows wildcards in dNSName entries. It is not obvious to me whether the proscription against wildcards in RFC4474 should apply to general use of TLS, or just to identity. OPEN ISSUE: Should we have at least one case for SIP EKU? Appendix A. Making Test Certificates OPEN ISSUE: The information in this section needs to be verified with the latest software versions. How to do conversions between supported types needs to be updated accordingly. Any Windows users out there want to volunteer for verify the Windows side of these? Appendix B. Certificates for Testing OPEN ISSUE: Should we discuss certificate chains? We aren't really trying to be a tutorial. Would it be helpful to add a non-root CA and hosts signed by that non-root CA to help with testing events? We do imply non-root CAs in Section 6. Appendix C. Message Dumps OPEN ISSUE: All of this binary bit-exact stuff needs to be verified by other than myself. I'm looking into ways to make this easier for someone else to review and verify. Any code I make available will be OpenSSL-centric. -BCH ===== TODOs ===== These are mainly issues I need to fix in the binary-generated content. 2.2. Host Certificates TODO: Fix subjectAltName DNS:com to DNS:example.com and DNS:net to DNS:example.net. 3.2. MESSAGE Message Over TLS TODO: Actually use the allOneLine convention. This will be fixed in a change to binary-generated content. TODO: Remove the Contact headers. 4.1. MESSAGE Message with Signed Body TODO: For generated-content, change "hello" to "Hello!" to be consistent. TODO: Actually use the allOneLine convention. This will be fixed in a change to binary-generated content. 4.2. MESSAGE Message with Encrypted Body TODO: For generated-content, change "hello" to "Hello!" to be consistent. TODO: Actually use the allOneLine convention. This will be fixed in a change to binary-generated content. 4.3. MESSAGE Message with Encrypted and Signed Body TODO: Actually use the allOneLine convention. This will be fixed in a change to binary-generated content. From drage@alcatel-lucent.com Fri Jan 22 15:16:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8F83A67AB for ; Fri, 22 Jan 2010 15:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBzhEQG7hlTj for ; Fri, 22 Jan 2010 15:16:36 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id EB2D03A67F7 for ; Fri, 22 Jan 2010 15:16:35 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o0MNGO8R003139 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 23 Jan 2010 00:16:25 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sat, 23 Jan 2010 00:16:24 +0100 From: "DRAGE, Keith (Keith)" To: Robert Sparks Date: Sat, 23 Jan 2010 00:16:24 +0100 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 Thread-Index: AcqarkxW+7xWkoYjRvSCqIlUZaDHDwA7To4A Message-ID: References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> , <0309D74A-996B-49C1-B6CE-620459683C75@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 23:16:37 -0000 Would you like to clarify exactly how tou get your interpretation from the = RFC 5226 text. For example the bits about interoperability certainly imply to me that the = expert has to a much more extensive review than what was intended. In other words, act as the expert would when presented with an info package= definition, and tell me what you would look at using the RFC 5226 definiti= on, what tests you would apply and so on. regards Keith=20 > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Thursday, January 21, 2010 3:28 PM > To: DRAGE, Keith (Keith) > Cc: Christer Holmberg; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > Subject: Re: [sipcore] Draft new version:=20 > draft-ietf-sipcore-info-events-05 >=20 > I think what its trying to say is exactly what 5226 says in=20 > its definition of Specification Required and that we run the=20 > risk of introducing ambiguity and confusion by trying to=20 > duplicate what's said there. >=20 > I don't think we're trying to modify that definition and that=20 > the pressure you're trying to put on it would be clarifying=20 > pressure. There might be better text that could do that=20 > without introducing ambiguity, but we've noted the current=20 > text isn't it. My proposed alternate text is the empty string. >=20 > If we _are_ trying to modify that definition, then we need=20 > quite a bit of different, and very explicit, text. >=20 > RjS >=20 > On Jan 21, 2010, at 5:47 AM, DRAGE, Keith (Keith) wrote: >=20 > > I do not want to remove the text - and Dean has explained=20 > exactly why=20 > > in better words than I can. > > > > I am happy to look at rewordings, but we have had too many=20 > instances=20 > > where expert review has gone into considerable detail, and that we=20 > > have consensus on is not meant here. > > > > Keith > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > >> Sent: Wednesday, January 20, 2010 5:50 PM > >> To: Robert Sparks > >> Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > >> Subject: Re: [sipcore] Draft new version: > >> draft-ietf-sipcore-info-events-05 > >> > >> Hi, > >> > >> Earlier we had a rather lenghty discussion about this, I=20 > believe all=20 > >> text was presented on the list before added to the draft,=20 > and nobody=20 > >> objected... > >> > >> Anyway, does anyone object if I now remove the text? > >> > >> Regards, > >> > >> Christer > >> > >> ________________________________________ > >> From: Robert Sparks [rjsparks@nostrum.com] > >> Sent: Wednesday, January 20, 2010 8:56 AM > >> To: Christer Holmberg > >> Cc: Dean Willis; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > >> Subject: Re: [sipcore] Draft new version: > >> draft-ietf-sipcore-info-events-05 > >> > >> I don't think we need to keep the text - that's already what=20 > >> Specification Required says. > >> > >> RjS > >> > >> On Jan 20, 2010, at 12:39 AM, Christer Holmberg wrote: > >> > >>> > >>> Hi, > >>> > >>> A possible comprimise would be to keep the text, but make=20 > it into a=20 > >>> note. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>>> -----Original Message----- > >>>> From: sipcore-bounces@ietf.org > >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > >>>> Sent: 20. tammikuuta 2010 8:39 > >>>> To: Dean Willis; Robert Sparks > >>>> Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > >>>> Subject: Re: [sipcore] Draft new version: > >>>> draft-ietf-sipcore-info-events-05 > >>>> > >>>> > >>>> Hi Dean, > >>>> > >>>> So, you want to keep the text? > >>>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>>> -----Original Message----- > >>>>> From: Dean Willis [mailto:dean.willis@softarmor.com] > >>>>> Sent: 20. tammikuuta 2010 8:00 > >>>>> To: Robert Sparks > >>>>> Cc: Christer Holmberg; SIPCORE; Gonzalo Camarillo;=20 > Hadriel Kaplan > >>>>> Subject: Re: [sipcore] Draft new version: > >>>>> draft-ietf-sipcore-info-events-05 > >>>>> > >>>>> > >>>>> On Jan 19, 2010, at 3:35 PM, Robert Sparks wrote: > >>>>> > >>>>>> I would also have removed > >>>>>> " The reviewer does not consider the applicability of the > >>>>> Info Package > >>>>>> The reviewer does not consider the applicability of the > >>>>> Info Package > >>>>>> for the usage for which it is defined." > >>>>> > >>>>> While the language is broken, the intent is that the > >>>> reviewer not say > >>>>> "This is a silly thing to do with an INFO package. > >>>>> Why, we should be doing this with SOAP (or insert your favorite > >>>>> modality) instead." As a group, we tend to review SIP=20 > extensions=20 > >>>>> through something of a religious lens, to say "But that > >> usage isn't > >>>>> the intent of SIP; SIP is only for (insert favorite=20 > thing here)!" > >>>>> > >>>>> The goals of an INFO package reviewer should be to be to > >> 1) verify > >>>>> that the document exists and actually specifies an INFO > >>>> package, not > >>>>> something completely different (like say, a recipe for > >>>> cheese dip), 2) > >>>>> verify that the INFO package name is unique, and 3) confirm > >>>> that the > >>>>> INFO package is not trying to sneak modifications of the > >> SIP State > >>>>> machine into the specification family; there MUST be no=20 > normative=20 > >>>>> language that alters the SIP state machine functionality. > >>>>> > >>>>> > >>>>> If somebody wants "INFO for lightbulbs", that's OK. If=20 > they want=20 > >>>>> "INFO for remote procedure calls", that's OK too. > >>>>> Neither may be a particularly smart usage of SIP, but=20 > they don't=20 > >>>>> break the SIP protocol, and that's all the reviewer should care=20 > >>>>> about. > >>>>> > >>>>> -- > >>>>> Dean > >>>>> > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> >=20 > = From dean.willis@softarmor.com Fri Jan 22 20:46:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A703A6833 for ; Fri, 22 Jan 2010 20:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjvCZW-qauMU for ; Fri, 22 Jan 2010 20:46:20 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 32E773A67B7 for ; Fri, 22 Jan 2010 20:46:20 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0N4k8a3011662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2010 22:46:10 -0600 Message-Id: <08099603-E986-4628-98E0-89C3B39CFE1E@softarmor.com> From: Dean Willis To: Robert Sparks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Jan 2010 22:46:03 -0600 References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> , <0309D74A-996B-49C1-B6CE-620459683C75@nostrum.com> <6E2E1A30-72B6-4B8A-8EDA-51AFBF447588@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 04:46:21 -0000 On Jan 22, 2010, at 12:24 PM, Robert Sparks wrote: > I'd be ok with that text. > > Just to make sure we're explicit, do you think this absolves the > reviewer of making sure the > specification meets the requirements that this new RFC would put on > any new package? > We had a long conversation essentially about whether a blank, but > stable, document satisfied > specification required. I want to make sure we don't regress and > lose where that conversation > ended. I'd say that the reviewer should look at the specification and at least see that it is attempting to specify an INFO package. This is arguably slightly below the bar set by 5226, which I think requires a reviewer to decide that the specification is good enough that it could be implemented with some hope of interoperability. I'm still pondering whether we should have just said "first come first served". I'd be willing to accept even the "bar set by 5226", as long as the reviewer does not get to determine whether the INFO package is specifying "something that is reasonable to do with SIP". I don't care whether the intent is "reasonable" or not; if there's a legible specification, we register the info package. If somebody really wants to reimplement BitTorrent in INFO and publishes a spec that shows how to do it, we register that INFO package without complaint about it being a really stupid thing to do with SIP. We need to get out of the position of being the stupidity police for the users of our protocol. If they want to shoot themselves, so be it; we're here to keep them from shooting each other accidentally by using the same package name. -- Dean From christer.holmberg@ericsson.com Mon Jan 25 02:44:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1423A685A for ; Mon, 25 Jan 2010 02:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7Rsnnz4i-p8 for ; Mon, 25 Jan 2010 02:44:39 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9A3BD3A683B for ; Mon, 25 Jan 2010 02:44:39 -0800 (PST) X-AuditID: c1b4fb24-b7c57ae000002bb1-1d-4b5d761bf22f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 6F.26.11185.B167D5B4; Mon, 25 Jan 2010 11:44:44 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 25 Jan 2010 11:44:43 +0100 From: Christer Holmberg To: Dean Willis , Robert Sparks Date: Mon, 25 Jan 2010 11:44:42 +0100 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 Thread-Index: Acqb5wHKmtdRmgYOTSCwKaGM3KZ3xwBxFSxw Message-ID: References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> , <0309D74A-996B-49C1-B6CE-620459683C75@nostrum.com> <6E2E1A30-72B6-4B8A-8EDA-51AFBF447588@softarmor.com> <08099603-E986-4628-98E0-89C3B39CFE1E@softarmor.com> In-Reply-To: <08099603-E986-4628-98E0-89C3B39CFE1E@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 10:44:40 -0000 Hi, Could you please show how the whole section would look like? Thanks! Christer=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis > Sent: 23. tammikuuta 2010 6:46 > To: Robert Sparks > Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > Subject: Re: [sipcore] Draft new version:=20 > draft-ietf-sipcore-info-events-05 >=20 >=20 > On Jan 22, 2010, at 12:24 PM, Robert Sparks wrote: >=20 > > I'd be ok with that text. > > > > Just to make sure we're explicit, do you think this absolves the=20 > > reviewer of making sure the specification meets the=20 > requirements that=20 > > this new RFC would put on any new package? > > We had a long conversation essentially about whether a blank, but=20 > > stable, document satisfied specification required. I want=20 > to make sure=20 > > we don't regress and lose where that conversation ended. >=20 > I'd say that the reviewer should look at the specification=20 > and at least see that it is attempting to specify an INFO=20 > package. This is arguably slightly below the bar set by 5226,=20 > which I think requires a reviewer to decide that the=20 > specification is good enough that it could be implemented=20 > with some hope of interoperability. I'm still pondering=20 > whether we should have just said "first come first served". >=20 > I'd be willing to accept even the "bar set by 5226", as=20 > long as the reviewer does not get to determine whether the=20 > INFO package is specifying "something that is reasonable to=20 > do with SIP". I don't care whether the intent is "reasonable"=20 > or not; if there's a legible specification, we register the=20 > info package. If somebody really wants to reimplement=20 > BitTorrent in INFO and publishes a spec that shows how to do=20 > it, we register that INFO package without complaint about it=20 > being a really stupid thing to do with SIP. We need to get=20 > out of the position of being the stupidity police for the=20 > users of our protocol. =20 > If they want to shoot themselves, so be it; we're here to=20 > keep them from shooting each other accidentally by using the=20 > same package name. >=20 > -- > Dean > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Tue Jan 26 00:50:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB08D3A693D for ; Tue, 26 Jan 2010 00:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpFxpI1xIC1X for ; Tue, 26 Jan 2010 00:50:28 -0800 (PST) Received: from mailgw9.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E86B83A6837 for ; Tue, 26 Jan 2010 00:50:27 -0800 (PST) X-AuditID: c1b4fb24-b7bbdae00000494b-be-4b5eacdb20e8 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.ericsson.se (Symantec Mail Security) with SMTP id D0.72.18763.BDCAE5B4; Tue, 26 Jan 2010 09:50:36 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 26 Jan 2010 09:50:35 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Tue, 26 Jan 2010 09:50:35 +0100 From: Christer Holmberg To: Christer Holmberg , Dean Willis , Robert Sparks Date: Tue, 26 Jan 2010 09:50:34 +0100 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 Thread-Index: Acqb5wHKmtdRmgYOTSCwKaGM3KZ3xwBxFSxwAC4sCcA= Message-ID: References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> , <0309D74A-996B-49C1-B6CE-620459683C75@nostrum.com> <6E2E1A30-72B6-4B8A-8EDA-51AFBF447588@softarmor.com> <08099603-E986-4628-98E0-89C3B39CFE1E@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 08:50:30 -0000 Are people ok with the following text? ---------------- Please create a subregistry in the SIP Parameters registry for Info Packages. Note to Reviewers: The policy for review of Info Packages is "Specification Required", as defined in [RFC5226]. This policy was selected because INFO packages re-= use=20 an existing mechanism for transport of arbitrary session- associated=20 data within SIP, and therefore new INFO packages do not require the=20 more extensive review required by specifications that make fundamental=20 protocol changes. However, the reviewer is expected to verify that=20 each INFO package registration is in fact consistent with this=20 definition. Changes to the SIP protocol and state machine are outside=20 of the allowable scope for an INFO package and are governed by other =20 procedures including [RFC3427] and its successors, if any. The following data elements populate the Info Package Registry. o Info Package Name: The Info Package Name is a case insensitive token. In addition, IANA shall not register multiple Info Package names that have identical case-insensitive values. o Reference: A reference to a specification which describes the Info Package. The initial population of this table shall be: Name Reference ------------------- Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 25. tammikuuta 2010 12:45 > To: Dean Willis; Robert Sparks > Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > Subject: Re: [sipcore] Draft new version:=20 > draft-ietf-sipcore-info-events-05 >=20 >=20 > Hi, >=20 > Could you please show how the whole section would look like? >=20 > Thanks! >=20 > Christer=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis > > Sent: 23. tammikuuta 2010 6:46 > > To: Robert Sparks > > Cc: SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > > Subject: Re: [sipcore] Draft new version:=20 > > draft-ietf-sipcore-info-events-05 > >=20 > >=20 > > On Jan 22, 2010, at 12:24 PM, Robert Sparks wrote: > >=20 > > > I'd be ok with that text. > > > > > > Just to make sure we're explicit, do you think this absolves the=20 > > > reviewer of making sure the specification meets the > > requirements that > > > this new RFC would put on any new package? > > > We had a long conversation essentially about whether a blank, but=20 > > > stable, document satisfied specification required. I want > > to make sure > > > we don't regress and lose where that conversation ended. > >=20 > > I'd say that the reviewer should look at the specification and at=20 > > least see that it is attempting to specify an INFO package. This is=20 > > arguably slightly below the bar set by 5226, which I think=20 > requires a=20 > > reviewer to decide that the specification is good enough=20 > that it could=20 > > be implemented with some hope of interoperability. I'm=20 > still pondering=20 > > whether we should have just said "first come first served". > >=20 > > I'd be willing to accept even the "bar set by 5226", as=20 > long as the=20 > > reviewer does not get to determine whether the INFO package is=20 > > specifying "something that is reasonable to do with SIP". I=20 > don't care=20 > > whether the intent is "reasonable" > > or not; if there's a legible specification, we register the info=20 > > package. If somebody really wants to reimplement BitTorrent in INFO=20 > > and publishes a spec that shows how to do it, we register that INFO=20 > > package without complaint about it being a really stupid=20 > thing to do=20 > > with SIP. We need to get out of the position of being the stupidity=20 > > police for the users of our protocol. > > If they want to shoot themselves, so be it; we're here to keep them=20 > > from shooting each other accidentally by using the same=20 > package name. > >=20 > > -- > > Dean > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From dean.willis@softarmor.com Tue Jan 26 10:02:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBAC43A67E7 for ; Tue, 26 Jan 2010 10:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvVM6aKSEjJU for ; Tue, 26 Jan 2010 10:02:31 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E277728B56A for ; Tue, 26 Jan 2010 10:02:30 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0QI2Zbh018538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jan 2010 12:02:37 -0600 Message-Id: From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jan 2010 12:02:30 -0600 References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> , <0309D74A-996B-49C1-B6CE-620459683C75@nostrum.com> <6E2E1A30-72B6-4B8A-8EDA-51AFBF447588@softarmor.com> <08099603-E986-4628-98E0-89C3B39CFE1E@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE , Gonzalo Camarillo , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 18:02:32 -0000 On Jan 26, 2010, at 2:50 AM, Christer Holmberg wrote: > > Are people ok with the following text? Works for me. -- Dean From jmpolk@cisco.com Tue Jan 26 15:42:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250F63A6860 for ; Tue, 26 Jan 2010 15:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoURDbu0RDBI for ; Tue, 26 Jan 2010 15:42:25 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4513B3A6407 for ; Tue, 26 Jan 2010 15:42:25 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFANMMX0urR7Ht/2dsb2JhbACGZ7wBlyeENwQ X-IronPort-AV: E=Sophos;i="4.49,348,1262563200"; d="scan'208";a="140457475" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 26 Jan 2010 23:42:37 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0QNgbWe014780 for ; Tue, 26 Jan 2010 23:42:37 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 15:42:36 -0800 Received: from jmpolk-wxp01.cisco.com ([10.99.80.18]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 15:42:36 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Jan 2010 17:42:48 -0600 To: sipcore@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 26 Jan 2010 23:42:36.0908 (UTC) FILETIME=[3D704AC0:01CA9EE1] Subject: [sipcore] BNF for Geolocation Header proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 23:42:26 -0000 I thought I'd run this by the WG before finalizing the next rev of Location Conveyance. I pretty sure I've solved the BNF issue in relation to RFC 5606 (retransmission of SIP location conveyance). Does anyone have any heartburn with this: Geolocation = "Geolocation" HCOLON (locationValue *(COMMA locationValue)) (COMMA retrans-param) locationValue = LAQUOT locationURI RAQUOT SEMI inserted-param *(SEMI geoloc-param) locationURI = sip-URI / sips-URI / pres-URI / cid-url ; (from RFC 2392) / absoluteURI ; (from RFC 3261) inserted-param = "inserted-by" EQUAL geoloc-inserter geoloc-inserter = DQUOTE hostport DQUOTE / gen-value ; (from RFC 3261) geoloc-param = "used-for-routing" / generic-param ; (from RFC 3261) retrans-param = "routing-allowed" EQUAL "yes" / "no" The nut of the change is to create the retrans-param, and make it COMMA separated from any locationValue in the header. This is because the routing-allowed parameter can exist in the Geolocation header value without a locationValue - i.e., when there's no location indicated within this SIP request, but there is a policy statement about whether this UAC wants its location - potentially inserted by a SIP server - to be allowed to retransmitted to a third party (i.e., to someone/entity not in the SIP signaling path) by any other in-path entity. The routing-allowed parameter was moved from the geoloc-param portion of the BNF. An agreement was reached by many (based on 5606) that since there should be only one of these parameters - regardless of how many locationValues there are in the header - thus making the parameter globally applicable. Moving this to the top line seemed best (i.e., there can be only one instance of it), instead of parsing though each locationValue -- potentially with competing routing-allowed values when there is more than one locationValue in the header value. I'm updating the text now to reflect all of this. Let me know if this is broken somehow. James From christer.holmberg@ericsson.com Wed Jan 27 00:00:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7B03A67E1 for ; Wed, 27 Jan 2010 00:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfshqdanXfBC for ; Wed, 27 Jan 2010 00:00:43 -0800 (PST) Received: from mailgw-virt-test.ericsson.se (mailgw-virt-test.ericsson.se [193.180.251.35]) by core3.amsl.com (Postfix) with ESMTP id 7BFB43A67D8 for ; Wed, 27 Jan 2010 00:00:43 -0800 (PST) X-AuditID: c1b4fb23-b7b3fae00000170d-f5-4b5ff2b741e6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw-virt-test.ericsson.se (Symantec Brightmail Gateway) with SMTP id BE.22.05901.7B2FF5B4; Wed, 27 Jan 2010 09:00:55 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 27 Jan 2010 09:00:54 +0100 From: Christer Holmberg To: Dean Willis Date: Wed, 27 Jan 2010 09:00:52 +0100 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 Thread-Index: AcqescE0ehywBglBTl+fmQQIqjuAAQAdP1BQ Message-ID: References: <4601CD43-5FCC-4FBC-AB6F-02FE2C3E8E97@nostrum.com> , <0309D74A-996B-49C1-B6CE-620459683C75@nostrum.com> <6E2E1A30-72B6-4B8A-8EDA-51AFBF447588@softarmor.com> <08099603-E986-4628-98E0-89C3B39CFE1E@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Hadriel Kaplan , SIPCORE , Gonzalo, Camarillo Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 08:00:44 -0000 Hi, Ok, I will submit a new version later today. It will also contain some spel= ling error corrections that I have been informed about, but otherwise there= will be no other changes. Regards, Christer=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 26. tammikuuta 2010 20:03 > To: Christer Holmberg > Cc: Robert Sparks; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan > Subject: Re: [sipcore] Draft new version:=20 > draft-ietf-sipcore-info-events-05 >=20 >=20 > On Jan 26, 2010, at 2:50 AM, Christer Holmberg wrote: >=20 > > > > Are people ok with the following text? >=20 > Works for me. >=20 > -- > Dean > = From gonzalo.camarillo@ericsson.com Wed Jan 27 00:16:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B0A3A63D3 for ; Wed, 27 Jan 2010 00:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.789 X-Spam-Level: X-Spam-Status: No, score=-105.789 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ7y-Tk65WwP for ; Wed, 27 Jan 2010 00:16:00 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C15C03A68FC for ; Wed, 27 Jan 2010 00:15:59 -0800 (PST) X-AuditID: c1b4fb24-b7c64ae000005cb7-f7-4b5ff64bf729 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id EE.F0.23735.B46FF5B4; Wed, 27 Jan 2010 09:16:11 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 09:16:10 +0100 Received: from [131.160.126.209] ([131.160.126.209]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 09:16:10 +0100 Message-ID: <4B5FF648.5090302@ericsson.com> Date: Wed, 27 Jan 2010 10:16:08 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: , <0309D74A-996B-49C1-B6CE-620459683C75@nostrum.com> <6E2E1A30-72B6-4B8A-8EDA-51AFBF447588@softarmor.com> <08099603-E986-4628-98E0-89C3B39CFE1E@softarmor.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jan 2010 08:16:10.0730 (UTC) FILETIME=[FBE864A0:01CA9F28] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 08:16:01 -0000 Hi Christer, please, make sure the ID nits tool does not complain about the new version... the idea is to be able to request its publication. Thanks, Gonzalo Christer Holmberg wrote: > Hi, > > Ok, I will submit a new version later today. It will also contain some spelling error corrections that I have been informed about, but otherwise there will be no other changes. > > Regards, > > Christer > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: 26. tammikuuta 2010 20:03 >> To: Christer Holmberg >> Cc: Robert Sparks; SIPCORE; Gonzalo Camarillo; Hadriel Kaplan >> Subject: Re: [sipcore] Draft new version: >> draft-ietf-sipcore-info-events-05 >> >> >> On Jan 26, 2010, at 2:50 AM, Christer Holmberg wrote: >> >>> Are people ok with the following text? >> Works for me. >> >> -- >> Dean From jbemmel@zonnet.nl Wed Jan 27 04:37:36 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C094C3A6A75 for ; Wed, 27 Jan 2010 04:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh2A197dy2DA for ; Wed, 27 Jan 2010 04:37:33 -0800 (PST) Received: from smtp3.versatel.nl (smtp4.versatel.nl [62.58.50.91]) by core3.amsl.com (Postfix) with ESMTP id 904EE3A6855 for ; Wed, 27 Jan 2010 04:37:31 -0800 (PST) Received: (qmail 13852 invoked by uid 0); 27 Jan 2010 12:37:43 -0000 Received: from bewww05.admin.zonnet.nl (HELO webmail6.zonnet.nl) ([10.170.1.69]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 27 Jan 2010 12:37:43 -0000 Received: by webmail6.zonnet.nl (Postfix, from userid 33) id 92604121E; Wed, 27 Jan 2010 14:38:17 +0100 (CET) Received: from ip160-34-212-87.adsl2.static.versatel.nl (ip160-34-212-87.adsl2.static.versatel.nl [87.212.34.160]) by webmail.versatel.nl (Horde MIME library) with HTTP; Wed, 27 Jan 2010 14:38:17 +0100 Message-ID: <20100127143817.9neiwmoilrr440g0@webmail.versatel.nl> Date: Wed, 27 Jan 2010 14:38:17 +0100 From: jbemmel@zonnet.nl To: "James M. Polk" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) Cc: sipcore@ietf.org Subject: Re: [sipcore] BNF for Geolocation Header proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 12:37:36 -0000 Hi James, This BNF doesn't allow for the case you describe, i.e. a "routing-allowed" param without location value. Suggestion: Geolocation = "Geolocation" HCOLON value *(COMMA value) value = locationValue | retrans-param and then in text describe that there may be at most 1 instance of retrans-param ( instead of "enforcing" this via BNF). Has been done before, ref. e.g. RFC3323 for the "Privacy" header Regards, Jeroen Citeren "James M. Polk" : > I thought I'd run this by the WG before finalizing the next rev of > Location Conveyance. I pretty sure I've solved the BNF issue in > relation to RFC 5606 (retransmission of SIP location conveyance). > Does anyone have any heartburn with this: > > Geolocation = "Geolocation" HCOLON (locationValue *(COMMA > locationValue)) (COMMA retrans-param) > locationValue = LAQUOT locationURI RAQUOT SEMI inserted-param > *(SEMI geoloc-param) > locationURI = sip-URI / sips-URI / pres-URI > / cid-url ; (from RFC 2392) > / absoluteURI ; (from RFC 3261) > inserted-param = "inserted-by" EQUAL geoloc-inserter > geoloc-inserter = DQUOTE hostport DQUOTE > / gen-value ; (from RFC 3261) > geoloc-param = "used-for-routing" / generic-param ; > (from RFC 3261) > retrans-param = "routing-allowed" EQUAL "yes" / "no" > > The nut of the change is to create the retrans-param, and make it > COMMA separated from any locationValue in the header. This is > because the routing-allowed parameter can exist in the Geolocation > header value without a locationValue - i.e., when there's no location > indicated within this SIP request, but there is a policy statement > about whether this UAC wants its location - potentially inserted by a > SIP server - to be allowed to retransmitted to a third party (i.e., > to someone/entity not in the SIP signaling path) by any other in-path > entity. > > The routing-allowed parameter was moved from the geoloc-param portion > of the BNF. > > An agreement was reached by many (based on 5606) that since there > should be only one of these parameters - regardless of how many > locationValues there are in the header - thus making the parameter > globally applicable. Moving this to the top line seemed best (i.e., > there can be only one instance of it), instead of parsing though each > locationValue -- potentially with competing routing-allowed values > when there is more than one locationValue in the header value. > > I'm updating the text now to reflect all of this. > > Let me know if this is broken somehow. > > James > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Wed Jan 27 06:26:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CCF43A6960 for ; Wed, 27 Jan 2010 06:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFl3nEYtgO-M for ; Wed, 27 Jan 2010 06:26:24 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4C0B33A6A5D for ; Wed, 27 Jan 2010 06:26:24 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMbbX0urR7Hu/2dsb2JhbADARZcUhDgE X-IronPort-AV: E=Sophos;i="4.49,353,1262563200"; d="scan'208";a="473641620" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 27 Jan 2010 14:26:38 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0REQckM029730 for ; Wed, 27 Jan 2010 14:26:38 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 08:26:38 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 08:26:38 -0600 Message-ID: <4B604D1D.2060602@cisco.com> Date: Wed, 27 Jan 2010 09:26:37 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "James M. Polk" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jan 2010 14:26:38.0239 (UTC) FILETIME=[BC891AF0:01CA9F5C] Cc: sipcore@ietf.org Subject: Re: [sipcore] BNF for Geolocation Header proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 14:26:25 -0000 I do see a problem with this. More inline. Regards, Paul James M. Polk wrote: > I thought I'd run this by the WG before finalizing the next rev of > Location Conveyance. I pretty sure I've solved the BNF issue in > relation to RFC 5606 (retransmission of SIP location conveyance). Does > anyone have any heartburn with this: > > Geolocation = "Geolocation" HCOLON (locationValue *(COMMA > locationValue)) (COMMA retrans-param) > locationValue = LAQUOT locationURI RAQUOT SEMI inserted-param > *(SEMI geoloc-param) > locationURI = sip-URI / sips-URI / pres-URI > / cid-url ; (from RFC 2392) > / absoluteURI ; (from RFC 3261) > inserted-param = "inserted-by" EQUAL geoloc-inserter > geoloc-inserter = DQUOTE hostport DQUOTE > / gen-value ; (from RFC 3261) > geoloc-param = "used-for-routing" / generic-param ; > (from RFC 3261) > retrans-param = "routing-allowed" EQUAL "yes" / "no" > > The nut of the change is to create the retrans-param, and make it COMMA > separated from any locationValue in the header. This is because the > routing-allowed parameter can exist in the Geolocation header value > without a locationValue - i.e., when there's no location indicated > within this SIP request, but there is a policy statement about whether > this UAC wants its location - potentially inserted by a SIP server - to > be allowed to retransmitted to a third party (i.e., to someone/entity > not in the SIP signaling path) by any other in-path entity. > > The routing-allowed parameter was moved from the geoloc-param portion of > the BNF. Section 7.3.1 of 3261 includes: Multiple header field rows with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list (that is, if follows the grammar defined in Section 7.3). It MUST be possible to combine the multiple header field rows into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy- Authenticate, and Proxy-Authorization header fields. Multiple header field rows with these names MAY be present in a message, but since their grammar does not follow the general form listed in Section 7.3, they MUST NOT be combined into a single header field row. The references format in 7.3 is: header = "header-name" HCOLON header-value *(COMMA header-value) Your syntax is in violation of this rule. Even ignoring the restriction in 3261, there are real implementation difficulties with what you have written. Most notably, suppose there are two instances of the header in a message: Geolocation: ;inserted-by="example.com", routing-allowed=yes ... Geolocation: ;inserted-by="example.org", routing-allowed=no That would seem to be allowed by your syntax, but makes no sense. A straightforward way to deal with this would be to create a distinct header for this value, separate from the Geolocation header. Another way would be: Geolocation = "Geolocation" HCOLON locationArg *(COMMA locationArg) locationArg = locationValue / retrans-param And then just supply text that says retrans-param may appear at most once in a message. (I think a separate header is cleaner.) > An agreement was reached by many (based on 5606) that since there should > be only one of these parameters - regardless of how many locationValues > there are in the header - thus making the parameter globally applicable. > Moving this to the top line seemed best (i.e., there can be only one > instance of it), instead of parsing though each locationValue -- > potentially with competing routing-allowed values when there is more > than one locationValue in the header value. > > I'm updating the text now to reflect all of this. > > Let me know if this is broken somehow. > > James > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From wwwrun@core3.amsl.com Wed Jan 27 09:05:25 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 634903A6AB2; Wed, 27 Jan 2010 09:05:25 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100127170525.634903A6AB2@core3.amsl.com> Date: Wed, 27 Jan 2010 09:05:25 -0800 (PST) Cc: sipcore chair , Internet Architecture Board , sipcore mailing list , RFC Editor Subject: [sipcore] Protocol Action: 'An Extension to Session Initiation Protocol X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 17:05:25 -0000 (SIP) Events for Conditional Event Notification' to Proposed Standard The IESG has approved the following document: - 'An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification ' as a Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Robert Sparks and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-subnot-etags-04.txt Technical Summary The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These SIP Events Framework procedures have a serious deficiency in that they provide no tools to avoid replaying event notifications that have already been received by a user agent. This specification defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. This "conditioning" of the subscription requests uses the well-known concept of entity tags (eTags). Working Group Summary This document received extended working group review during a SIP WGLC period that exceeded one year in duration. One critical clarification came up in this review period: this specification does not provide "versioning history" for events; rather it lets a subscriber know whether the current event state is consistent with the event state as currently known by that subscriber. The distinction is subtle. For example, if the subscriber knows of event state "A", but the actual state has changed to "B" and then back to "A" before a NOTIFY would be sent (if the subscriber were offline for example), the subscriber will not be informed about the B state through this specification. Following WGLC, the proto review process detected and corrected a minor error in the ABNF, and further review by Adam Roach detected and corrected problem related to suppressed NOTIFYs on initial dialogs. Document Quality The Open Mobile Alliance SIMPLE Presence specification references this document, and has done so for several years. Personnel Dean Willis is this document's shepherd. Robert Sparks is the responsible AD. From jmpolk@cisco.com Wed Jan 27 09:21:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B4228C142 for ; Wed, 27 Jan 2010 09:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6Cl13GdhU9m for ; Wed, 27 Jan 2010 09:21:42 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4DDC13A6AB2 for ; Wed, 27 Jan 2010 09:21:42 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsFAMoEYEurR7Ht/2dsb2JhbACGVbwBlxqEOQQ X-IronPort-AV: E=Sophos;i="4.49,355,1262563200"; d="scan'208";a="473734860" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 27 Jan 2010 17:21:57 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0RHLvZR005979; Wed, 27 Jan 2010 17:21:57 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 09:21:57 -0800 Received: from jmpolk-wxp01.cisco.com ([10.99.80.18]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 09:21:56 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Jan 2010 11:21:54 -0600 To: jbemmel@zonnet.nl From: "James M. Polk" In-Reply-To: <20100127143817.9neiwmoilrr440g0@webmail.versatel.nl> References: <20100127143817.9neiwmoilrr440g0@webmail.versatel.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 27 Jan 2010 17:21:56.0794 (UTC) FILETIME=[3A1539A0:01CA9F75] Cc: sipcore@ietf.org Subject: Re: [sipcore] BNF for Geolocation Header proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 17:21:44 -0000 At 07:38 AM 1/27/2010, jbemmel@zonnet.nl wrote: >Hi James, > >This BNF doesn't allow for the case you describe, i.e. a >"routing-allowed" param without location value. > >Suggestion: >Geolocation = "Geolocation" HCOLON value *(COMMA value) >value = locationValue | retrans-param I think the (*COMMA value) means there can be more than one of these values in the header. We only want one retrans-param in all of the header (to prevent conflicting indications by this parameter). So is this really the right way to do this? (i.e., it appears to be inconsistent) James >and then in text describe that there may be at most 1 instance of >retrans-param ( instead of "enforcing" this via BNF). Has been done >before, ref. e.g. RFC3323 for the "Privacy" header > >Regards, >Jeroen > >Citeren "James M. Polk" : > >>I thought I'd run this by the WG before finalizing the next rev of >>Location Conveyance. I pretty sure I've solved the BNF issue in >>relation to RFC 5606 (retransmission of SIP location conveyance). >>Does anyone have any heartburn with this: >> >> Geolocation = "Geolocation" HCOLON (locationValue *(COMMA >> locationValue)) (COMMA retrans-param) >> locationValue = LAQUOT locationURI RAQUOT SEMI inserted-param >> *(SEMI geoloc-param) >> locationURI = sip-URI / sips-URI / pres-URI >> / cid-url ; (from RFC 2392) >> / absoluteURI ; (from RFC 3261) >> inserted-param = "inserted-by" EQUAL geoloc-inserter >> geoloc-inserter = DQUOTE hostport DQUOTE >> / gen-value ; (from RFC 3261) >> geoloc-param = "used-for-routing" / generic-param ; >> (from RFC 3261) >> retrans-param = "routing-allowed" EQUAL "yes" / "no" >> >>The nut of the change is to create the retrans-param, and make it >>COMMA separated from any locationValue in the header. This is >>because the routing-allowed parameter can exist in the Geolocation >>header value without a locationValue - i.e., when there's no >>location indicated within this SIP request, but there is a policy >>statement about whether this UAC wants its location - potentially >>inserted by a SIP server - to be allowed to retransmitted to a >>third party (i.e., to someone/entity not in the SIP signaling path) >>by any other in-path entity. >> >>The routing-allowed parameter was moved from the geoloc-param >>portion of the BNF. >> >>An agreement was reached by many (based on 5606) that since there >>should be only one of these parameters - regardless of how many >>locationValues there are in the header - thus making the parameter >>globally applicable. Moving this to the top line seemed best (i.e., >>there can be only one instance of it), instead of parsing though >>each locationValue -- potentially with competing routing-allowed >>values when there is more than one locationValue in the header value. >> >>I'm updating the text now to reflect all of this. >> >>Let me know if this is broken somehow. >> >>James >> >>_______________________________________________ >>sipcore mailing list >>sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore > From fluffy@cisco.com Wed Jan 27 10:00:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32A383A690D for ; Wed, 27 Jan 2010 10:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj7S3QUALmjv for ; Wed, 27 Jan 2010 10:00:32 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 972D13A696B for ; Wed, 27 Jan 2010 10:00:32 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO4NYEurR7H+/2dsb2JhbADCNpcZhDkE X-IronPort-AV: E=Sophos;i="4.49,355,1262563200"; d="scan'208";a="209631808" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 27 Jan 2010 18:00:47 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0RI0kRc007362; Wed, 27 Jan 2010 18:00:47 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <126F4C63-8C3D-4131-8FA4-B8EBC0B7C804@estacado.net> Date: Wed, 27 Jan 2010 11:00:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <85C804CE-610E-42E9-86FD-F8FED9620E29@cisco.com> <126F4C63-8C3D-4131-8FA4-B8EBC0B7C804@estacado.net> To: Brian Hibbard X-Mailer: Apple Mail (2.1077) Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 18:00:33 -0000 On Jan 19, 2010, at 12:16 PM, Brian Hibbard wrote: >=20 >=20 > As for how to check revocation status, you're almost certainly right = about whether we can get agreement. We could refer them to section 3.3 = of RFC 5280 and leave it at that.=20 I think it might be good to add an informative ref to OSCP and SCVP too.=20= From fluffy@cisco.com Wed Jan 27 10:00:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472DE3A690D for ; Wed, 27 Jan 2010 10:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.413 X-Spam-Level: X-Spam-Status: No, score=-110.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbkDsb7NGkbe for ; Wed, 27 Jan 2010 10:00:53 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 69D603A688E for ; Wed, 27 Jan 2010 10:00:53 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO4NYEurR7H+/2dsb2JhbADCNpcZhDkE X-IronPort-AV: E=Sophos;i="4.49,355,1262563200"; d="scan'208";a="209631950" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 27 Jan 2010 18:01:08 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0RI0kRd007362; Wed, 27 Jan 2010 18:01:08 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <01DD632E-C839-4965-BB4E-0F063D0871B0@edvina.net> Date: Wed, 27 Jan 2010 11:01:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <932F6A87-D112-4E9D-913E-9AF518E6891E@cisco.com> References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B210DA9.90501@alcatel-lucent.com> <01DD632E-C839-4965-BB4E-0F063D0871B0@edvina.net> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1077) Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 18:00:54 -0000 On Jan 8, 2010, at 5:36 AM, Olle E. Johansson wrote: >=20 > During the tests we had at SIPit in New Hampshire we discovered that = without an IP address in the certificate, most TLS scenarious with = record-route/route headers pointing to IP addresses would fail. Either = avoiding IP addresses in record-route/route or having IP address for the = server in the cert are working solutions to this issue.=20 >=20 > IP in SAN certs is propably the fast way forward, but also gives a = headache in solutions where you have multiple IP addresses in a = "clustered" environment. It just feels wrong to me to have non-DNS data = like IP address within the cert. You are complete right that what goes in the record route needs to match = what is in the cert. However, it is difficult to get cert signed by a = well known CA that has an IP address in it so the obvious solution is = don't put IP addresses in your record-route. If a particular proxy, say = with a host name of say proxy22, in the example.com domain wants to = record route, the easiest thing to deploy in my opinion is putting = proxy22.example.com in the record route. Or if you are a domain with = only one proxy, you could just put example.com in the record route. In = the simple one proxy case, then all you need is a cert with example.com = and in the more complex case you might want a cert with both example.com = and proxy22.example.com. Hope that makes sense. The other problem with = IPs in certs is when you want to renumber the network or move a machine, = you might need new certs. There is likely some cases where IP in certs = make sense but my opinion is that in most case, using DNS names is = easier.=20 Cullen From fluffy@cisco.com Wed Jan 27 10:01:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4D93A67D3 for ; Wed, 27 Jan 2010 10:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWz1aDYUz8Rz for ; Wed, 27 Jan 2010 10:01:55 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A4AA33A688E for ; Wed, 27 Jan 2010 10:01:55 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKQOYEurRN+J/2dsb2JhbADCMJchhDkE X-IronPort-AV: E=Sophos;i="4.49,355,1262563200"; d="scan'208";a="79856432" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 27 Jan 2010 18:02:10 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0RI29m9008906; Wed, 27 Jan 2010 18:02:10 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4B32DD8F.7050402@softarmor.com> Date: Wed, 27 Jan 2010 11:02:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <47CBDB59-01C6-4DD0-B3BD-A59073BCC2D0@cisco.com> References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B310591.7070808@alcatel-lucent.com> <4B32DD8F.7050402@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 18:01:56 -0000 On Dec 23, 2009, at 8:18 PM, Dean Willis wrote: > Vijay K. Gurbani wrote: >=20 >> Here is a table that contains the number of TLS implementations >> since SIPit 16: >=20 > The adoption rate of TLS peaked a couple of years back, and has been = steadily declining since? That should tell us something important. Like, = maybe nobody can figure out how to implement this stuff, nobody actually = uses it, or nobody runs SIP on a hostile network. Not sure which is the = case, here. >=20 > -- > Dean Dean, I don't buy this argument in the slightest. The prevalence of = something at SIPit has close to nothing to do with the deployment = prevalence or the number of products that support it. Most widely = distributed mainstream SIP products are not taken to SIPit at all = because the value proposition of SIPIit is mostly around helping fix new = things where a vendor does not have significant experience to get them = right without showing a pre release version of a product to your = competitors. For example, the amount of TLS at SIPit exceeds the Video = at SIPit, yet I hardly think you can come to the conclusions that = therefore the video over IP market it really small.=20 Cullen From fluffy@cisco.com Wed Jan 27 10:07:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D893A680F for ; Wed, 27 Jan 2010 10:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.426 X-Spam-Level: X-Spam-Status: No, score=-110.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2nxyELhaYLM for ; Wed, 27 Jan 2010 10:07:12 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id BD7653A67D3 for ; Wed, 27 Jan 2010 10:07:12 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOwOYEurR7Ht/2dsb2JhbADCMZchhDkE X-IronPort-AV: E=Sophos;i="4.49,355,1262563200"; d="scan'208";a="209634929" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 27 Jan 2010 18:07:27 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0RI7Pjv020953; Wed, 27 Jan 2010 18:07:25 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 27 Jan 2010 11:07:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4656101B-A8F8-4EC3-B9D7-D2B01FD824B0@estacado.net> To: Brian Hibbard X-Mailer: Apple Mail (2.1077) Cc: Kumiko Ono , SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: document scope and intent X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 18:07:13 -0000 On Jan 7, 2010, at 3:08 PM, Brian Hibbard wrote: > OK, it seems there is heavy agreement that this SHOULD be = informational and not standards track. Do we have agreement on that? >=20 > Specifically, Cullen, are you OK with that? No problem - this is a chair issue/AD (Robert) issue and glad to do = whatever they want.=20 > Do you want to weigh in on the rationale for normative-strength = statements? >=20 > If there are no remaining objections, I can go ahead and make the = draft informational and remove section 2 and references to RFC 2119. = I'll make sure we have no normative-sounding SHOULDs, MUSTs, et al. Uh, we have all kinds of normative language in RAI Information RFC so = don't water things down such that implementers don't know what to do. = The point of this doc is to help implementers get it right so as long as = the language changes are consistent with helping implementors get it = right. I'm fine with them.=20 >=20 > -b > On Dec 11, 2009, at 8:07 AM, DRAGE, Keith (Keith) wrote: >=20 >> If so, you arbitrarily decided to change it because as far as I know = it was informational during its complete lifetime in the SIP group, and = I remember no discussion in the transfer to SIPCORE that made it = standards track. Certainly my final SIP status slides (and the ones = before and the ones before that ...) also say "Candidate: = Informational". The first version that carries an "intended status" line = is the 1st sipcore version, and this is at variance with the charter = pages. >>=20 >> The last SIP charter pages clearly say: >> Mar 2009 Example security flows to WGLC (Informational) >> Jul 2009 Example security flows to IESG (Informational) >>=20 >> And the SIPCORE charter pages state: >>=20 >> Oct 2009 Example security flows to IESG (Informational) >>=20 >> And from my own perspective this should still be informational. If = you feel there is standards track information in here, then pull it out = and submit it as a separate draft, and then the WG can decide whether = they want to proceed with such a standards track document. >>=20 >> I'd also note to all authors that if you receive private messages of = interest, then at least please let the WG chairs know that you have had = those expressions of interest. If you received any of those messages on = sec-flows during its SIP lifetime, the ex SIP WG chairs certainly have = no evidence of them ever having been received - and that is essential = information to the PROTO writeups. I assume the SIPCORE chairs are now = in the same boat, having no email evidence because a small set of = exchanges in the past on SIP and SIPCORE that anyone is even interested = in this document. >>=20 >> regards >>=20 >> Keith >>=20 >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org >>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Cullen Jennings >>> Sent: Thursday, December 10, 2009 6:14 AM >>> To: Brian Hibbard >>> Cc: SIPCORE; Kumiko Ono >>> Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: >>> document scope and intent >>>=20 >>>=20 >>> On Nov 24, 2009, at 2:25 PM, Brian Hibbard wrote: >>>=20 >>>> The draft states in the first line of the introduction that >>> it is not normative for SIP. That raises the question as to >>> whether this should be on the standards track. Should this be >>> informational or BCP? >>>=20 >>> I think we decided it need to be standards track when we >>> added the normative statements about binary a long time ago. >>> (I note that the "should" should be a "SHOULD". >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 From vkg@alcatel-lucent.com Wed Jan 27 10:22:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738493A6876 for ; Wed, 27 Jan 2010 10:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx-v7mEQjPPv for ; Wed, 27 Jan 2010 10:22:56 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 24F603A681F for ; Wed, 27 Jan 2010 10:22:55 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o0RIN2qd022785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 12:23:04 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o0RIN1YQ020211; Wed, 27 Jan 2010 12:23:02 -0600 (CST) Message-ID: <4B608485.20309@alcatel-lucent.com> Date: Wed, 27 Jan 2010 12:23:01 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cullen Jennings References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B210DA9.90501@alcatel-lucent.com> <01DD632E-C839-4965-BB4E-0F063D0871B0@edvina.net> <932F6A87-D112-4E9D-913E-9AF518E6891E@cisco.com> In-Reply-To: <932F6A87-D112-4E9D-913E-9AF518E6891E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: SIPCORE , "Olle E. Johansson" Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 18:22:57 -0000 Cullen Jennings wrote: > You are complete right that what goes in the record route needs to > match what is in the cert. [...] Cullen: We had extensive discussion on this very topic when we were hashing out domain-certs (remember: we were then referring to "pinning" the request through a particular proxy.) The normative behavior that we agreed on is spelled out in Section 7.5 of domain-certs (see the third paragraph.) Fortunately, the normative behavior in Section 7.5 matches your description. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From oej@edvina.net Wed Jan 27 10:37:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 460B13A68BD for ; Wed, 27 Jan 2010 10:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7eVNh9WsQwt for ; Wed, 27 Jan 2010 10:37:09 -0800 (PST) Received: from smtp5.webway.se (smtp5.webway.se [212.3.14.196]) by core3.amsl.com (Postfix) with ESMTP id 61E683A6927 for ; Wed, 27 Jan 2010 10:37:09 -0800 (PST) Received: from smtp6.webway.se (smtp2.webway.se [87.96.134.128]) by smtp5.webway.se (Postfix) with ESMTP id E7E8D43F7EB; Wed, 27 Jan 2010 18:37:22 +0000 (UTC) Received: from [192.168.40.12] (ns.webway.se [87.96.134.125]) by smtp6.webway.se (Postfix) with ESMTPA id 4B9F3552E52; Wed, 27 Jan 2010 18:38:59 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4B608485.20309@alcatel-lucent.com> Date: Wed, 27 Jan 2010 19:37:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1A6D7EFA-3502-4B12-AE15-7A52535DAE24@edvina.net> References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B210DA9.90501@alcatel-lucent.com> <01DD632E-C839-4965-BB4E-0F063D0871B0@edvina.net> <932F6A87-D112-4E9D-913E-9AF518E6891E@cisco.com> <4B608485.20309@alcatel-lucent.com> To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.1077) Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 18:37:10 -0000 27 jan 2010 kl. 19.23 skrev Vijay K. Gurbani: > Cullen Jennings wrote: >> You are complete right that what goes in the record route needs to >> match what is in the cert.=20 > [...] >=20 > Cullen: We had extensive discussion on this very topic when we > were hashing out domain-certs (remember: we were then referring > to "pinning" the request through a particular proxy.) >=20 > The normative behavior that we agreed on is spelled out in > Section 7.5 of domain-certs (see the third paragraph.) Fortunately, > the normative behavior in Section 7.5 matches your description. >=20 " If a proxy adds a Record-Route when forwarding a request with the expectation that the route is to use secure connections, the proxy MUST insert into the Record-Route header a URI that corresponds to an identity for which the proxy has a certificate; if the proxy does not insert such a URI, then creation of a secure connection using the value from the Record-Route as the AUS will be impossible." It doesn't really say that a DNS name is preferred. Maybe we should add = that, and a note about benefits using a domain name in some = environments. /O= From vkg@alcatel-lucent.com Wed Jan 27 10:51:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85CDC3A6971 for ; Wed, 27 Jan 2010 10:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-iR+uUvQluk for ; Wed, 27 Jan 2010 10:51:49 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 74DA73A6861 for ; Wed, 27 Jan 2010 10:51:49 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o0RIpx1K001648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 12:51:59 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o0RIpxkM018708; Wed, 27 Jan 2010 12:51:59 -0600 (CST) Message-ID: <4B608B4F.4000304@alcatel-lucent.com> Date: Wed, 27 Jan 2010 12:51:59 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Olle E. Johansson" References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B210DA9.90501@alcatel-lucent.com> <01DD632E-C839-4965-BB4E-0F063D0871B0@edvina.net> <932F6A87-D112-4E9D-913E-9AF518E6891E@cisco.com> <4B608485.20309@alcatel-lucent.com> <1A6D7EFA-3502-4B12-AE15-7A52535DAE24@edvina.net> In-Reply-To: <1A6D7EFA-3502-4B12-AE15-7A52535DAE24@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 18:51:50 -0000 Olle E. Johansson wrote: > It doesn't really say that a DNS name is preferred. Maybe we should > add that, and a note about benefits using a domain name in some > environments. Olle: The document recognizes what you presciently write above, and says this in support: This document shows how the certificates are to be used for mutual authentication when both the client and server possess appropriate certificates, and normative behavior for matching the DNS query string with an identity stored in the X.509 certificate. Furthermore, a certificate can contain multiple identities for the subject in the subjectAltName extension (the "subject" of a certificate identifies the entity associated with the public key stored in the public key field.) As such, this document specifies appropriate matching rules to encompass various subject identity representation options. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From jmpolk@cisco.com Wed Jan 27 12:24:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9126A3A6972 for ; Wed, 27 Jan 2010 12:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTtu-VgGoHYE for ; Wed, 27 Jan 2010 12:24:23 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1B7213A67B2 for ; Wed, 27 Jan 2010 12:24:23 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsFAOovYEurR7Ht/2dsb2JhbACGVbtKlyKEOQQ X-IronPort-AV: E=Sophos;i="4.49,355,1262563200"; d="scan'208";a="209659400" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 27 Jan 2010 20:24:38 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0RKOcTq022235 for ; Wed, 27 Jan 2010 20:24:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 12:24:38 -0800 Received: from jmpolk-wxp01.cisco.com ([10.99.80.18]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 12:24:37 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Jan 2010 14:24:36 -0600 To: Paul Kyzivat From: "James M. Polk" In-Reply-To: <4B604D1D.2060602@cisco.com> References: <4B604D1D.2060602@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 27 Jan 2010 20:24:38.0076 (UTC) FILETIME=[BF841FC0:01CA9F8E] Cc: sipcore@ietf.org Subject: Re: [sipcore] BNF for Geolocation Header proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 20:24:24 -0000 At 08:26 AM 1/27/2010, Paul Kyzivat wrote: >I do see a problem with this. More inline. thanks for reviewing this quickly, Paul! comments and new text/BNF below > Regards, > Paul > >James M. Polk wrote: >>I thought I'd run this by the WG before finalizing the next rev of >>Location Conveyance. I pretty sure I've solved the BNF issue in >>relation to RFC 5606 (retransmission of SIP location >>conveyance). Does anyone have any heartburn with this: >> Geolocation = "Geolocation" HCOLON (locationValue *(COMMA >> locationValue)) (COMMA retrans-param) >> locationValue = LAQUOT locationURI RAQUOT SEMI inserted-param >> *(SEMI geoloc-param) >> locationURI = sip-URI / sips-URI / pres-URI >> / cid-url ; (from RFC 2392) >> / absoluteURI ; (from RFC 3261) >> inserted-param = "inserted-by" EQUAL geoloc-inserter >> geoloc-inserter = DQUOTE hostport DQUOTE >> / gen-value ; (from RFC 3261) >> geoloc-param = "used-for-routing" / generic-param ; >> (from RFC 3261) >> retrans-param = "routing-allowed" EQUAL "yes" / "no" >>The nut of the change is to create the retrans-param, and make it >>COMMA separated from any locationValue in the header. This is >>because the routing-allowed parameter can exist in the Geolocation >>header value without a locationValue - i.e., when there's no >>location indicated within this SIP request, but there is a policy >>statement about whether this UAC wants its location - potentially >>inserted by a SIP server - to be allowed to retransmitted to a >>third party (i.e., to someone/entity not in the SIP signaling path) >>by any other in-path entity. >>The routing-allowed parameter was moved from the geoloc-param >>portion of the BNF. > >Section 7.3.1 of 3261 includes: > > Multiple header field rows with the same field-name MAY be present in > a message if and only if the entire field-value for that header field > is defined as a comma-separated list (that is, if follows the grammar > defined in Section 7.3). It MUST be possible to combine the multiple > header field rows into one "field-name: field-value" pair, without > changing the semantics of the message, by appending each subsequent > field-value to the first, each separated by a comma. The exceptions > to this rule are the WWW-Authenticate, Authorization, Proxy- > Authenticate, and Proxy-Authorization header fields. Multiple header > field rows with these names MAY be present in a message, but since > their grammar does not follow the general form listed in Section 7.3, > they MUST NOT be combined into a single header field row. > >The references format in 7.3 is: > > header = "header-name" HCOLON header-value *(COMMA header-value) > >Your syntax is in violation of this rule. > >Even ignoring the restriction in 3261, there are real implementation >difficulties with what you have written. Most notably, suppose there >are two instances of the header in a message: > >Geolocation: ;inserted-by="example.com", routing-allowed=yes >... >Geolocation: ;inserted-by="example.org", routing-allowed=no > >That would seem to be allowed by your syntax, but makes no sense. I knew about this multiple rows scenario, but was looking for a way for the BNF to solve it in the single header. I guess that cannot happen. >A straightforward way to deal with this would be to create a >distinct header for this value, separate from the Geolocation >header. Another way would be: > > Geolocation = "Geolocation" HCOLON locationArg > *(COMMA locationArg) > locationArg = locationValue / retrans-param > >And then just supply text that says retrans-param may appear at most >once in a message. ok -- I've changed the BNF to Geolocation = "Geolocation" HCOLON (locationArg *(COMMA locationArg) locationArg = locationValue / routing-param locationValue = LAQUOT locationURI RAQUOT SEMI inserted-param *(SEMI geoloc-param) locationURI = sip-URI / sips-URI / pres-URI / cid-url ; (from RFC 2392) / absoluteURI ; (from RFC 3261) inserted-param = "inserted-by" EQUAL geoloc-inserter geoloc-inserter = DQUOTE hostport DQUOTE / gen-value ; (from RFC 3261) geoloc-param = "used-for-routing" / generic-param ; (from RFC 3261) routing-param = "routing-allowed" EQUAL "yes" / "no" which is what you stated would work above. I'll also include the text surrounding the routing-allowed parameter for review too, including the text about how the routing-allowed parameter cannot occur more than once, as well as what to do if a SIP intermediary does receive more than one that conflict: == The "routing-allowed" header field parameter is a global parameter over any (and all/each) locationValues in the Geolocation header field. The placement of the parameter is outside any locationValue, appears only once, and is always last in the header field value. The routing-allowed parameter can be present when no locationValue is present. This scenario sets the routing-allowed policy downstream along the request's signaling path. This header field parameter only has the values "=yes" or "=no". When this parameter is "=yes", any locationValue can be used for routing decisions along the downstream signaling path by intermediaries. When this parameter is "=no", this means no locationValue (inserted by the originating UAC or any (or subsequent) intermediary(ies) along the signaling path) can be used by any SIP intermediary to make routing decisions. This behavior MUST be adhered to. Section 4.3 describes the details on what a routing intermediary does if it believes it needs to use the location in the SIP request in order to process the message further. The practical implication is that when the "routing-allowed" parameter is set to "no", if a cid:url is present in the SIP request, intermediaries MUST NOT view the location (because it is not for intermediaries to view), and if a location URI is present, intermediaries MUST NOT dereference it. UASs are allowed to view location in the SIP request even when the "routing-allowed" parameter is set to "no". There MUST not be more than one routing-allowed parameter in any SIP request, regardless of when there are cases of more than one Geolocation header field rows (i.e., more than one Geolocation header in the SIP request, as defined in section 7.3.1 of RFC 3261). There does not have to be any routing-allowed parameter present in a Geolocation header value of a SIP request. However, the default treatment of the absence of the routing-allowed parameter is as if it were present, and set to "=no" without exception. If a routing-allowed parameter is parsed as set to "=yes", an implementation MUST parse the rest of the SIP header for another instance of the Geolocation header value to determine if there is another instance of the routing-allowed parameter set to "=no". If this is the case, the behavior MUST be to process the "=no" only, and ignore the "=yes". == Does this work (for everyone)? Let me know (fairly soon) if there are mods you want to this. James >(I think a separate header is cleaner.) > >>An agreement was reached by many (based on 5606) that since there >>should be only one of these parameters - regardless of how many >>locationValues there are in the header - thus making the parameter >>globally applicable. Moving this to the top line seemed best (i.e., >>there can be only one instance of it), instead of parsing though >>each locationValue -- potentially with competing routing-allowed >>values when there is more than one locationValue in the header value. >>I'm updating the text now to reflect all of this. >>Let me know if this is broken somehow. >>James >>_______________________________________________ >>sipcore mailing list >>sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Wed Jan 27 12:53:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF8A3A68E7 for ; Wed, 27 Jan 2010 12:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.256 X-Spam-Level: X-Spam-Status: No, score=-10.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6erbewficBE for ; Wed, 27 Jan 2010 12:53:41 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 48DEB3A688C for ; Wed, 27 Jan 2010 12:53:41 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALY2YEurRN+K/2dsb2JhbADCKJclhDkE X-IronPort-AV: E=Sophos;i="4.49,355,1262563200"; d="scan'208";a="141088815" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 27 Jan 2010 20:53:56 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0RKru0U003033 for ; Wed, 27 Jan 2010 20:53:56 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 14:53:55 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 14:53:56 -0600 Message-ID: <4B60A7E3.7090108@cisco.com> Date: Wed, 27 Jan 2010 15:53:55 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "James M. Polk" References: <4B604D1D.2060602@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jan 2010 20:53:56.0233 (UTC) FILETIME=[D7759790:01CA9F92] Cc: sipcore@ietf.org Subject: Re: [sipcore] BNF for Geolocation Header proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 20:53:42 -0000 Inline James M. Polk wrote: > At 08:26 AM 1/27/2010, Paul Kyzivat wrote: >> I do see a problem with this. More inline. > > thanks for reviewing this quickly, Paul! > > comments and new text/BNF below > > >> Regards, >> Paul >> >> James M. Polk wrote: >>> I thought I'd run this by the WG before finalizing the next rev of >>> Location Conveyance. I pretty sure I've solved the BNF issue in >>> relation to RFC 5606 (retransmission of SIP location conveyance). >>> Does anyone have any heartburn with this: >>> Geolocation = "Geolocation" HCOLON (locationValue *(COMMA >>> locationValue)) (COMMA retrans-param) >>> locationValue = LAQUOT locationURI RAQUOT SEMI inserted-param >>> *(SEMI geoloc-param) >>> locationURI = sip-URI / sips-URI / pres-URI >>> / cid-url ; (from RFC 2392) >>> / absoluteURI ; (from RFC 3261) >>> inserted-param = "inserted-by" EQUAL geoloc-inserter >>> geoloc-inserter = DQUOTE hostport DQUOTE >>> / gen-value ; (from RFC 3261) >>> geoloc-param = "used-for-routing" / generic-param ; >>> (from RFC 3261) >>> retrans-param = "routing-allowed" EQUAL "yes" / "no" >>> The nut of the change is to create the retrans-param, and make it >>> COMMA separated from any locationValue in the header. This is >>> because the routing-allowed parameter can exist in the Geolocation >>> header value without a locationValue - i.e., when there's no location >>> indicated within this SIP request, but there is a policy statement >>> about whether this UAC wants its location - potentially inserted by a >>> SIP server - to be allowed to retransmitted to a third party (i.e., >>> to someone/entity not in the SIP signaling path) by any other in-path >>> entity. >>> The routing-allowed parameter was moved from the geoloc-param portion >>> of the BNF. >> >> Section 7.3.1 of 3261 includes: >> >> Multiple header field rows with the same field-name MAY be present in >> a message if and only if the entire field-value for that header field >> is defined as a comma-separated list (that is, if follows the grammar >> defined in Section 7.3). It MUST be possible to combine the multiple >> header field rows into one "field-name: field-value" pair, without >> changing the semantics of the message, by appending each subsequent >> field-value to the first, each separated by a comma. The exceptions >> to this rule are the WWW-Authenticate, Authorization, Proxy- >> Authenticate, and Proxy-Authorization header fields. Multiple header >> field rows with these names MAY be present in a message, but since >> their grammar does not follow the general form listed in Section 7.3, >> they MUST NOT be combined into a single header field row. >> >> The references format in 7.3 is: >> >> header = "header-name" HCOLON header-value *(COMMA header-value) >> >> Your syntax is in violation of this rule. >> >> Even ignoring the restriction in 3261, there are real implementation >> difficulties with what you have written. Most notably, suppose there >> are two instances of the header in a message: >> >> Geolocation: ;inserted-by="example.com", routing-allowed=yes >> ... >> Geolocation: ;inserted-by="example.org", routing-allowed=no >> >> That would seem to be allowed by your syntax, but makes no sense. > > I knew about this multiple rows scenario, but was looking for a way for > the BNF to solve it in the single header. I guess that cannot happen. > > >> A straightforward way to deal with this would be to create a distinct >> header for this value, separate from the Geolocation header. Another >> way would be: >> >> Geolocation = "Geolocation" HCOLON locationArg >> *(COMMA locationArg) >> locationArg = locationValue / retrans-param >> >> And then just supply text that says retrans-param may appear at most >> once in a message. > > ok -- I've changed the BNF to > > Geolocation = "Geolocation" HCOLON (locationArg > *(COMMA locationArg) You have an extra "(" in the above, just after HCOLON. Just remove it and it will be ok. > locationArg = locationValue / routing-param > locationValue = LAQUOT locationURI RAQUOT SEMI inserted-param > *(SEMI geoloc-param) > locationURI = sip-URI / sips-URI / pres-URI > / cid-url ; (from RFC 2392) > / absoluteURI ; (from RFC 3261) > inserted-param = "inserted-by" EQUAL geoloc-inserter > geoloc-inserter = DQUOTE hostport DQUOTE > / gen-value ; (from RFC 3261) > geoloc-param = "used-for-routing" / generic-param ; > (from RFC 3261) > routing-param = "routing-allowed" EQUAL "yes" / "no" > > which is what you stated would work above. > > I'll also include the text surrounding the routing-allowed parameter for > review too, including the text about how the routing-allowed parameter > cannot occur more than once, as well as what to do if a SIP intermediary > does receive more than one that conflict: > > == > The "routing-allowed" header field parameter is a global parameter > over any (and all/each) locationValues in the Geolocation header > field. The placement of the parameter is outside any locationValue, > appears only once, and is always last in the header field value. The > routing-allowed parameter can be present when no locationValue is > present. This scenario sets the routing-allowed policy downstream > along the request's signaling path. I think it unwise to impose the "must be last" rule. I don't see that it adds anything but grief. If the UAC includes a "Geolocation: routing-allowed=yes", and then an intermediary wants to add the actual location, a reasonable thing to do would be to simply add another Geolocation header, or header field, after the prior onces have been examined. Changing the order would be annoying. > This header field parameter only has the values "=yes" or "=no". > When this parameter is "=yes", any locationValue can be used for > routing decisions along the downstream signaling path by > intermediaries. When this parameter is "=no", this means no > locationValue (inserted by the originating UAC or any (or > subsequent) intermediary(ies) along the signaling path) can be used > by any SIP intermediary to make routing decisions. This behavior > MUST be adhered to. Section 4.3 describes the details on what a > routing intermediary does if it believes it needs to use the > location in the SIP request in order to process the message further. > > The practical implication is that when the "routing-allowed" > parameter is set to "no", if a cid:url is present in the SIP > request, intermediaries MUST NOT view the location (because it is > not for intermediaries to view), and if a location URI is present, > intermediaries MUST NOT dereference it. UASs are allowed to view > location in the SIP request even when the "routing-allowed" > parameter is set to "no". > > There MUST not be more than one routing-allowed parameter in any SIP > request, regardless of when there are cases of more than one > Geolocation header field rows (i.e., more than one Geolocation > header in the SIP request, as defined in section 7.3.1 of RFC 3261). > There does not have to be any routing-allowed parameter present in a > Geolocation header value of a SIP request. However, the default > treatment of the absence of the routing-allowed parameter is as if > it were present, and set to "=no" without exception. > > If a routing-allowed parameter is parsed as set to "=yes", an > implementation MUST parse the rest of the SIP header for another > instance of the Geolocation header value to determine if there is > another instance of the routing-allowed parameter set to "=no". If > this is the case, the behavior MUST be to process the "=no" only, > and ignore the "=yes". I have mixed feelings about the above. You have already stated that there MUST only be one. And now you are stating what to do if there is more than one. Usually we don't spec behavior on non-conforming cases. It might be better to state that there SHOULD only be one, and that when there is more than one, "no" takes precedence over "yes". Thanks, Paul > == > > Does this work (for everyone)? Let me know (fairly soon) if there are > mods you want to this. > > James > > >> (I think a separate header is cleaner.) >> >>> An agreement was reached by many (based on 5606) that since there >>> should be only one of these parameters - regardless of how many >>> locationValues there are in the header - thus making the parameter >>> globally applicable. Moving this to the top line seemed best (i.e., >>> there can be only one instance of it), instead of parsing though each >>> locationValue -- potentially with competing routing-allowed values >>> when there is more than one locationValue in the header value. >>> I'm updating the text now to reflect all of this. >>> Let me know if this is broken somehow. >>> James >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore > > From brian@estacado.net Wed Jan 27 14:16:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51853A6924 for ; Wed, 27 Jan 2010 14:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1o6FTM4YiQYC for ; Wed, 27 Jan 2010 14:16:51 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id B1AC63A67A4 for ; Wed, 27 Jan 2010 14:16:50 -0800 (PST) Received: from [172.16.3.229] (dn3-229.estacado.net [172.16.3.229]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o0RMGrwG018449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jan 2010 16:16:53 -0600 (CST) (envelope-from brian@estacado.net) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Hibbard In-Reply-To: Date: Wed, 27 Jan 2010 16:16:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1C8D975C-DDAA-42AD-AB8A-723E34820552@estacado.net> References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <85C804CE-610E-42E9-86FD-F8FED9620E29@cisco.com> <126F4C63-8C3D-4131-8FA4-B8EBC0B7C804@estacado.net> To: Cullen Jennings X-Mailer: Apple Mail (2.1077) Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 22:16:52 -0000 I'll put references in. Thanks! -b On Jan 27, 2010, at 12:00 PM, Cullen Jennings wrote: >=20 > On Jan 19, 2010, at 12:16 PM, Brian Hibbard wrote: >=20 >>=20 >>=20 >> As for how to check revocation status, you're almost certainly right = about whether we can get agreement. We could refer them to section 3.3 = of RFC 5280 and leave it at that.=20 >=20 > I think it might be good to add an informative ref to OSCP and SCVP = too.=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From brian@estacado.net Wed Jan 27 14:30:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3C63A6956 for ; Wed, 27 Jan 2010 14:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUOSZlkMSNb7 for ; Wed, 27 Jan 2010 14:30:37 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 4D8EB3A635F for ; Wed, 27 Jan 2010 14:30:36 -0800 (PST) Received: from [172.16.3.229] (dn3-229.estacado.net [172.16.3.229]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o0RMUgZ2020676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jan 2010 16:30:42 -0600 (CST) (envelope-from brian@estacado.net) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Hibbard In-Reply-To: <4B608B4F.4000304@alcatel-lucent.com> Date: Wed, 27 Jan 2010 16:30:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B210DA9.90501@alcatel-lucent.com> <01DD632E-C839-4965-BB4E-0F063D0871B0@edvina.net> <932F6A87-D112-4E9D-913E-9AF518E6891E@cisco.com> <4B608485.20309@alcatel-lucent.com> <1A6D7EFA-3502-4B12-AE15-7A52535DAE24@edvina.net> <4B608B4F.4000304@alcatel-lucent.com> To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.1077) Cc: SIPCORE , "Olle E. Johansson" Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 22:30:39 -0000 So, we should add an admonition in section 6 "Additional Test Scenarios" = to avoid using IP addrs in SAN if possible, and reference sec 7.5 of = domain-certs? Is it beneficial to cite the specific issue of = Record-Route? I was thinking of paraphrasing Cullen's earlier comment. = Of course, if someone wants to take a stab at word-crafting this, I'm = sure it would be well received. -b On Jan 27, 2010, at 12:51 PM, Vijay K. Gurbani wrote: > Olle E. Johansson wrote: >> It doesn't really say that a DNS name is preferred. Maybe we should = add that, and a note about benefits using a domain name in some = environments. >=20 > Olle: The document recognizes what you presciently write above, > and says this in support: >=20 > This document shows how the certificates are to be used for mutual > authentication when both the client and server possess appropriate > certificates, and normative behavior for matching the DNS query > string with an identity stored in the X.509 certificate. > Furthermore, a certificate can contain multiple identities for the > subject in the subjectAltName extension (the "subject" of a > certificate identifies the entity associated with the public key > stored in the public key field.) As such, this document specifies > appropriate matching rules to encompass various subject identity > representation options. >=20 > Thanks, >=20 > - vijay > --=20 > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Wed Jan 27 15:19:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F25B3A67F3 for ; Wed, 27 Jan 2010 15:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.239 X-Spam-Level: X-Spam-Status: No, score=-10.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwIVVteNBDrF for ; Wed, 27 Jan 2010 15:19:56 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7C7DB3A67BE for ; Wed, 27 Jan 2010 15:19:56 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FALJYYEurR7Hu/2dsb2JhbACGWLpplyiEOQQ X-IronPort-AV: E=Sophos;i="4.49,356,1262563200"; d="scan'208";a="141187621" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 27 Jan 2010 23:20:12 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0RNKCc2003515 for ; Wed, 27 Jan 2010 23:20:12 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 15:20:12 -0800 Received: from jmpolk-wxp01.cisco.com ([10.99.80.18]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 15:20:11 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Jan 2010 17:20:08 -0600 To: Paul Kyzivat From: "James M. Polk" In-Reply-To: <4B60A7E3.7090108@cisco.com> References: <4B604D1D.2060602@cisco.com> <4B60A7E3.7090108@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 27 Jan 2010 23:20:11.0917 (UTC) FILETIME=[462CB3D0:01CA9FA7] Cc: sipcore@ietf.org Subject: Re: [sipcore] BNF for Geolocation Header proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 23:19:58 -0000 in-line At 02:53 PM 1/27/2010, Paul Kyzivat wrote: >Inline > >James M. Polk wrote: >>At 08:26 AM 1/27/2010, Paul Kyzivat wrote: >>>I do see a problem with this. More inline. >>thanks for reviewing this quickly, Paul! >>comments and new text/BNF below >> >>> Regards, >>> Paul >>> >>>James M. Polk wrote: >>>>I thought I'd run this by the WG before finalizing the next rev >>>>of Location Conveyance. I pretty sure I've solved the BNF issue >>>>in relation to RFC 5606 (retransmission of SIP location conveyance). >>>>Does anyone have any heartburn with this: >>>> Geolocation = "Geolocation" HCOLON (locationValue *(COMMA >>>> locationValue)) (COMMA retrans-param) >>>> locationValue = LAQUOT locationURI RAQUOT SEMI inserted-param >>>> *(SEMI geoloc-param) >>>> locationURI = sip-URI / sips-URI / pres-URI >>>> / cid-url ; (from RFC 2392) >>>> / absoluteURI ; (from RFC 3261) >>>> inserted-param = "inserted-by" EQUAL geoloc-inserter >>>> geoloc-inserter = DQUOTE hostport DQUOTE >>>> / gen-value ; (from RFC 3261) >>>> geoloc-param = "used-for-routing" / generic-param ; >>>> (from RFC 3261) >>>> retrans-param = "routing-allowed" EQUAL "yes" / "no" >>>>The nut of the change is to create the retrans-param, and make it >>>>COMMA separated from any locationValue in the header. This is >>>>because the routing-allowed parameter can exist in the >>>>Geolocation header value without a locationValue - i.e., when >>>>there's no location indicated within this SIP request, but there >>>>is a policy statement about whether this UAC wants its location - >>>>potentially inserted by a SIP server - to be allowed to >>>>retransmitted to a third party (i.e., to someone/entity not in >>>>the SIP signaling path) by any other in-path entity. >>>>The routing-allowed parameter was moved from the geoloc-param >>>>portion of the BNF. >>> >>>Section 7.3.1 of 3261 includes: >>> >>> Multiple header field rows with the same field-name MAY be present in >>> a message if and only if the entire field-value for that header field >>> is defined as a comma-separated list (that is, if follows the grammar >>> defined in Section 7.3). It MUST be possible to combine the multiple >>> header field rows into one "field-name: field-value" pair, without >>> changing the semantics of the message, by appending each subsequent >>> field-value to the first, each separated by a comma. The exceptions >>> to this rule are the WWW-Authenticate, Authorization, Proxy- >>> Authenticate, and Proxy-Authorization header fields. Multiple header >>> field rows with these names MAY be present in a message, but since >>> their grammar does not follow the general form listed in Section 7.3, >>> they MUST NOT be combined into a single header field row. >>> >>>The references format in 7.3 is: >>> >>> header = "header-name" HCOLON header-value *(COMMA header-value) >>> >>>Your syntax is in violation of this rule. >>> >>>Even ignoring the restriction in 3261, there are real >>>implementation difficulties with what you have written. Most >>>notably, suppose there are two instances of the header in a message: >>> >>>Geolocation: ;inserted-by="example.com", routing-allowed=yes >>>... >>>Geolocation: ;inserted-by="example.org", routing-allowed=no >>> >>>That would seem to be allowed by your syntax, but makes no sense. >>I knew about this multiple rows scenario, but was looking for a way >>for the BNF to solve it in the single header. I guess that cannot happen. >> >>>A straightforward way to deal with this would be to create a >>>distinct header for this value, separate from the Geolocation >>>header. Another way would be: >>> >>> Geolocation = "Geolocation" HCOLON locationArg >>> *(COMMA locationArg) >>> locationArg = locationValue / retrans-param >>> >>>And then just supply text that says retrans-param may appear at >>>most once in a message. >>ok -- I've changed the BNF to >> Geolocation = "Geolocation" HCOLON (locationArg >> *(COMMA locationArg) > >You have an extra "(" in the above, just after HCOLON. Just remove >it and it will be ok. thanks, I've made the correction >> locationArg = locationValue / routing-param >> locationValue = LAQUOT locationURI RAQUOT SEMI inserted-param >> *(SEMI geoloc-param) >> locationURI = sip-URI / sips-URI / pres-URI >> / cid-url ; (from RFC 2392) >> / absoluteURI ; (from RFC 3261) >> inserted-param = "inserted-by" EQUAL geoloc-inserter >> geoloc-inserter = DQUOTE hostport DQUOTE >> / gen-value ; (from RFC 3261) >> geoloc-param = "used-for-routing" / generic-param ; >> (from RFC 3261) >> routing-param = "routing-allowed" EQUAL "yes" / "no" >>which is what you stated would work above. >>I'll also include the text surrounding the routing-allowed >>parameter for review too, including the text about how the >>routing-allowed parameter cannot occur more than once, as well as >>what to do if a SIP intermediary does receive more than one that conflict: >>== >> The "routing-allowed" header field parameter is a global parameter >> over any (and all/each) locationValues in the Geolocation header >> field. The placement of the parameter is outside any locationValue, >> appears only once, and is always last in the header field value. The >> routing-allowed parameter can be present when no locationValue is >> present. This scenario sets the routing-allowed policy downstream >> along the request's signaling path. > >I think it unwise to impose the "must be last" rule. I don't see >that it adds anything but grief. If the UAC includes a "Geolocation: >routing-allowed=yes", and then an intermediary wants to add the >actual location, a reasonable thing to do would be to simply add >another Geolocation header, or header field, after the prior onces >have been examined. Changing the order would be annoying. ok, you've talked me into removing the "must be last" wrt the "routing-allowed" parameter. >> This header field parameter only has the values "=yes" or "=no". >> When this parameter is "=yes", any locationValue can be used for >> routing decisions along the downstream signaling path by >> intermediaries. When this parameter is "=no", this means no >> locationValue (inserted by the originating UAC or any (or >> subsequent) intermediary(ies) along the signaling path) can be used >> by any SIP intermediary to make routing decisions. This behavior >> MUST be adhered to. Section 4.3 describes the details on what a >> routing intermediary does if it believes it needs to use the >> location in the SIP request in order to process the message further. >> The practical implication is that when the "routing-allowed" >> parameter is set to "no", if a cid:url is present in the SIP >> request, intermediaries MUST NOT view the location (because it is >> not for intermediaries to view), and if a location URI is present, >> intermediaries MUST NOT dereference it. UASs are allowed to view >> location in the SIP request even when the "routing-allowed" >> parameter is set to "no". >> There MUST not be more than one routing-allowed parameter in any SIP >> request, regardless of when there are cases of more than one >> Geolocation header field rows (i.e., more than one Geolocation >> header in the SIP request, as defined in section 7.3.1 of RFC 3261). >> There does not have to be any routing-allowed parameter present in a >> Geolocation header value of a SIP request. However, the default >> treatment of the absence of the routing-allowed parameter is as if >> it were present, and set to "=no" without exception. >> If a routing-allowed parameter is parsed as set to "=yes", an >> implementation MUST parse the rest of the SIP header for another >> instance of the Geolocation header value to determine if there is >> another instance of the routing-allowed parameter set to "=no". If >> this is the case, the behavior MUST be to process the "=no" only, >> and ignore the "=yes". > >I have mixed feelings about the above. You have already stated that >there MUST only be one. And now you are stating what to do if there >is more than one. the reason for this (which may be more appropriate in the SIP Proxy section, as it only applies to these SIP entities) is bad implementations, and what to do with receiving multiple of this parameter *from* a bad implementation (trying to prevent entities barfing when it likely is 100% the case that the original UAC didn't cause this problem, and can't fix it regardless of the 4XX or 5XX code in the reply indicating there was a problem with this request). >Usually we don't spec behavior on non-conforming cases. Usually we don't spec abilities for SIP servers to inject something into request that can cause a bad reaction either - such as the UAC and Proxy inserting location of the UAC in the request, yet point to two different locations. What's a UAS to do with this? The prevailing belief coming out of RFC 5606 was that the "routing-allowed=no" would rule out any conflicting indication of "=yes'. The above text instructs what to do in the case of two parameter values that conflict. Perhaps it could be said better. >It might be better to state that there SHOULD only be one, and that >when there is more than one, "no" takes precedence over "yes". This is a thought... I'd still like to instruct the Proxy that parses a "=yes" to have to search for another routing-allowed parameter in each Geolocation header value to find out if there is a "=no" also in the same request -- and not just jump on the policy of the first routing-allowed parameter and move on to something else entirely. Thoughts? James > Thanks, > Paul > >>== >>Does this work (for everyone)? Let me know (fairly soon) if there >>are mods you want to this. >>James >> >>>(I think a separate header is cleaner.) >>> >>>>An agreement was reached by many (based on 5606) that since there >>>>should be only one of these parameters - regardless of how many >>>>locationValues there are in the header - thus making the >>>>parameter globally applicable. Moving this to the top line seemed >>>>best (i.e., there can be only one instance of it), instead of >>>>parsing though each locationValue -- potentially with competing >>>>routing-allowed values when there is more than one locationValue >>>>in the header value. >>>>I'm updating the text now to reflect all of this. >>>>Let me know if this is broken somehow. >>>>James >>>>_______________________________________________ >>>>sipcore mailing list >>>>sipcore@ietf.org >>>>https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Wed Jan 27 15:40:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89EC3A69F6 for ; Wed, 27 Jan 2010 15:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nusfabkYQN-X for ; Wed, 27 Jan 2010 15:40:20 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 608B03A688D for ; Wed, 27 Jan 2010 15:40:20 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ9dYEutJV2c/2dsb2JhbADBGJcphDkE X-IronPort-AV: E=Sophos;i="4.49,356,1262563200"; d="scan'208";a="82561640" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 27 Jan 2010 23:40:35 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o0RNeZwS011790 for ; Wed, 27 Jan 2010 23:40:35 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:40:35 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 17:40:34 -0600 Message-ID: <4B60CEF2.5010509@cisco.com> Date: Wed, 27 Jan 2010 18:40:34 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "James M. Polk" References: <4B604D1D.2060602@cisco.com> <4B60A7E3.7090108@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jan 2010 23:40:35.0032 (UTC) FILETIME=[1F353D80:01CA9FAA] Cc: sipcore@ietf.org Subject: Re: [sipcore] BNF for Geolocation Header proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 23:40:21 -0000 at end... James M. Polk wrote: >> I think it unwise to impose the "must be last" rule. I don't see that >> it adds anything but grief. If the UAC includes a "Geolocation: >> routing-allowed=yes", and then an intermediary wants to add the actual >> location, a reasonable thing to do would be to simply add another >> Geolocation header, or header field, after the prior onces have been >> examined. Changing the order would be annoying. > > ok, you've talked me into removing the "must be last" wrt the > "routing-allowed" parameter. > > >>> This header field parameter only has the values "=yes" or "=no". >>> When this parameter is "=yes", any locationValue can be used for >>> routing decisions along the downstream signaling path by >>> intermediaries. When this parameter is "=no", this means no >>> locationValue (inserted by the originating UAC or any (or >>> subsequent) intermediary(ies) along the signaling path) can be used >>> by any SIP intermediary to make routing decisions. This behavior >>> MUST be adhered to. Section 4.3 describes the details on what a >>> routing intermediary does if it believes it needs to use the >>> location in the SIP request in order to process the message further. >>> The practical implication is that when the "routing-allowed" >>> parameter is set to "no", if a cid:url is present in the SIP >>> request, intermediaries MUST NOT view the location (because it is >>> not for intermediaries to view), and if a location URI is present, >>> intermediaries MUST NOT dereference it. UASs are allowed to view >>> location in the SIP request even when the "routing-allowed" >>> parameter is set to "no". >>> There MUST not be more than one routing-allowed parameter in any SIP >>> request, regardless of when there are cases of more than one >>> Geolocation header field rows (i.e., more than one Geolocation >>> header in the SIP request, as defined in section 7.3.1 of RFC 3261). >>> There does not have to be any routing-allowed parameter present in a >>> Geolocation header value of a SIP request. However, the default >>> treatment of the absence of the routing-allowed parameter is as if >>> it were present, and set to "=no" without exception. >>> If a routing-allowed parameter is parsed as set to "=yes", an >>> implementation MUST parse the rest of the SIP header for another >>> instance of the Geolocation header value to determine if there is >>> another instance of the routing-allowed parameter set to "=no". If >>> this is the case, the behavior MUST be to process the "=no" only, >>> and ignore the "=yes". >> >> I have mixed feelings about the above. You have already stated that >> there MUST only be one. And now you are stating what to do if there is >> more than one. > > the reason for this (which may be more appropriate in the SIP Proxy > section, as it only applies to these SIP entities) is bad > implementations, and what to do with receiving multiple of this > parameter *from* a bad implementation (trying to prevent entities > barfing when it likely is 100% the case that the original UAC didn't > cause this problem, and can't fix it regardless of the 4XX or 5XX code > in the reply indicating there was a problem with this request). > >> Usually we don't spec behavior on non-conforming cases. > > Usually we don't spec abilities for SIP servers to inject something into > request that can cause a bad reaction either - such as the UAC and Proxy > inserting location of the UAC in the request, yet point to two different > locations. What's a UAS to do with this? > > The prevailing belief coming out of RFC 5606 was that the > "routing-allowed=no" would rule out any conflicting indication of > "=yes'. The above text instructs what to do in the case of two parameter > values that conflict. Perhaps it could be said better. > >> It might be better to state that there SHOULD only be one, and that >> when there is more than one, "no" takes precedence over "yes". > > This is a thought... I'd still like to instruct the Proxy that parses a > "=yes" to have to search for another routing-allowed parameter in each > Geolocation header value to find out if there is a "=no" also in the > same request -- and not just jump on the policy of the first > routing-allowed parameter and move on to something else entirely. Yes, definitely. I gather the behavior you are looking for is: - if a "yes" is present and a "no" is *not* present, then routing based on the geoloc is permitted, - else routing on the geoloc is *not* permitted. Thanks, Paul From jmpolk@cisco.com Wed Jan 27 15:46:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F553A69F6 for ; Wed, 27 Jan 2010 15:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9peH2MbRPnU for ; Wed, 27 Jan 2010 15:46:15 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 17FD13A68FA for ; Wed, 27 Jan 2010 15:46:15 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAIlfYEurRN+J/2dsb2JhbACGWLpAlymEOQQ X-IronPort-AV: E=Sophos;i="4.49,356,1262563200"; d="scan'208";a="80050786" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 27 Jan 2010 23:46:30 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0RNkUHh002943; Wed, 27 Jan 2010 23:46:31 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 15:46:30 -0800 Received: from jmpolk-wxp01.cisco.com ([10.99.80.18]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 15:46:30 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Jan 2010 17:46:26 -0600 To: Paul Kyzivat From: "James M. Polk" In-Reply-To: <4B60CEF2.5010509@cisco.com> References: <4B604D1D.2060602@cisco.com> <4B60A7E3.7090108@cisco.com> <4B60CEF2.5010509@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 27 Jan 2010 23:46:30.0404 (UTC) FILETIME=[F306B440:01CA9FAA] Cc: sipcore@ietf.org Subject: Re: [sipcore] BNF for Geolocation Header proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 23:46:16 -0000 at end... At 05:40 PM 1/27/2010, Paul Kyzivat wrote: >at end... > >James M. Polk wrote: > >>>I think it unwise to impose the "must be last" rule. I don't see >>>that it adds anything but grief. If the UAC includes a >>>"Geolocation: routing-allowed=yes", and then an intermediary wants >>>to add the actual location, a reasonable thing to do would be to >>>simply add another Geolocation header, or header field, after the >>>prior onces have been examined. Changing the order would be annoying. >>ok, you've talked me into removing the "must be last" wrt the >>"routing-allowed" parameter. >> >>>> This header field parameter only has the values "=yes" or "=no". >>>> When this parameter is "=yes", any locationValue can be used for >>>> routing decisions along the downstream signaling path by >>>> intermediaries. When this parameter is "=no", this means no >>>> locationValue (inserted by the originating UAC or any (or >>>> subsequent) intermediary(ies) along the signaling path) can be used >>>> by any SIP intermediary to make routing decisions. This behavior >>>> MUST be adhered to. Section 4.3 describes the details on what a >>>> routing intermediary does if it believes it needs to use the >>>> location in the SIP request in order to process the message further. >>>> The practical implication is that when the "routing-allowed" >>>> parameter is set to "no", if a cid:url is present in the SIP >>>> request, intermediaries MUST NOT view the location (because it is >>>> not for intermediaries to view), and if a location URI is present, >>>> intermediaries MUST NOT dereference it. UASs are allowed to view >>>> location in the SIP request even when the "routing-allowed" >>>> parameter is set to "no". >>>> There MUST not be more than one routing-allowed parameter in any SIP >>>> request, regardless of when there are cases of more than one >>>> Geolocation header field rows (i.e., more than one Geolocation >>>> header in the SIP request, as defined in section 7.3.1 of RFC 3261). >>>> There does not have to be any routing-allowed parameter present in a >>>> Geolocation header value of a SIP request. However, the default >>>> treatment of the absence of the routing-allowed parameter is as if >>>> it were present, and set to "=no" without exception. >>>> If a routing-allowed parameter is parsed as set to "=yes", an >>>> implementation MUST parse the rest of the SIP header for another >>>> instance of the Geolocation header value to determine if there is >>>> another instance of the routing-allowed parameter set to "=no". If >>>> this is the case, the behavior MUST be to process the "=no" only, >>>> and ignore the "=yes". >>> >>>I have mixed feelings about the above. You have already stated >>>that there MUST only be one. And now you are stating what to do if >>>there is more than one. >>the reason for this (which may be more appropriate in the SIP Proxy >>section, as it only applies to these SIP entities) is bad >>implementations, and what to do with receiving multiple of this >>parameter *from* a bad implementation (trying to prevent entities >>barfing when it likely is 100% the case that the original UAC >>didn't cause this problem, and can't fix it regardless of the 4XX >>or 5XX code in the reply indicating there was a problem with this request). >> >>>Usually we don't spec behavior on non-conforming cases. >>Usually we don't spec abilities for SIP servers to inject something >>into request that can cause a bad reaction either - such as the UAC >>and Proxy inserting location of the UAC in the request, yet point >>to two different locations. What's a UAS to do with this? >>The prevailing belief coming out of RFC 5606 was that the >>"routing-allowed=no" would rule out any conflicting indication of >>"=yes'. The above text instructs what to do in the case of two >>parameter values that conflict. Perhaps it could be said better. >> >>>It might be better to state that there SHOULD only be one, and >>>that when there is more than one, "no" takes precedence over "yes". >>This is a thought... I'd still like to instruct the Proxy that >>parses a "=yes" to have to search for another routing-allowed >>parameter in each Geolocation header value to find out if there is >>a "=no" also in the same request -- and not just jump on the policy >>of the first routing-allowed parameter and move on to something else entirely. > >Yes, definitely. good! >I gather the behavior you are looking for is: > >- if a "yes" is present and a "no" is *not* present, then > routing based on the geoloc is permitted, >- else routing on the geoloc is *not* permitted. exactly Thanks! James > Thanks, > Paul From drage@alcatel-lucent.com Thu Jan 28 04:12:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C963A690E for ; Thu, 28 Jan 2010 04:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeM28usUQfmi for ; Thu, 28 Jan 2010 04:12:10 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 7A5BB3A6782 for ; Thu, 28 Jan 2010 04:12:08 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o0SCBrXl003063 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Jan 2010 13:11:59 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 28 Jan 2010 13:11:54 +0100 From: "DRAGE, Keith (Keith)" To: Cullen Jennings , Brian Hibbard Date: Thu, 28 Jan 2010 13:11:53 +0100 Thread-Topic: [sipcore] draft-ietf-sipcore-sec-flows-01: document scope and intent Thread-Index: Acqfe5xKhMeT2mLQTUOM11IVEnc8cgAltu1Q Message-ID: References: <4656101B-A8F8-4EC3-B9D7-D2B01FD824B0@estacado.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: document scope and intent X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 12:12:14 -0000 The key thing here is whether any of those normative like statements need t= o appear at standards track level.=20 If they do, they belong in another document, as this document is definitely= informative. If they don't belong in another document they still need careful considerat= ion as to whether they appear as=20 XXX MUST do this,=20 as opposed to a commentary on what appears elsewhere: Based on the requirements in document zzz, the correct usage of those requi= rements results in XXX doing this. There is certainly no point in circulating normative statements in a docume= nt just because that is the way they were first formulated. We need to cons= ider if that is the best way of presenting that particular item of informat= ion. regards Keith > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Wednesday, January 27, 2010 6:07 PM > To: Brian Hibbard > Cc: DRAGE, Keith (Keith); SIPCORE; Kumiko Ono > Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01:=20 > document scope and intent >=20 >=20 > On Jan 7, 2010, at 3:08 PM, Brian Hibbard wrote: >=20 > > OK, it seems there is heavy agreement that this SHOULD be=20 > informational and not standards track. Do we have agreement on that? > >=20 > > Specifically, Cullen, are you OK with that? >=20 > No problem - this is a chair issue/AD (Robert) issue and glad=20 > to do whatever they want.=20 >=20 > > Do you want to weigh in on the rationale for=20 > normative-strength statements? > >=20 > > If there are no remaining objections, I can go ahead and=20 > make the draft informational and remove section 2 and=20 > references to RFC 2119. I'll make sure we have no =20 > normative-sounding SHOULDs, MUSTs, et al. >=20 > Uh, we have all kinds of normative language in RAI =20 > Information RFC so don't water things down such that=20 > implementers don't know what to do. The point of this doc is=20 > to help implementers get it right so as long as the language=20 > changes are consistent with helping implementors get it=20 > right. I'm fine with them.=20 >=20 > >=20 > > -b > > On Dec 11, 2009, at 8:07 AM, DRAGE, Keith (Keith) wrote: > >=20 > >> If so, you arbitrarily decided to change it because as far=20 > as I know it was informational during its complete lifetime=20 > in the SIP group, and I remember no discussion in the=20 > transfer to SIPCORE that made it standards track. Certainly=20 > my final SIP status slides (and the ones before and the ones=20 > before that ...) also say "Candidate: Informational". The=20 > first version that carries an "intended status" line is the=20 > 1st sipcore version, and this is at variance with the charter pages. > >>=20 > >> The last SIP charter pages clearly say: > >> Mar 2009 Example security flows to WGLC (Informational) > >> Jul 2009 Example security flows to IESG (Informational) > >>=20 > >> And the SIPCORE charter pages state: > >>=20 > >> Oct 2009 Example security flows to IESG (Informational) > >>=20 > >> And from my own perspective this should still be=20 > informational. If you feel there is standards track=20 > information in here, then pull it out and submit it as a=20 > separate draft, and then the WG can decide whether they want=20 > to proceed with such a standards track document. > >>=20 > >> I'd also note to all authors that if you receive private=20 > messages of interest, then at least please let the WG chairs=20 > know that you have had those expressions of interest. If you=20 > received any of those messages on sec-flows during its SIP=20 > lifetime, the ex SIP WG chairs certainly have no evidence of=20 > them ever having been received - and that is essential=20 > information to the PROTO writeups. I assume the SIPCORE=20 > chairs are now in the same boat, having no email evidence=20 > because a small set of exchanges in the past on SIP and=20 > SIPCORE that anyone is even interested in this document. > >>=20 > >> regards > >>=20 > >> Keith > >>=20 > >>> -----Original Message----- > >>> From: sipcore-bounces@ietf.org > >>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Cullen Jennings > >>> Sent: Thursday, December 10, 2009 6:14 AM > >>> To: Brian Hibbard > >>> Cc: SIPCORE; Kumiko Ono > >>> Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: > >>> document scope and intent > >>>=20 > >>>=20 > >>> On Nov 24, 2009, at 2:25 PM, Brian Hibbard wrote: > >>>=20 > >>>> The draft states in the first line of the introduction that > >>> it is not normative for SIP. That raises the question as=20 > to whether=20 > >>> this should be on the standards track. Should this be=20 > informational=20 > >>> or BCP? > >>>=20 > >>> I think we decided it need to be standards track when we=20 > added the=20 > >>> normative statements about binary a long time ago. > >>> (I note that the "should" should be a "SHOULD". > >>>=20 > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>>=20 > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 > = From vkg@alcatel-lucent.com Thu Jan 28 07:25:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCBA33A6A0A for ; Thu, 28 Jan 2010 07:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0ia5JCi66hB for ; Thu, 28 Jan 2010 07:25:05 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 6AA5E3A680E for ; Thu, 28 Jan 2010 07:25:05 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o0SFPFfa004995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 09:25:15 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o0SFPE96007976; Thu, 28 Jan 2010 09:25:15 -0600 (CST) Message-ID: <4B61AC59.8010600@alcatel-lucent.com> Date: Thu, 28 Jan 2010 09:25:13 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Hibbard References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B210DA9.90501@alcatel-lucent.com> <01DD632E-C839-4965-BB4E-0F063D0871B0@edvina.net> <932F6A87-D112-4E9D-913E-9AF518E6891E@cisco.com> <4B608485.20309@alcatel-lucent.com> <1A6D7EFA-3502-4B12-AE15-7A52535DAE24@edvina.net> <4B608B4F.4000304@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 15:25:06 -0000 Brian Hibbard wrote: > So, we should add an admonition in section 6 "Additional Test > Scenarios" to avoid using IP addrs in SAN if possible, and reference > sec 7.5 of domain-certs? Brian: No matter how strongly we admonish against this, those that want to use IP addresses will do so (sometimes in a closed lab setting, people just use raw IP addresses instead of bothering to set up a DNS infrastructure.) I think the handling of raw IP addresses is well covered by domain-certs and since you already have a reference to that, IMHO it suffices. > Is it beneficial to cite the specific issue > of Record-Route? I was thinking of paraphrasing Cullen's earlier > comment. Of course, if someone wants to take a stab at > word-crafting this, I'm sure it would be well received. AFAICT, this is worded in domain-certs already in S7.5, viz: If a proxy adds a Record-Route when forwarding a request with the expectation that the route is to use secure connections, the proxy MUST insert into the Record-Route header a URI that corresponds to an identity for which the proxy has a certificate; if the proxy does not insert such a URI, then creation of a secure connection using the value from the Record-Route as the AUS will be impossible. Feel free to use the same wordings, or simply have a reference to that section. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From brian@estacado.net Thu Jan 28 12:44:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39FF23A6807 for ; Thu, 28 Jan 2010 12:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nOOHJ0UhLGK for ; Thu, 28 Jan 2010 12:44:13 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 966E93A6894 for ; Thu, 28 Jan 2010 12:44:12 -0800 (PST) Received: from [192.168.1.106] (cpe-76-182-241-151.tx.res.rr.com [76.182.241.151]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o0SKhb46007805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jan 2010 14:43:42 -0600 (CST) (envelope-from brian@estacado.net) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Hibbard In-Reply-To: <4B61AC59.8010600@alcatel-lucent.com> Date: Thu, 28 Jan 2010 14:43:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1015E926-7320-4050-B39B-077642369519@estacado.net> References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B210DA9.90501@alcatel-lucent.com> <01DD632E-C839-4965-BB4E-0F063D0871B0@edvina.net> <932F6A87-D112-4E9D-913E-9AF518E6891E@cisco.com> <4B608485.20309@alcatel-lucent.com> <1A6D7EFA-3502-4B12-AE15-7A52535DAE24@edvina.net> <4B608B4F.4000304@alcatel-lucent.com> <4B61AC59.8010600@alcatel-lucent.com> To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.1077) Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 20:44:15 -0000 Hi Vijay, You're totally right that there will be folks that will still use IP = addresses, regardless of how much lead shot they have to dig out of = their feet. My only thinking on it was that perhaps some of those folks = might make better decisions if they understood *why*. Of course, I'm = second guessing them, and maybe I shouldn't. =20 How about something like this: "Note that if IP addresses are used in subjectAltName, there are = important ramifications regarding the use of Record-Route headers that = also need to be considered. See section 7.5 of domain-certs[??]" Thanks for the input, -b On Jan 28, 2010, at 9:25 AM, Vijay K. Gurbani wrote: > Brian Hibbard wrote: >> So, we should add an admonition in section 6 "Additional Test >> Scenarios" to avoid using IP addrs in SAN if possible, and reference >> sec 7.5 of domain-certs? =20 >=20 > Brian: No matter how strongly we admonish against this, those that > want to use IP addresses will do so (sometimes in a closed lab > setting, people just use raw IP addresses instead of bothering > to set up a DNS infrastructure.) >=20 > I think the handling of raw IP addresses is well covered > by domain-certs and since you already have a reference > to that, IMHO it suffices. >=20 >> Is it beneficial to cite the specific issue >> of Record-Route? I was thinking of paraphrasing Cullen's earlier >> comment. Of course, if someone wants to take a stab at >> word-crafting this, I'm sure it would be well received. >=20 > AFAICT, this is worded in domain-certs already in S7.5, viz: >=20 > If a proxy adds a Record-Route when forwarding a request with the > expectation that the route is to use secure connections, the proxy > MUST insert into the Record-Route header a URI that corresponds to an > identity for which the proxy has a certificate; if the proxy does not > insert such a URI, then creation of a secure connection using the > value from the Record-Route as the AUS will be impossible. >=20 > Feel free to use the same wordings, or simply have a reference > to that section. >=20 > Thanks, >=20 > - vijay > --=20 > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ From vkg@alcatel-lucent.com Thu Jan 28 12:45:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F11F3A695A for ; Thu, 28 Jan 2010 12:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPR82exl9m8E for ; Thu, 28 Jan 2010 12:45:50 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id B2AF13A6945 for ; Thu, 28 Jan 2010 12:45:50 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o0SKk34e022091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 14:46:03 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o0SKk3PW018439; Thu, 28 Jan 2010 14:46:03 -0600 (CST) Message-ID: <4B61F78B.4010208@alcatel-lucent.com> Date: Thu, 28 Jan 2010 14:46:03 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Hibbard References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B210DA9.90501@alcatel-lucent.com> <01DD632E-C839-4965-BB4E-0F063D0871B0@edvina.net> <932F6A87-D112-4E9D-913E-9AF518E6891E@cisco.com> <4B608485.20309@alcatel-lucent.com> <1A6D7EFA-3502-4B12-AE15-7A52535DAE24@edvina.net> <4B608B4F.4000304@alcatel-lucent.com> <4B61AC59.8010600@alcatel-lucent.com> <1015E926-7320-4050-B39B-077642369519@estacado.net> In-Reply-To: <1015E926-7320-4050-B39B-077642369519@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 20:45:51 -0000 Brian Hibbard wrote: > How about something like this: "Note that if IP addresses are used in > subjectAltName, there are important ramifications regarding the use > of Record-Route headers that also need to be considered. See section > 7.5 of domain-certs[??]" Brian: Works for me. Thanks for getting this ironed out. Ciao, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From vkg@alcatel-lucent.com Thu Jan 28 13:33:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7864F3A67FC for ; Thu, 28 Jan 2010 13:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hsvuf+0Y1BUJ for ; Thu, 28 Jan 2010 13:33:37 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 7F58F3A6828 for ; Thu, 28 Jan 2010 13:33:37 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o0SLXs9i014561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 15:33:54 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o0SLXsMV000835; Thu, 28 Jan 2010 15:33:54 -0600 (CST) Message-ID: <4B6202C0.2080404@lucent.com> Date: Thu, 28 Jan 2010 15:33:52 -0600 From: "Vijay K. Gurbani" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Robert Sparks Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: SIPCORE Subject: [sipcore] sip-ipv6-abnf-fix-04 submitted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 21:33:38 -0000 Robert: I have submitted draft-ietf-sip-ipv6-abnf-fix-04 following our conversation a couple of weeks ago on this. Hopefully this should get in your AD workflow, and assuming the conflict with the generic URI ABNF (related to the [] symbols) has been solved, then we can move this work forward. The latest version is at: http://www.ietf.org/internet-drafts/draft-ietf-sip-ipv6-abnf-fix-04.txt Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From christer.holmberg@ericsson.com Fri Jan 29 04:06:07 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E053A68FB for ; Fri, 29 Jan 2010 04:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.993 X-Spam-Level: X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtXUZXpy+6iN for ; Fri, 29 Jan 2010 04:06:06 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 152333A688D for ; Fri, 29 Jan 2010 04:06:05 -0800 (PST) X-AuditID: c1b4fb24-b7c64ae000005cb7-a6-4b62cf42c990 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 9E.18.23735.24FC26B4; Fri, 29 Jan 2010 13:06:26 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 29 Jan 2010 13:06:26 +0100 From: Christer Holmberg To: SIPCORE Date: Fri, 29 Jan 2010 13:06:25 +0100 Thread-Topic: Draft new version: draft-ietf-sipcore-info-events-06 Thread-Index: Acqg23r/X1/jFubpSSaxtE9zznoAyQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FF84A09F50A6DC48ACB6714F4666CC743C57135FDDESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Gonzalo Camarillo , Eric Subject: [sipcore] Draft new version: draft-ietf-sipcore-info-events-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 12:06:07 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC743C57135FDDESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of the info draft. I did the changes regaring the IANA review of info packages, and some edito= rial fixes. Regards, Christer --_000_FF84A09F50A6DC48ACB6714F4666CC743C57135FDDESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I've submitted a new version of the info draft.
 
I did the changes regaring the IANA review of info pa= ckages, and some editorial fixes.
 
Regards,
 
Christer
 
 --_000_FF84A09F50A6DC48ACB6714F4666CC743C57135FDDESESSCMS0354e_-- From root@core3.amsl.com Fri Jan 29 04:15:01 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D3E313A6A04; Fri, 29 Jan 2010 04:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100129121501.D3E313A6A04@core3.amsl.com> Date: Fri, 29 Jan 2010 04:15:01 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-info-events-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 12:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) INFO Method and Package Framework Author(s) : C. Holmberg, et al. Filename : draft-ietf-sipcore-info-events-06.txt Pages : 39 Date : 2010-01-29 This document defines a method, INFO, for the Session Initiation Protocol (SIP) [RFC3261], and an Info Package mechanism. The document obsoletes [RFC2976]. For backward compatibility the document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in [RFC2976], referred to as "legacy INFO Usage" in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-info-events-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-29040403.I-D@ietf.org> --NextPart-- From oej@edvina.net Sun Jan 31 00:53:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8E3D3A6928 for ; Sun, 31 Jan 2010 00:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yi+LzE0Y5+SW for ; Sun, 31 Jan 2010 00:53:11 -0800 (PST) Received: from smtp5.webway.se (smtp5.webway.se [212.3.14.196]) by core3.amsl.com (Postfix) with ESMTP id CC5393A686B for ; Sun, 31 Jan 2010 00:53:09 -0800 (PST) Received: from smtp6.webway.se (smtp2.webway.se [87.96.134.128]) by smtp5.webway.se (Postfix) with ESMTP id 92D0843F809; Sun, 31 Jan 2010 08:53:37 +0000 (UTC) Received: from [192.168.40.12] (ns.webway.se [87.96.134.125]) by smtp6.webway.se (Postfix) with ESMTPA id 6E515552C41; Sun, 31 Jan 2010 08:55:21 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4B61F78B.4010208@alcatel-lucent.com> Date: Sun, 31 Jan 2010 09:53:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B210DA9.90501@alcatel-lucent.com> <01DD632E-C839-4965-BB4E-0F063D0871B0@edvina.net> <932F6A87-D112-4E9D-913E-9AF518E6891E@cisco.com> <4B608485.20309@alcatel-lucent.com> <1A6D7EFA-3502-4B12-AE15-7A52535DAE24@edvina.net> <4B608B4F.4000304@alcatel-lucent.com> <4B61AC59.8010600@alcatel-lucent.com> <1015E926-7320-4050-B39B-077642369519@estacado.net> <4B61F78B.4010208@alcatel-lucent.com> To: Vijay K. Gurbani X-Mailer: Apple Mail (2.1077) Cc: SIPCORE , Brian Hibbard Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 08:53:11 -0000 28 jan 2010 kl. 21.46 skrev Vijay K. Gurbani: > Brian Hibbard wrote: >> How about something like this: "Note that if IP addresses are used in >> subjectAltName, there are important ramifications regarding the use >> of Record-Route headers that also need to be considered. See section >> 7.5 of domain-certs[??]" >=20 > Brian: Works for me. Thanks for getting this ironed out. I like this. People won't be reading between the lines and understand = that a "SIP URI" means that we prefer domain usage, since that will give = them more functionality. Sometimes, you just have to be extremely clear. Thanks, Brian and Vijay! /O= From dean.willis@softarmor.com Sun Jan 31 10:14:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B60503A688D for ; Sun, 31 Jan 2010 10:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldOMri6JjuCQ for ; Sun, 31 Jan 2010 10:14:49 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id DDDC53A6827 for ; Sun, 31 Jan 2010 10:14:48 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0VIDnVl010183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 31 Jan 2010 12:13:50 -0600 Message-Id: <83CBA835-4E1B-43ED-858F-558160C4A5D4@softarmor.com> From: Dean Willis To: Cullen Jennings In-Reply-To: <47CBDB59-01C6-4DD0-B3BD-A59073BCC2D0@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 31 Jan 2010 12:13:42 -0600 References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B310591.7070808@alcatel-lucent.com> <4B32DD8F.7050402@softarmor.com> <47CBDB59-01C6-4DD0-B3BD-A59073BCC2D0@cisco.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 18:14:49 -0000 On Jan 27, 2010, at 12:02 PM, Cullen Jennings wrote: > > On Dec 23, 2009, at 8:18 PM, Dean Willis wrote: > >> Vijay K. Gurbani wrote: >> >>> Here is a table that contains the number of TLS implementations >>> since SIPit 16: >> >> The adoption rate of TLS peaked a couple of years back, and has >> been steadily declining since? That should tell us something >> important. Like, maybe nobody can figure out how to implement this >> stuff, nobody actually uses it, or nobody runs SIP on a hostile >> network. Not sure which is the case, here. >> >> -- >> Dean > > Dean, I don't buy this argument in the slightest. The prevalence of > something at SIPit has close to nothing to do with the deployment > prevalence or the number of products that support it. Most widely > distributed mainstream SIP products are not taken to SIPit at all > because the value proposition of SIPIit is mostly around helping fix > new things where a vendor does not have significant experience to > get them right without showing a pre release version of a product to > your competitors. For example, the amount of TLS at SIPit exceeds > the Video at SIPit, yet I hardly think you can come to the > conclusions that therefore the video over IP market it really small. > Okay. Show me a current large-scale SIP deployment that uses TLS, and I'll show you a widespread adoption rate for TLS that is roughly comparable to the TLS implementation rate at SIPit. -- Dean From oej@edvina.net Sun Jan 31 23:36:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD2CB3A6849 for ; Sun, 31 Jan 2010 23:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTPA7urRcSbi for ; Sun, 31 Jan 2010 23:36:15 -0800 (PST) Received: from smtp5.webway.se (smtp5.webway.se [212.3.14.196]) by core3.amsl.com (Postfix) with ESMTP id 801883A68B3 for ; Sun, 31 Jan 2010 23:36:15 -0800 (PST) Received: from smtp6.webway.se (smtp2.webway.se [87.96.134.128]) by smtp5.webway.se (Postfix) with ESMTP id A367E43F81F; Mon, 1 Feb 2010 07:36:47 +0000 (UTC) Received: from [192.168.40.12] (ns.webway.se [87.96.134.125]) by smtp6.webway.se (Postfix) with ESMTPA id 7CA8C552C41; Mon, 1 Feb 2010 07:38:33 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <83CBA835-4E1B-43ED-858F-558160C4A5D4@softarmor.com> Date: Mon, 1 Feb 2010 08:36:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> <7F45E9F5-ADFF-42D4-9505-882A5A19E198@cisco.com> <4B310591.7070808@alcatel-lucent.com> <4B32DD8F.7050402@softarmor.com> <47CBDB59-01C6-4DD0-B3BD-A59073BCC2D0@cisco.com> <83CBA835-4E1B-43ED-858F-558160C4A5D4@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 07:36:17 -0000 31 jan 2010 kl. 19.13 skrev Dean Willis: >=20 > On Jan 27, 2010, at 12:02 PM, Cullen Jennings wrote: >=20 >>=20 >> On Dec 23, 2009, at 8:18 PM, Dean Willis wrote: >>=20 >>> Vijay K. Gurbani wrote: >>>=20 >>>> Here is a table that contains the number of TLS implementations >>>> since SIPit 16: >>>=20 >>> The adoption rate of TLS peaked a couple of years back, and has been = steadily declining since? That should tell us something important. Like, = maybe nobody can figure out how to implement this stuff, nobody actually = uses it, or nobody runs SIP on a hostile network. Not sure which is the = case, here. >>>=20 >>> -- >>> Dean >>=20 >> Dean, I don't buy this argument in the slightest. The prevalence of = something at SIPit has close to nothing to do with the deployment = prevalence or the number of products that support it. Most widely = distributed mainstream SIP products are not taken to SIPit at all = because the value proposition of SIPIit is mostly around helping fix new = things where a vendor does not have significant experience to get them = right without showing a pre release version of a product to your = competitors. For example, the amount of TLS at SIPit exceeds the Video = at SIPit, yet I hardly think you can come to the conclusions that = therefore the video over IP market it really small. >>=20 >=20 > Okay. Show me a current large-scale SIP deployment that uses TLS, and = I'll show you a widespread adoption rate for TLS that is roughly = comparable to the TLS implementation rate at SIPit. >=20 I won't get into the debate about adoption rate, but can report that we = have focused a bit more on TLS during the last couple of SIPits. During = the SIPit in New Hampshire in September 2009, Nils Ohlmeier and I set up = a large set of automated tests and also had a short seminar to educate = people about general TLS/PKI and the implementation in SIP. Thanks to = the self-tests and the training there was a lot of TLS testing going on = and we came much more detailed in the group tests than I've seen before.=20= I hope that will have an impact on implementations out there. Robert has = been working to set up a permanent SIPit test bed with these tests and a = few other self-tests that has been around on SIPits. /O=