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

Shida Schubert <shida@agnada.com> Fri, 17 June 2011 00:30 UTC

Return-Path: <shida@agnada.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB2D1F0C58 for <sipcore@ietfa.amsl.com>; Thu, 16 Jun 2011 17:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.151
X-Spam-Level:
X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=1.113, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhS8n6P9weZ8 for <sipcore@ietfa.amsl.com>; Thu, 16 Jun 2011 17:30:08 -0700 (PDT)
Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.14.8]) by ietfa.amsl.com (Postfix) with SMTP id 0BC931F0C4E for <sipcore@ietf.org>; Thu, 16 Jun 2011 17:30:07 -0700 (PDT)
Received: (qmail 19307 invoked from network); 17 Jun 2011 00:29:31 -0000
Received: from gator465.hostgator.com (69.56.174.130) by gateway04.websitewelcome.com with SMTP; 17 Jun 2011 00:29:31 -0000
Received: from [125.192.75.244] (port=58011 helo=[192.168.1.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <shida@agnada.com>) id 1QXMwl-0001z6-8q; Thu, 16 Jun 2011 19:30:04 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-1--749079247
From: Shida Schubert <shida@agnada.com>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E36022D@ESESSCMS0356.eemea.ericsson.se>
Date: Fri, 17 Jun 2011 09:30:02 +0900
Message-Id: <2FDD10D8-6DF3-4D77-B300-C05C2AB5D3A2@agnada.com>
References: <4DEC205A.5040503@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E36022D@ESESSCMS0356.eemea.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator465.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - agnada.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: flh1agj244.tky.mesh.ad.jp ([192.168.1.3]) [125.192.75.244]:58011
X-Source-Auth: shida@agnada.com
X-Email-Count: 3
X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t
X-Mailman-Approved-At: Thu, 16 Jun 2011 18:59:01 -0700
Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org, "SIPCORE \(Session Initiation Protocol Core\) WG" <sipcore@ietf.org>, SIPCORE Chairs <sipcore-chairs@tools.ietf.org>, Robert Sparks <RjS@nostrum.com>
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 17 Jun 2011 00:30:09 -0000

Hi Christer;

 Thanks for the comments and for reviewing the draft.

 My comments inline..

On Jun 10, 2011, at 6:08 AM, Christer Holmberg wrote:

> Hi,
>  
> 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.

 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."

>  
>  
> 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? :-)

>  
>  
> 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.
>  

 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 
R-URI. 

>  
> 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)

>  
>  
> 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".

 I agree.

>  
>  
> 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.
>  

 Sounds good. 

>  
> 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.

 We thought we were pretty careful with this as John has pointed these out before. 

 We will go through the draft and make sure there is consistency with the wording. 

 Thanks
  Shida

>  
>  
> Regards,
>  
> Christer
> 
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: 6. kesäkuuta 2011 3:34
> To: SIPCORE (Session Initiation Protocol Core) WG
> Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org; 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:
> 
> http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis
> 
> Any comments on the document should be sent to the SIPCORE mailing list.
> 
>     Thanks,
>     Paul