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

Christer Holmberg <> Fri, 17 June 2011 07:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7993321F84B2 for <>; Fri, 17 Jun 2011 00:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.532
X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id who1KxWORezs for <>; Fri, 17 Jun 2011 00:25:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9BD1F21F84B1 for <>; Fri, 17 Jun 2011 00:25:49 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-7b-4dfb017ca446
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 0B.BC.09774.C710BFD4; Fri, 17 Jun 2011 09:25:48 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Fri, 17 Jun 2011 09:25:47 +0200
From: Christer Holmberg <>
To: Shida Schubert <>
Date: Fri, 17 Jun 2011 09:25:47 +0200
Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis
Thread-Index: AcwskE2KA3YSDlZTQ1ieRnsW6pVr1wAKRjFg
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
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 (Session Initiation Protocol Core) WG" <>, SIPCORE Chairs <>, 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: Fri, 17 Jun 2011 07:25:50 -0000

Hi Shida, 
>>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.
>	 I think this is already described in the section 10.4. 
>	 "In the latter case, the specific header parameter field in the Contact
>	   header becomes the header field parameter that is used in the hi-
>	   target-param in the hi-entry when the request is retargeted."

The text says what you use it for, but not how it was inserted in the Contact in the first place.


>>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.
>Are you talking about adding target-param based on ENUM lookup or simply recording the transformation/resolution in H-I? 


>Anyway, do you want to suggest some text as a co-author of the draft? :-)

Sure :) 

But, it is a little unclear to me what target-param (if any), I would include, so I would like that to get soreted out first.

>>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, 
>I don't know if we need to add anything specific for this. The draft doesn't limit the 
>behavior of the entity recording H-I to only record SIP-URI, it just says to record the 

Based on the comments I get, the text seems to indicate that you shouldn't insert a Tel in a History-Info in the first place. Instead you should transform it to a SIP-URI before inserting it.

But, I can think of some text for that also, because it's related to the previous comments.


>>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.
>I guess we can call it a "registrar" or at the first instance include a text used in 
>RFC 3327. 
>	 REGISTRAR or a "home proxy" (a proxy serving as the terminal point for routing an address-of-record)

I think it occurs only once, but as long as there is a definition (or a reference to a definition) I don't mind if it's used.