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

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 13 Dec 2013 18:05:53 +0000

See below

Keith

________________________________
From: cuss [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 21 November 2013 15:32
To: [email-masked]
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.