Re: [cuss] WGLC commentsfor draft-ietf-cuss-sip-uui-isdn

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Fri, 13 December 2013 18:06 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: cuss@ietfa.amsl.com
Delivered-To: cuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC0E1AE376 for <cuss@ietfa.amsl.com>; Fri, 13 Dec 2013 10:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMkH8uehhnmA for <cuss@ietfa.amsl.com>; Fri, 13 Dec 2013 10:06:06 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id A676F1AE325 for <cuss@ietf.org>; Fri, 13 Dec 2013 10:06:06 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rBDI5tcv025006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Dec 2013 12:05:56 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rBDI5s5t018319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 19:05:54 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 13 Dec 2013 19:05:54 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Andrew Allen <aallen@blackberry.com>, "cuss@ietf.org" <cuss@ietf.org>
Thread-Topic: WGLC commentsfor draft-ietf-cuss-sip-uui-isdn
Thread-Index: Ac7ms5+uqD1lEgYcTAytxv9IVdFQqgReM1aA
Date: Fri, 13 Dec 2013 18:05:53 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0F9109@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <BBF5DDFE515C3946BC18D733B20DAD2338E677AB@XMB104ADS.rim.net>
In-Reply-To: <BBF5DDFE515C3946BC18D733B20DAD2338E677AB@XMB104ADS.rim.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0F9109FR712WXCHMBA11zeu_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Subject: Re: [cuss] WGLC commentsfor draft-ietf-cuss-sip-uui-isdn
X-BeenThere: cuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" <cuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cuss>, <mailto:cuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cuss/>
List-Post: <mailto:cuss@ietf.org>
List-Help: <mailto:cuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cuss>, <mailto:cuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Dec 2013 18:06:12 -0000

See below

Keith

________________________________
From: cuss [mailto:cuss-bounces@ietf.org] On Behalf Of Andrew Allen
Sent: 21 November 2013 15:32
To: cuss@ietf.org
Subject: [cuss] WGLC commentsfor draft-ietf-cuss-sip-uui-isdn


I have reviewed draft-ietf-cuss-sip-uui-isdn

Here are some NITS

General: inconsistent use of User-to-User (sometimes without hyphens and sometimes lower case u)

Section 3.1

      The maximum number of octets of user information that can be
      transported in 128 octets plus a protocol discriminator.

SHOULD BE


      The maximum number of octets of user information that can be

      transported is 128 octets plus a protocol discriminator.

KED: Done

 This sentence doesn't make sense to me. I think it needs rephrasing:


        Only a single user information can be transported in each message.

KED: As I don't understand what you don't understand, I do not know how to revise. It is saying you cannot put two user inforamations in a message, i.e. SETUP can only have one, CONNECT can only have one, and so on. Tell me what you want.

Section 6


      What happens to User-to-User header fields relating to different

      packages is outside the scope of this document.

READS BETTER AS


      What happens to User-to-User header fields relating to other

      packages is outside the scope of this document.


Done

Section 8
   The UAS MAY include the User-to-User header field in responses to the
   initial INVITE request, or the BYE requests or responses for the
   dialog, only where the original INVITE request included a User-to-
   User header field with the "purpose" header field parameter to "isdn-
   uui", or where no "purpose" header field parameter was included.

SHOULD BE

   The UAS MAY include the User-to-User header field in responses to the
   initial INVITE request, or the BYE requests or responses for the
  dialog, only where the original INVITE request included a User-to-
   User header field with the "purpose" header field parameter set to "isdn-
   uui", or where no "purpose" header field parameter was included.


   When receiving UUI, when multiple User-to-User header fields are
   received from the originating user in the same request with the
   "purpose" header field parameter to "isdn-uui", or with no "purpose"
   header field parameter, or with some combination of these, the UAC
   MUST discard all these header fields.

SHOULD BE

   When receiving UUI, when multiple User-to-User header fields are
   received from the originating user in the same request with the
   "purpose" header field parameter set to "isdn-uui", or with no "purpose"
   header field parameter, or with some combination of these, the UAC
   MUST discard all these header fields.

Done. Also discovered another similar instance.

 Section 9

   A receiving
   SIP entity MUST ignore a received User-to-User header field if the
   "content" header field parameter is present and the value is some
   other value that "isdn-uui".

SHOULD BE

   A receiving
   SIP entity MUST ignore a received User-to-User header field if the
   "content" header field parameter is present and the value is some
   other value than "isdn-uui".

Done

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.