Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis

Christer Holmberg <> Thu, 09 June 2011 21:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 95C2C11E80FF for <>; Thu, 9 Jun 2011 14:08:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.506
X-Spam-Status: No, score=-7.506 tagged_above=-999 required=5 tests=[AWL=1.092, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FqAHPMAU6W6g for <>; Thu, 9 Jun 2011 14:08:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D69C211E80FC for <>; Thu, 9 Jun 2011 14:08:13 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-00-4df1363ca18d
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 3A.45.20773.C3631FD4; Thu, 9 Jun 2011 23:08:12 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Thu, 9 Jun 2011 23:08:05 +0200
From: Christer Holmberg <>
To: SIPCORE Chairs <>, "SIPCORE (Session Initiation Protocol Core) WG" <>
Date: Thu, 09 Jun 2011 23:08:03 +0200
Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis
Thread-Index: Acwj4WCkAecOmo7GTteRXYIV9OnhoADAwo8A
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585194E36022DESESSCMS0356e_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>, Robert Sparks <>
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Jun 2011 21:08:15 -0000


Some comments, based on feedback I've got from collegues.

1. Usage of "rc" and "mp" in Contact header field (technical)

The document defines the "rc" and "mp" parameters also for the Contact header field. However, it is unclear when and how the parameters would be used in a Contact header field.

2. Tel to Sip transformation: ENUM (technical)

Section 5 talks about transformation from Tel to Sip, according section 19.6.1 of RFC 3261. However, the transformation can also be the result of an ENUM DNS lookup. So, maybe some text should be added, indicating that the transformation can be done based on local configuration (the hostpart of the new SIP-URI needs to be taken from somewhere), or based on an ENUM DNS lookup.

3. Tel to Sip transformation: History-Info (technical)

Related to the previous question, the text doesn't indicate whether the transformation from Tel to Sip should be recorded in an History-Info header field. The Request-URI is, after all, changed.

4. Home proxy (editorial)

The draft mentions "home proxy", but there is no reference or definition for it. I guess it should be "registrar", or something.

5. Out-of-dialog request (editorial)

Section 5 talks about "request not associated with an early or established dialog", while section 6.1 talks about "new or out-of-dialog request". In both cases the text refers to the request that can carry History-Info, so the wording should be consistance. For example "out-of-dialog requests or initial requests for a dialog".

6. Appearence (editorial)

Section 5 says in which message types History-Info "can appear". It would be better to say for which message types the document/specification defines the usage of History-Info.

7. Misc (editorial)

There are, throughout the document, some inconsistance between usage of "header" vs "header field", "this document" vs "this specification", the usage of capital letters for requests and SIP entity names etc, but I guess that can be taken care of by the authors without a list of every occurance here.



From: [] On Behalf Of Paul Kyzivat
Sent: 6. kesäkuuta 2011 3:34
To: SIPCORE (Session Initiation Protocol Core) WG
Cc:; SIPCORE Chairs; Robert Sparks
Subject: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis

[as co-chair]

The current editor of draft-ietf-sipcore-rfc4244bis believes that the document has no remaining technical issues, and is ready for evaluation. Today, we are starting a two-week working group last call period. This last call period ends on Sunday, June 19.

The latest version of the document can be retrieved here:

Any comments on the document should be sent to the SIPCORE mailing list.