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

Shida Schubert <> Mon, 27 June 2011 07:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E82C21F85D4 for <>; Mon, 27 Jun 2011 00:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.689
X-Spam-Status: No, score=-99.689 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ol0ihvZfEDCO for <>; Mon, 27 Jun 2011 00:13:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B0A3221F85F0 for <>; Mon, 27 Jun 2011 00:13:20 -0700 (PDT)
Received: from [] (port=56323 helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <>) id 1Qb60S-0004uW-LE; Mon, 27 Jun 2011 02:13:17 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Shida Schubert <>
In-Reply-To: <>
Date: Mon, 27 Jun 2011 16:13:14 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Cullen Jennings <>
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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Source-Sender: ([]) []:56323
X-Email-Count: 2
X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t
Cc:, " WG" <>
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: Mon, 27 Jun 2011 07:13:26 -0000

Hi Cullen;

 Thanks for your review and comments. 

 My comments inline.

On Jun 22, 2011, at 8:08 AM, Cullen Jennings wrote:

> Privacy issue: There is no way to know that the next downstream proxy support the processing required by the privacy header. 

 That is generally true for any privacy mechanism based on 3323, this is not a problem limited to 4244/4244bis. 

 Most deployments I am aware of have these servers that handle the privacy. 

> What's this for: The most concrete use is making sure a call arriving at a voice mail servers goes to the correct mailbox. However, the draft is woefully underspecified to be able to implement this from the draft. This draft specifies a bunch of data that can get dumped in a bag, but to allow interoperable implementation, it needs to say how one could use that data for some actually feature. 

 We tried to cover these use-cases in section 3.3/3.4 of 4244bis-callflow draft.

 I am not sure, the example will satisfy you, but let me know what you think.

> As a coauthor of 4244, I agree this draft is better than 4244 but I don't think it is ready to publish.Given what we have learned about 4244 since it was published, I would support 4244 being changed to historic. 
> Does it work? Consider text such as  
>       Note, this would be
>       the original AoR if all the entities involved support the
>       History-info header field and there is absence of an "mp" header
>       field parameter prior to the "rc" header field parameter in the
>       hi-target-param in the History-info header field.  However, there
>       is no guarantee that all entities will support History-Info, thus
>       the hi-entry that matches the value of the "rc" parameter of the
>       first hi-entry with an "rc" parameter in the hi-target-param
>       within the domain associated with the target URI at the
>       destination is more likely to be useful.
> This amounts to you might some information you want at X but then again you might not. The whole draft is like this - it's pretty hard to imagine this will reliably work for nearly any purpose I can think of given the limitations of the draft. 

 I think it definitely has some uses and is valuable, even it is only supported within one domain 
which intend to use this. 

 Sure, there is a good chance that some information may get lost or may not exist in the 
first place when it crosses the domain due to the reason you mentioned above, but as long 
as all the entities within a domain who wants to use it, supports it, I believe it provides useful 

> Backwards Compatibly - yes the syntax is backwards compatible but no effort has been put into consider what would happen if some elements in the network were doing 4244 and some where doing 4244bis.

 I am looking at this in more details right now, as I had some internal people form my company 
showing concern about this as well. I am hoping to add the summary of my findings in the next 

> Implementations: I'd like to know about implementations that were going to use this data. And by use, I don't mean write to the history header but instead ones that are going to read from it and use the information for some purpose. 
> Does not meet requirements. As far as I can tell, the draft does not meet the requirements outline in section A.1 of the draft. 

 Do you mind being more specific if it is particular requirement you are talking about or 
are you saying all the requirements aren't satisfied by the mechanism?


> On Jun 5, 2011, at 17:33 , Paul Kyzivat wrote:
>> [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.
>>    Thanks,
>>    Paul
>> _______________________________________________
>> sipcore mailing list
> Cullen Jennings
> For corporate legal information go to: