Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments
Peter Musgrave <peter.musgrave@magorcorp.com> Tue, 03 August 2010 13:55 UTC
Return-Path: <peter.musgrave@magorcorp.com>
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 10BF63A67E1 for <sipcore@core3.amsl.com>; Tue, 3 Aug 2010 06:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.164
X-Spam-Level:
X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 aO-Efc-ISYLN for <sipcore@core3.amsl.com>; Tue, 3 Aug 2010 06:55:35 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 19FF43A6848 for <sipcore@ietf.org>; Tue, 3 Aug 2010 06:55:35 -0700 (PDT)
Received: by qyk8 with SMTP id 8so2920495qyk.10 for <sipcore@ietf.org>; Tue, 03 Aug 2010 06:56:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.183.132 with SMTP id cg4mr1141962qcb.111.1280843763154; Tue, 03 Aug 2010 06:56:03 -0700 (PDT)
Received: by 10.229.34.14 with HTTP; Tue, 3 Aug 2010 06:56:03 -0700 (PDT)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850CA5BE@ESESSCMS0356.eemea.ericsson.se>
References: <7F2072F1E0DE894DA4B517B93C6A05850B5C23@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05850CA572@ESESSCMS0356.eemea.ericsson.se> <AANLkTi=qcrUgdpov0BmFZA07eUCiW2MuToHX9gg3JhU1@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05850CA5BE@ESESSCMS0356.eemea.ericsson.se>
Date: Tue, 03 Aug 2010 09:56:03 -0400
Message-ID: <AANLkTim7Z45rU2YKTvD09+h6jQxc881LZg5n5A+a=AX4@mail.gmail.com>
From: Peter Musgrave <peter.musgrave@magorcorp.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Aug 2010 13:55:36 -0000
All ok with me. Thanks, Peter On Tue, Aug 3, 2010 at 8:52 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote: > > Hi, > >>>>4.4 para 2. This paragraph is one sentence. I read it many times - I >>>>gave up. >>> >>>I tried to make the paragraph more readable. It still >>>contain a long sentence, but please let me know if it's >>>easier to understand now: >>> >>> "When a SIP entity creates or receives a response, and the >>> adjacent downstream SIP entity that sent the associated request >>> indicated willingness to send keep-alives, if the SIP entity >>> is willing to receive keep-alives associated with the registration >>> (in case of a REGISTER response), or the dialog (in case of a >>> response to an initial request for a dialog, or a response to a mid-dialog >>> target refresh request), from the adjacent downstream SIP entity it MUST >>> add a parameter value to the "keep" parameter, before sending >>> or forwarding the response. The parameter can contain a recommended keep-alive >>> frequency, or a zero value." >>> >>Better - but I am still getting a stack overflow since I parse "When... A or B ..and...if..or.." > > You should take a look at some 3GPP specifications :) > >>How about: >> >>If a request from a downstream SIP element indicated support >>for keep-alives and the upstream element also supports >>keep-alives then the response from the upstream element MUST >>contain a parameter value for the "keep". This value can >>contain a recommended keep-alive value or a zero value. >> >>(I have cut out the stuff on what kind of request it is - I >>am not sure if this distinction was vital?) > > I think it is important to indicate the "scope" (registration or dialog) for which the entity > Indicates willingess to receive keep-alives. > > I guess the "in case of..." parts could be removed. > > Also, the "the response from the upstream element" is a little confusing, because it seems to refer to some other entity (the "reference point" in the text is the SIP entity that inserts the value in the keep header). I would like to use "the SIP entity", as elsewhere in the document. > > Regards, > > Christer
- Re: [sipcore] draft-ietf-sipcore-keep - Peter's c… Christer Holmberg
- Re: [sipcore] draft-ietf-sipcore-keep - Peter's c… Christer Holmberg
- Re: [sipcore] draft-ietf-sipcore-keep - Peter's c… Peter Musgrave
- Re: [sipcore] draft-ietf-sipcore-keep - Peter's c… Christer Holmberg
- Re: [sipcore] draft-ietf-sipcore-keep - Peter's c… Peter Musgrave
- Re: [sipcore] draft-ietf-sipcore-keep - Peter's c… Paul Kyzivat
- Re: [sipcore] draft-ietf-sipcore-keep - Peter's c… Christer Holmberg
- Re: [sipcore] draft-ietf-sipcore-keep - Peter's c… Paul Kyzivat
- Re: [sipcore] draft-ietf-sipcore-keep - Peter's c… Christer Holmberg
- Re: [sipcore] draft-ietf-sipcore-keep - Peter's c… Paul Kyzivat
- Re: [sipcore] draft-ietf-sipcore-keep - Peter's c… Christer Holmberg
- Re: [sipcore] draft-ietf-sipcore-keep - New draft… Paul Kyzivat