From wwwrun@rfc-editor.org Tue Feb 4 11:16:00 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474141A01E0; Tue, 4 Feb 2014 11:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.953 X-Spam-Level: X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uffEpG4JiOgG; Tue, 4 Feb 2014 11:15:58 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id D80631A01DF; Tue, 4 Feb 2014 11:15:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 7CAF67FC159; Tue, 4 Feb 2014 11:15:57 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140204191557.7CAF67FC159@rfc-editor.org> Date: Tue, 4 Feb 2014 11:15:57 -0800 (PST) Cc: drafts-update-ref@iana.org, sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 7044 on An Extension to the Session Initiation Protocol (SIP) for Request History Information X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 19:16:00 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7044 Title: An Extension to the Session Initiation Protocol (SIP) for Request History Information Author: M. Barnes, F. Audet, S. Schubert, J. van Elburg, C. Holmberg Status: Standards Track Stream: IETF Date: February 2014 Mailbox: mary.ietf.barnes@gmail.com, francois.audet@skype.net, shida@ntt-at.com, ietf.hanserik@gmail.com, christer.holmberg@ericsson.com Pages: 36 Characters: 85068 Obsoletes: RFC 4244 I-D Tag: draft-ietf-sipcore-rfc4244bis-12.txt URL: http://www.rfc-editor.org/rfc/rfc7044.txt This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. This document obsoletes RFC 4244. This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From pkyzivat@alum.mit.edu Tue Feb 4 11:33:43 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126021A01BE for ; Tue, 4 Feb 2014 11:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX8tCIxezHTe for ; Tue, 4 Feb 2014 11:33:41 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id CD2121A0035 for ; Tue, 4 Feb 2014 11:33:40 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta15.westchester.pa.mail.comcast.net with comcast id NHv81n0031ZXKqc5FKZg8P; Tue, 04 Feb 2014 19:33:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id NKZg1n00A3ZTu2S3hKZgcD; Tue, 04 Feb 2014 19:33:40 +0000 Message-ID: <52F14093.9040506@alum.mit.edu> Date: Tue, 04 Feb 2014 14:33:39 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: SIPCORE References: <20140204191557.7CAF67FC159@rfc-editor.org> In-Reply-To: <20140204191557.7CAF67FC159@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391542420; bh=FFzLBEdZZdG5h9m6Td1C8+w3rjiTmkxclxWk/Y8cyGk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=X4uM+161WHSmj9Zg+IuLrRFAovdK0kyrOsjT+1weLcOPMXJYSu9nDC2h8OJe6BTqS Reu/M3LokFyQX3SKdRQpK3AvHWkf305Ay5cgW0HpHDvGolGfJmmkLtqmP2pGTxt1oR 6i16deCdsYnlnZMmhIFVC8rb6fzBxSwUayHEfT1DDLo/J5RRwJbezK+5fh1nsLkkO1 akATmI/LCdH/2dlcMFWUBM6E0vSWBDOues42/jj5f722Ajh0OsBo3RdkrAsiriFJY2 wJimbwjDOy0zLMNpPqVTrZF6eoYiLyqEbmg70WC5qbdm5G0yaZacqEJbzQeoXb08t/ wWKEW0rPfg6Hw== Subject: [sipcore] Congratulations! draft-barnes-sipcore-rfc4244bis is now RFC 7044 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 19:33:43 -0000 This was a long haul. Thanks to the authors for all their work. Now we can all join them in giving a huge sigh of relief. Thanks, Paul On 2/4/14 2:15 PM, rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 7044 > > Title: An Extension to the Session > Initiation Protocol (SIP) for > Request History Information > Author: M. Barnes, F. Audet, > S. Schubert, J. van Elburg, > C. Holmberg > Status: Standards Track > Stream: IETF > Date: February 2014 > Mailbox: mary.ietf.barnes@gmail.com, > francois.audet@skype.net, > shida@ntt-at.com, > ietf.hanserik@gmail.com, > christer.holmberg@ericsson.com > Pages: 36 > Characters: 85068 > Obsoletes: RFC 4244 > > I-D Tag: draft-ietf-sipcore-rfc4244bis-12.txt > > URL: http://www.rfc-editor.org/rfc/rfc7044.txt > > This document defines a standard mechanism for capturing the history > information associated with a Session Initiation Protocol (SIP) > request. This capability enables many enhanced services by providing > the information as to how and why a SIP request arrives at a specific > application or user. This document defines an optional SIP header > field, History-Info, for capturing the history information in > requests. The document also defines SIP header field parameters for > the History-Info and Contact header fields to tag the method by which > the target of a request is determined. In addition, this > specification defines a value for the Privacy header field that > directs the anonymization of values in the History-Info header field. > This document obsoletes RFC 4244. > > This document is a product of the Session Initiation Protocol Core Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php > For downloading RFCs, see http://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Fri Feb 7 11:36:53 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967031ACCE3 for ; Fri, 7 Feb 2014 11:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZGzS4UH2IJv for ; Fri, 7 Feb 2014 11:36:50 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFA41A0465 for ; Fri, 7 Feb 2014 11:36:50 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id ar20so1949336iec.10 for ; Fri, 07 Feb 2014 11:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G8DujM8VWzKMDES/NqgF6UERTAoSp/B1Vz8bbqkL2Ts=; b=h0+bh0sSef9B8DQI0OK0+LUaa0Orou+u3NdKWztmR2k3mjV1TdmMsJdV+ARUsmGGFM diLlGNhmm1zBgfjqnnAaR0fMO570IuQDwh3kWKU8VowB+1tXGEzz+mUyp9RnVQ78vvA9 fjALJ1zKep4CaA0VFEG/XdwI7uuyCBh5uumOYwwcqg4lhwqQz8rToKVw9c8wOboC1S6/ QkMr5PVIhzkCKFfBSx7QrKZ5KWdr5KC6Yz1IqNqfo+LdOHcHF+fXCXDfdUTzzT2dtKOl A85hxics5SYWqP++nCjRRURIM80UFfXe2BJ8Rp2MXa/NrxoStPl+JKMA55e/zyPK85e7 Y2cg== MIME-Version: 1.0 X-Received: by 10.42.40.83 with SMTP id k19mr8518981ice.3.1391801810495; Fri, 07 Feb 2014 11:36:50 -0800 (PST) Received: by 10.43.58.137 with HTTP; Fri, 7 Feb 2014 11:36:50 -0800 (PST) In-Reply-To: <52F14093.9040506@alum.mit.edu> References: <20140204191557.7CAF67FC159@rfc-editor.org> <52F14093.9040506@alum.mit.edu> Date: Fri, 7 Feb 2014 13:36:50 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=90e6ba1efbf4832b4c04f1d61c7c Cc: SIPCORE Subject: Re: [sipcore] Congratulations! draft-barnes-sipcore-rfc4244bis is now RFC 7044 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 19:36:53 -0000 --90e6ba1efbf4832b4c04f1d61c7c Content-Type: text/plain; charset=ISO-8859-1 Yes, a huge sigh of relief! Thanks to the WG for their patience and to Dale for his numerous reviews and comments. Mary. On Tue, Feb 4, 2014 at 1:33 PM, Paul Kyzivat wrote: > This was a long haul. > Thanks to the authors for all their work. > Now we can all join them in giving a huge sigh of relief. > > Thanks, > Paul > > On 2/4/14 2:15 PM, rfc-editor@rfc-editor.org wrote: > >> A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 7044 >> >> Title: An Extension to the Session >> Initiation Protocol (SIP) for >> Request History Information >> Author: M. Barnes, F. Audet, >> S. Schubert, J. van Elburg, >> C. Holmberg >> Status: Standards Track >> Stream: IETF >> Date: February 2014 >> Mailbox: mary.ietf.barnes@gmail.com, >> francois.audet@skype.net, >> shida@ntt-at.com, >> ietf.hanserik@gmail.com, >> christer.holmberg@ericsson.com >> Pages: 36 >> Characters: 85068 >> Obsoletes: RFC 4244 >> >> I-D Tag: draft-ietf-sipcore-rfc4244bis-12.txt >> >> URL: http://www.rfc-editor.org/rfc/rfc7044.txt >> >> This document defines a standard mechanism for capturing the history >> information associated with a Session Initiation Protocol (SIP) >> request. This capability enables many enhanced services by providing >> the information as to how and why a SIP request arrives at a specific >> application or user. This document defines an optional SIP header >> field, History-Info, for capturing the history information in >> requests. The document also defines SIP header field parameters for >> the History-Info and Contact header fields to tag the method by which >> the target of a request is determined. In addition, this >> specification defines a value for the Privacy header field that >> directs the anonymization of values in the History-Info header field. >> This document obsoletes RFC 4244. >> >> This document is a product of the Session Initiation Protocol Core >> Working Group of the IETF. >> >> This is now a Proposed Standard. >> >> STANDARDS TRACK: This document specifies an Internet standards track >> protocol for the Internet community,and requests discussion and >> suggestions >> for improvements. Please refer to the current edition of the Internet >> Official Protocol Standards (STD 1) for the standardization state and >> status of this protocol. Distribution of this memo is unlimited. >> >> This announcement is sent to the IETF-Announce and rfc-dist lists. >> To subscribe or unsubscribe, see >> http://www.ietf.org/mailman/listinfo/ietf-announce >> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >> >> For searching the RFC series, see http://www.rfc-editor.org/ >> search/rfc_search.php >> For downloading RFCs, see http://www.rfc-editor.org/rfc.html >> >> Requests for special distribution should be addressed to either the >> author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless >> specifically noted otherwise on the RFC itself, all RFCs are for >> unlimited distribution. >> >> >> The RFC Editor Team >> Association Management Solutions, LLC >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --90e6ba1efbf4832b4c04f1d61c7c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, a huge sigh of relief! =A0 Thanks to the WG for their= patience and to Dale for his numerous reviews and comments. =A0

Mary.=A0


On Tue, Feb 4, 2014 at 1:33 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
This was a long haul.
Thanks to the authors for all their work.
Now we can all join them in giving a huge sigh of relief.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

On 2/4/14 2:15 PM, rfc-editor@rfc-editor.org wrote:
A new Request for Comments is now available in online RFC libraries.


=A0 =A0 =A0 =A0 =A0RFC 7044

=A0 =A0 =A0 =A0 =A0Title: =A0 =A0 =A0An Extension to the Session
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Initiation Protocol (SIP) for =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Request History Information
=A0 =A0 =A0 =A0 =A0Author: =A0 =A0 M. Barnes, F. Audet,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0S. Schubert, J. van Elburg,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0C. Holmberg
=A0 =A0 =A0 =A0 =A0Status: =A0 =A0 Standards Track
=A0 =A0 =A0 =A0 =A0Stream: =A0 =A0 IETF
=A0 =A0 =A0 =A0 =A0Date: =A0 =A0 =A0 February 2014
=A0 =A0 =A0 =A0 =A0Mailbox: =A0 =A0mary.ietf.barnes@gmail.com,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0francois.audet@skype.net,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0shida@ntt-at.com,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ietf.hanserik@gmail.com,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0christer.holmberg@ericsson.com
=A0 =A0 =A0 =A0 =A0Pages: =A0 =A0 =A036
=A0 =A0 =A0 =A0 =A0Characters: 85068
=A0 =A0 =A0 =A0 =A0Obsoletes: =A0RFC 4244

=A0 =A0 =A0 =A0 =A0I-D Tag: =A0 =A0draft-ietf-sipcore-rfc4244bis-12.= txt

=A0 =A0 =A0 =A0 =A0URL: =A0 =A0 =A0 =A0http://www.rfc-editor.org/rfc/rf= c7044.txt

This document defines a standard mechanism for capturing the history
information associated with a Session Initiation Protocol (SIP)
request. =A0This capability enables many enhanced services by providing
the information as to how and why a SIP request arrives at a specific
application or user. =A0This document defines an optional SIP header
field, History-Info, for capturing the history information in
requests. =A0The document also defines SIP header field parameters for
the History-Info and Contact header fields to tag the method by which
the target of a request is determined. =A0In addition, this
specification defines a value for the Privacy header field that
directs the anonymization of values in the History-Info header field.
This document obsoletes RFC 4244.

This document is a product of the Session Initiation Protocol Core Working = Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions=
for improvements. =A0Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and
status of this protocol. =A0Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
=A0 =A0http://www.ietf.org/mailman/listinfo/ietf-announce<= br> =A0 =A0http://mailman.rfc-editor.org/mailman/listinfo/rfc= -dist

For searching the RFC series, see http://www.rfc-editor.org/searc= h/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. =A0Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--90e6ba1efbf4832b4c04f1d61c7c-- From shida@agnada.com Sat Feb 8 15:50:49 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235001A0646 for ; Sat, 8 Feb 2014 15:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.134 X-Spam-Level: * X-Spam-Status: No, score=1.134 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evurS9b1BY8I for ; Sat, 8 Feb 2014 15:50:46 -0800 (PST) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.137.86]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0BA1A041B for ; Sat, 8 Feb 2014 15:50:46 -0800 (PST) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 7E84759929D29; Sat, 8 Feb 2014 17:50:46 -0600 (CST) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 6B26559929CE1 for ; Sat, 8 Feb 2014 17:50:46 -0600 (CST) Received: from [50.184.77.69] (port=61178 helo=[192.168.1.18]) by gator4135.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1WCHfa-0005dw-2P; Sat, 08 Feb 2014 17:50:46 -0600 Content-Type: multipart/alternative; boundary="Apple-Mail=_47E8FFF4-D0E4-4C1A-906D-D159C7FB2A59" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Shida Schubert In-Reply-To: Date: Sat, 8 Feb 2014 15:50:43 -0800 Message-Id: <773CC106-95BB-41F5-BC04-9E12DD5D9346@agnada.com> References: <20140204191557.7CAF67FC159@rfc-editor.org> <52F14093.9040506@alum.mit.edu> To: Mary Barnes X-Mailer: Apple Mail (2.1827) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.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-IP: 50.184.77.69 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [50.184.77.69]:61178 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Cc: SIPCORE Subject: Re: [sipcore] Congratulations! draft-barnes-sipcore-rfc4244bis is now RFC 7044 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 23:50:49 -0000 --Apple-Mail=_47E8FFF4-D0E4-4C1A-906D-D159C7FB2A59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 As Mary stated, thanks to you all!! Shida On Feb 7, 2014, at 11:36 AM, Mary Barnes = wrote: > Yes, a huge sigh of relief! Thanks to the WG for their patience and = to Dale for his numerous reviews and comments. =20 >=20 > Mary.=20 >=20 >=20 > On Tue, Feb 4, 2014 at 1:33 PM, Paul Kyzivat = wrote: > This was a long haul. > Thanks to the authors for all their work. > Now we can all join them in giving a huge sigh of relief. >=20 > Thanks, > Paul >=20 > On 2/4/14 2:15 PM, rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7044 >=20 > Title: An Extension to the Session > Initiation Protocol (SIP) for > Request History Information > Author: M. Barnes, F. Audet, > S. Schubert, J. van Elburg, > C. Holmberg > Status: Standards Track > Stream: IETF > Date: February 2014 > Mailbox: mary.ietf.barnes@gmail.com, > francois.audet@skype.net, > shida@ntt-at.com, > ietf.hanserik@gmail.com, > christer.holmberg@ericsson.com > Pages: 36 > Characters: 85068 > Obsoletes: RFC 4244 >=20 > I-D Tag: draft-ietf-sipcore-rfc4244bis-12.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc7044.txt >=20 > This document defines a standard mechanism for capturing the history > information associated with a Session Initiation Protocol (SIP) > request. This capability enables many enhanced services by providing > the information as to how and why a SIP request arrives at a specific > application or user. This document defines an optional SIP header > field, History-Info, for capturing the history information in > requests. The document also defines SIP header field parameters for > the History-Info and Contact header fields to tag the method by which > the target of a request is determined. In addition, this > specification defines a value for the Privacy header field that > directs the anonymization of values in the History-Info header field. > This document obsoletes RFC 4244. >=20 > This document is a product of the Session Initiation Protocol Core = Working Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see = http://www.rfc-editor.org/search/rfc_search.php > For downloading RFCs, see http://www.rfc-editor.org/rfc.html >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_47E8FFF4-D0E4-4C1A-906D-D159C7FB2A59 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

As Mary stated, thanks to you all!!

 Shida

On Feb 7, 2014, at 11:36 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

Yes, a huge sigh of relief!   Thanks to the WG for their patience and to Dale for his numerous reviews and comments.  

Mary. 


On Tue, Feb 4, 2014 at 1:33 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
This was a long haul.
Thanks to the authors for all their work.
Now we can all join them in giving a huge sigh of relief.

        Thanks,
        Paul

On 2/4/14 2:15 PM, rfc-editor@rfc-editor.org wrote:
A new Request for Comments is now available in online RFC libraries.


         RFC 7044

         Title:      An Extension to the Session
                     Initiation Protocol (SIP) for
                     Request History Information
         Author:     M. Barnes, F. Audet,
                     S. Schubert, J. van Elburg,
                     C. Holmberg
         Status:     Standards Track
         Stream:     IETF
         Date:       February 2014
         Mailbox:    mary.ietf.barnes@gmail.com,
                     francois.audet@skype.net,
                     shida@ntt-at.com,
                     ietf.hanserik@gmail.com,
                     christer.holmberg@ericsson.com
         Pages:      36
         Characters: 85068
         Obsoletes:  RFC 4244

         I-D Tag:    draft-ietf-sipcore-rfc4244bis-12.txt

         URL:        http://www.rfc-editor.org/rfc/rfc7044.txt

This document defines a standard mechanism for capturing the history
information associated with a Session Initiation Protocol (SIP)
request.  This capability enables many enhanced services by providing
the information as to how and why a SIP request arrives at a specific
application or user.  This document defines an optional SIP header
field, History-Info, for capturing the history information in
requests.  The document also defines SIP header field parameters for
the History-Info and Contact header fields to tag the method by which
the target of a request is determined.  In addition, this
specification defines a value for the Privacy header field that
directs the anonymization of values in the History-Info header field.
This document obsoletes RFC 4244.

This document is a product of the Session Initiation Protocol Core Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
   http://www.ietf.org/mailman/listinfo/ietf-announce
   http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--Apple-Mail=_47E8FFF4-D0E4-4C1A-906D-D159C7FB2A59-- From nobody Fri Feb 14 10:59:05 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FAE1A02A3 for ; Fri, 14 Feb 2014 10:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FS5dXylJ_g8v for ; Fri, 14 Feb 2014 10:58:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 026461A0278 for ; Fri, 14 Feb 2014 10:58:58 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 9678F3242AA for ; Fri, 14 Feb 2014 19:58:56 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 7F64927C077 for ; Fri, 14 Feb 2014 19:58:56 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 19:58:56 +0100 From: To: "sipcore@ietf.org" Thread-Topic: New Version Notification for draft-mohali-rfc6044bis-00.txt Thread-Index: AQHPKa0mPZIW1w+f4ESii16XRFYaWpq1GS5g Date: Fri, 14 Feb 2014 18:58:55 +0000 Message-ID: <29855_1392404336_52FE6770_29855_16315_1_8B970F90C584EA4E97D5BAAC9172DBB8141FC680@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20140214174942.25151.514.idtracker@ietfa.amsl.com> In-Reply-To: <20140214174942.25151.514.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.14.91814 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/f0LsfQbrEbNwqwJ9IwtixbIL5Dk Subject: [sipcore] TR: New Version Notification for draft-mohali-rfc6044bis-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:59:02 -0000 SGkgZm9sa3MsDQoNCkZZSQ0KRm9sbG93aW5nIFJGQzcwNDQgcHVibGljYXRpb24gKEhpc3Rvcnkt SW5mbyBiaXMpLCBoZXJlIGlzIGEgZmlyc3QgdmVyc2lvbiBvZiB0aGUgUkZDNjA0NGJpcyAoZHJh ZnQtbW9oYWxpLXJmYzYwNDRiaXMtMDApIHByb3Bvc2luZyBhIG1hcHBpbmcgYmV0d2VlbiBIaXN0 b3J5LUluZm8gaGVhZGVyIGZpZWxkIGFuZCBEaXZlcnNpb24gaGVhZGVyIGZpZWxkIChSRkM1ODA2 KS4NCg0KQmVzdCBSZWdhcmRzLA0KTWFyaWFubmUNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t LS0tDQpEZcKgOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KRW52b3nDqcKgOiB2ZW5kcmVkaSAxNCBmw6l2cmllciAyMDE0IDE4OjUw DQrDgMKgOiBNT0hBTEkgTWFyaWFubmUgSU1UL09MTjsgTU9IQUxJIE1hcmlhbm5lIElNVC9PTE4N Ck9iamV0wqA6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbW9oYWxpLXJmYzYw NDRiaXMtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1vaGFsaS1yZmM2 MDQ0YmlzLTAwLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1hcmlhbm5l IE1vaGFsaSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFm dC1tb2hhbGktcmZjNjA0NGJpcw0KUmV2aXNpb246CTAwDQpUaXRsZToJCU1hcHBpbmcgYW5kIGlu dGVyd29ya2luZyBvZiBEaXZlcnNpb24gaW5mb3JtYXRpb24gQmV0d2VlbiBEaXZlcnNpb24gYW5k IEhpc3RvcnktSW5mbyBIZWFkZXJzIGluIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wg KFNJUCkNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDItMTQNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpQYWdlczoJCTI1DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtbW9oYWxpLXJmYzYwNDRiaXMtMDAudHh0DQpTdGF0dXM6ICAg ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbW9oYWxpLXJmYzYw NDRiaXMvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bW9oYWxpLXJmYzYwNDRiaXMtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFtUaGlzIHZlcnNpb24gb2Yg dGhlIGRvY3VtZW50IGlzIGEgZHJhZnQgdmVyc2lvbiBmb3IgYW4gUkZDNjA0NGJpcw0KICAgdGhh dCB3aWxsIGRlc2NyaWJlIHRoZSBtYXBwaW5nIGJldHdlZW4gdGhlIERpdmVyc2lvbiBoZWFkZXIg ZGVmaW5lZA0KICAgaW4gUkZDNTgwNiBhbmQgdGhlIG5ldyBIaXN0b3J5LUluZm8gaGVhZGVyIGRl ZmluZWQgaW4gUkZDNzA0NC5dDQogICBBbHRob3VnaCB0aGUgU0lQIEhpc3RvcnktSW5mbyBoZWFk ZXIgaXMgdGhlIHNvbHV0aW9uIGFkb3B0ZWQgaW4gSUVURiwNCiAgIHRoZSBub24tc3RhbmRhcmQg RGl2ZXJzaW9uIGhlYWRlciBpcyBuZXZlcnRoZWxlc3MgYWxyZWFkeSBpbXBsZW1lbnRlZA0KICAg YW5kIHVzZWQgZm9yIGNvbnZleWluZyBjYWxsIGRpdmVyc2lvbiByZWxhdGVkIGluZm9ybWF0aW9u IGluIHRoZQ0KICAgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIHNpZ25hbGluZy4N CiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgcmVjb21tZW5kZWQgaW50ZXJ3b3JraW5nIGd1 aWRlbGluZSBiZXR3ZWVuDQogICB0aGUgRGl2ZXJzaW9uIGhlYWRlciBhbmQgdGhlIEhpc3Rvcnkt SW5mbyBoZWFkZXIgdG8gaGFuZGxlIGNhbGwNCiAgIGRpdmVyc2lvbiBpbmZvcm1hdGlvbi4gIElu IGFkZGl0aW9uLCBhbiBpbnRlcndvcmtpbmcgcG9saWN5IGlzDQogICBwcm9wb3NlZCB0byBtYW5h Z2UgdGhlIGhlYWRlcnMnIGNvZXhpc3RlbmNlLiAgVGhlIG5vbi1zdGFuZGFyZA0KICAgRGl2ZXJz aW9uIGhlYWRlciBpcyBkZXNjcmliZWQsIGFzIEhpc3RvcmljLCBpbiBbUkZDNTgwNl0uICBUaGUN CiAgIEhpc3RvcnktSW5mbyBoZWFkZXIgaXMgZGVzY3JpYmVkIGluIFtSRkM3MDQ0XSB0aGF0IG9i c29sZXRlcw0KICAgW1JGQzQyNDRdIGluaXRpYWxseSBkZXNjcmliaW5nIHRoZSBIaXN0b3J5LUlu Zm8gaGVhZGVyLiAgW1JGQzcwNDRdDQogICBkZWZpbmVzIGFuIG9wdGlvbmFsIFNJUCBoZWFkZXIg ZmllbGQsIEhpc3RvcnktSW5mbywgZm9yIGNhcHR1cmluZyB0aGUNCiAgIGhpc3RvcnkgaW5mb3Jt YXRpb24gaW4gcmVxdWVzdHMgYW5kIFNJUCBoZWFkZXIgZmllbGQgcGFyYW1ldGVycyBmb3INCiAg IHRoZSBIaXN0b3J5LUluZm8gYW5kIENvbnRhY3QgaGVhZGVyIGZpZWxkcyB0byB0YWcgdGhlIG1l dGhvZCBieSB3aGljaA0KICAgdGhlIHRhcmdldCBvZiBhIHJlcXVlc3QgaXMgZGV0ZXJtaW5lZC4g IFJGQzcwNDQgYWxzbyBkZWZpbmVzIGEgdmFsdWUNCiAgIGZvciB0aGUgUHJpdmFjeSBoZWFkZXIg ZmllbGQgdGhhdCBkaXJlY3RzIHRoZSBhbm9ueW1pemF0aW9uIG9mIHZhbHVlcw0KICAgaW4gdGhl IEhpc3RvcnktSW5mbyBoZWFkZXIgZmllbGQuDQoNCiAgIFNpbmNlIHRoZSBEaXZlcnNpb24gaGVh ZGVyIGlzIHVzZWQgaW4gZXhpc3RpbmcgbmV0d29yaw0KICAgaW1wbGVtZW50YXRpb25zIGZvciB0 aGUgdHJhbnNwb3J0IG9mIGNhbGwgZGl2ZXJzaW9uIGluZm9ybWF0aW9uLCBpdHMNCiAgIGludGVy d29ya2luZyB3aXRoIHRoZSBTSVAgSGlzdG9yeS1JbmZvIHN0YW5kYXJkaXplZCBzb2x1dGlvbiBp cw0KICAgbmVlZGVkLiAgVGhpcyB3b3JrIGlzIGludGVuZGVkIHRvIGVuYWJsZSB0aGUgbWlncmF0 aW9uIGZyb20gbm9uLQ0KICAgc3RhbmRhcmQgaW1wbGVtZW50YXRpb25zIGFuZCBkZXBsb3ltZW50 IHRvd2FyZCBJRVRGIHNwZWNpZmljYXRpb24tDQogICBiYXNlZCBpbXBsZW1lbnRhdGlvbnMgYW5k IGRlcGxveW1lbnQuDQogICBUaGlzIGRvY3VtZW50IG9ic29sZXRlcyBbUkZDNjA0NF0uDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwK T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Fri Feb 14 11:23:02 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED821A0364 for ; Fri, 14 Feb 2014 11:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUCw_dLZAPMx for ; Fri, 14 Feb 2014 11:22:54 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 9E45B1A0323 for ; Fri, 14 Feb 2014 11:22:49 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta07.westchester.pa.mail.comcast.net with comcast id SJ6n1n0020xGWP857KNoxq; Fri, 14 Feb 2014 19:22:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id SKNn1n00M3ZTu2S3YKNnRT; Fri, 14 Feb 2014 19:22:48 +0000 Message-ID: <52FE6D07.8050706@alum.mit.edu> Date: Fri, 14 Feb 2014 14:22:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <20140214174942.25151.514.idtracker@ietfa.amsl.com> <29855_1392404336_52FE6770_29855_16315_1_8B970F90C584EA4E97D5BAAC9172DBB8141FC680@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <29855_1392404336_52FE6770_29855_16315_1_8B970F90C584EA4E97D5BAAC9172DBB8141FC680@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392405768; bh=bCSG06SnryYUV94/1O0Y+lIY/88TEc0mvWU3j7SYizU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OypVXB3z+Q9o5gz1k1U/p4F5LQnP+6eHlD7rQ11CRsmD/HQgjpXy5QIo8bfK7Ayq/ hVXehn1pgS6cHAPutXFthlRMtyLhV4x251qegrn4+UN8O+OIdcyaqpQfHUvasnpWy1 uWqy135qwq6/z19VcZJ3qqXZnDPXXbKDBej1R+urz1vf/PALwvFNCQnC44uPbO/CdK vC2fPxd5nUmVVQFzIR9ErcHP1LN5loxekpLoe8n0DalxNeep9AnmmW192yFZsmVaA9 k8EzPwrn3N/4BV8VlG/4H5e5GeEDvHb3iMXFvje4WW6jz73fFlvJfbWudaYAjyaaYa TZi2QarVnK8mg== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/GINdtUfjdup9XOsucU5GvOUknEI Subject: Re: [sipcore] TR: New Version Notification for draft-mohali-rfc6044bis-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:22:56 -0000 Marianne, I see you have sent this mail to sipcore, but the individual draft itself doesn't indicate a wg. Looking back at how 6044 was handled, all the discussion I can find was on the bliss wg mailing list. But it never became a wg document there or sipcore. I gather it was progressed as AD sponsored? IMO sipcore isn't the proper place to discuss this. Maybe dispatch. Thanks, Paul (as sipcore co-chair) On 2/14/14 1:58 PM, marianne.mohali@orange.com wrote: > Hi folks, > > FYI > Following RFC7044 publication (History-Info bis), here is a first version of the RFC6044bis (draft-mohali-rfc6044bis-00) proposing a mapping between History-Info header field and Diversion header field (RFC5806). > > Best Regards, > Marianne > > -----Message d'origine----- > De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Envoyé : vendredi 14 février 2014 18:50 > À : MOHALI Marianne IMT/OLN; MOHALI Marianne IMT/OLN > Objet : New Version Notification for draft-mohali-rfc6044bis-00.txt > > > A new version of I-D, draft-mohali-rfc6044bis-00.txt has been successfully submitted by Marianne Mohali and posted to the IETF repository. > > Name: draft-mohali-rfc6044bis > Revision: 00 > Title: Mapping and interworking of Diversion information Between Diversion and History-Info Headers in the Session Initiation Protocol (SIP) > Document date: 2014-02-14 > Group: Individual Submission > Pages: 25 > URL: http://www.ietf.org/internet-drafts/draft-mohali-rfc6044bis-00.txt > Status: https://datatracker.ietf.org/doc/draft-mohali-rfc6044bis/ > Htmlized: http://tools.ietf.org/html/draft-mohali-rfc6044bis-00 > > > Abstract: > [This version of the document is a draft version for an RFC6044bis > that will describe the mapping between the Diversion header defined > in RFC5806 and the new History-Info header defined in RFC7044.] > Although the SIP History-Info header is the solution adopted in IETF, > the non-standard Diversion header is nevertheless already implemented > and used for conveying call diversion related information in the > Session Initiation Protocol (SIP) signaling. > This document describes a recommended interworking guideline between > the Diversion header and the History-Info header to handle call > diversion information. In addition, an interworking policy is > proposed to manage the headers' coexistence. The non-standard > Diversion header is described, as Historic, in [RFC5806]. The > History-Info header is described in [RFC7044] that obsoletes > [RFC4244] initially describing the History-Info header. [RFC7044] > defines an optional SIP header field, History-Info, for capturing the > history information in requests and SIP header field parameters for > the History-Info and Contact header fields to tag the method by which > the target of a request is determined. RFC7044 also defines a value > for the Privacy header field that directs the anonymization of values > in the History-Info header field. > > Since the Diversion header is used in existing network > implementations for the transport of call diversion information, its > interworking with the SIP History-Info standardized solution is > needed. This work is intended to enable the migration from non- > standard implementations and deployment toward IETF specification- > based implementations and deployment. > This document obsoletes [RFC6044]. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Fri Feb 14 14:21:42 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC5B1A022B for ; Fri, 14 Feb 2014 14:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8GfSIxoWLqT for ; Fri, 14 Feb 2014 14:21:28 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) by ietfa.amsl.com (Postfix) with ESMTP id E8BEC1A0229 for ; Fri, 14 Feb 2014 14:21:25 -0800 (PST) Received: by mail-yk0-f178.google.com with SMTP id 79so24885756ykr.9 for ; Fri, 14 Feb 2014 14:21:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fP+zA52TOtOXNnLAabBPNSicf65i2o0JCr3W+bYRsU0=; b=X2+idG67iW+IZgfPVp4sd1DQUu36HBSLcygDWTmPfSUwJGGV90rdprJHqkLPNXsXiA qUP9CQXauL/35cGt+4TZRvurmNvCfsoGlkENxJd2tMhNFmVjWOP5JuQjf6NrcUliaHuz BfcqWL6HF/0wjPlHvcAfWmMe3DFm01TVxss1HGkV07RJ60CTKpKdZmoo1vyECayyYfvg VvXoolBcZtAGcq/zW1L9i2U6wa43nLXH8vfsckgV8TQO4c8BsbrOyc9KflJWUyFq6bMA tW6KAwmgDCrhL0sW8mekP4b6EvRI7B9t70DjGKtEFiNuFxNPYnaI/xSCLtCW6FBCZ3zk rMKw== MIME-Version: 1.0 X-Received: by 10.236.101.227 with SMTP id b63mr4860564yhg.37.1392416484219; Fri, 14 Feb 2014 14:21:24 -0800 (PST) Received: by 10.170.150.2 with HTTP; Fri, 14 Feb 2014 14:21:24 -0800 (PST) In-Reply-To: <52FE6D07.8050706@alum.mit.edu> References: <20140214174942.25151.514.idtracker@ietfa.amsl.com> <29855_1392404336_52FE6770_29855_16315_1_8B970F90C584EA4E97D5BAAC9172DBB8141FC680@PEXCVZYM12.corporate.adroot.infra.ftgroup> <52FE6D07.8050706@alum.mit.edu> Date: Fri, 14 Feb 2014 16:21:24 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=20cf300e51e5ebdd9704f2653969 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/WNAV4FDmZKeu9N1EILQk4hyQdms Cc: SIPCORE Subject: Re: [sipcore] TR: New Version Notification for draft-mohali-rfc6044bis-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 22:21:37 -0000 --20cf300e51e5ebdd9704f2653969 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul, RFC 6044 was not a product of any IETF WG. Robert, was the shepherd and the IESG reviewed but the criteria are different in the case that the document is being considered for the independent stream: "This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. My recommendation is then that the same route is the only reasonable one for any updates to RFC 6044. Note, that this RFC has a normative dependency on the Diversion-header (RFC 5806) that was also published in the independent stream. It should not go to DISPATCH unless we want to waste our time rehashing the debate we had many times and we ultimately decided not to accept this as a work item in any of the WGs. Some of the earlier discussion was in the SIPPING WG prior to the chartering of DISPATCH. Mary. On Fri, Feb 14, 2014 at 1:22 PM, Paul Kyzivat wrote= : > Marianne, > > I see you have sent this mail to sipcore, but the individual draft itself > doesn't indicate a wg. Looking back at how 6044 was handled, all the > discussion I can find was on the bliss wg mailing list. But it never beca= me > a wg document there or sipcore. I gather it was progressed as AD sponsore= d? > > IMO sipcore isn't the proper place to discuss this. Maybe dispatch. > > Thanks, > Paul (as sipcore co-chair) > > > On 2/14/14 1:58 PM, marianne.mohali@orange.com wrote: > >> Hi folks, >> >> FYI >> Following RFC7044 publication (History-Info bis), here is a first versio= n >> of the RFC6044bis (draft-mohali-rfc6044bis-00) proposing a mapping betwe= en >> History-Info header field and Diversion header field (RFC5806). >> >> Best Regards, >> Marianne >> >> -----Message d'origine----- >> De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Envoy=E9 : vendredi 14 f=E9vrier 2014 18:50 >> =C0 : MOHALI Marianne IMT/OLN; MOHALI Marianne IMT/OLN >> Objet : New Version Notification for draft-mohali-rfc6044bis-00.txt >> >> >> A new version of I-D, draft-mohali-rfc6044bis-00.txt has been >> successfully submitted by Marianne Mohali and posted to the IETF reposit= ory. >> >> Name: draft-mohali-rfc6044bis >> Revision: 00 >> Title: Mapping and interworking of Diversion information Betwee= n >> Diversion and History-Info Headers in the Session Initiation Protocol (S= IP) >> Document date: 2014-02-14 >> Group: Individual Submission >> Pages: 25 >> URL: http://www.ietf.org/internet-drafts/draft-mohali- >> rfc6044bis-00.txt >> Status: https://datatracker.ietf.org/doc/draft-mohali-rfc6044bis= / >> Htmlized: http://tools.ietf.org/html/draft-mohali-rfc6044bis-00 >> >> >> Abstract: >> [This version of the document is a draft version for an RFC6044bis >> that will describe the mapping between the Diversion header defined >> in RFC5806 and the new History-Info header defined in RFC7044.] >> Although the SIP History-Info header is the solution adopted in IETF= , >> the non-standard Diversion header is nevertheless already implemente= d >> and used for conveying call diversion related information in the >> Session Initiation Protocol (SIP) signaling. >> This document describes a recommended interworking guideline between >> the Diversion header and the History-Info header to handle call >> diversion information. In addition, an interworking policy is >> proposed to manage the headers' coexistence. The non-standard >> Diversion header is described, as Historic, in [RFC5806]. The >> History-Info header is described in [RFC7044] that obsoletes >> [RFC4244] initially describing the History-Info header. [RFC7044] >> defines an optional SIP header field, History-Info, for capturing th= e >> history information in requests and SIP header field parameters for >> the History-Info and Contact header fields to tag the method by whic= h >> the target of a request is determined. RFC7044 also defines a value >> for the Privacy header field that directs the anonymization of value= s >> in the History-Info header field. >> >> Since the Diversion header is used in existing network >> implementations for the transport of call diversion information, its >> interworking with the SIP History-Info standardized solution is >> needed. This work is intended to enable the migration from non- >> standard implementations and deployment toward IETF specification- >> based implementations and deployment. >> This document obsoletes [RFC6044]. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> >> >> ____________________________________________________________ >> _____________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >> ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --20cf300e51e5ebdd9704f2653969 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Paul,

RFC 6044 was not a product of any= IETF WG. =A0Robert, was the shepherd and the IESG reviewed but the criteri= a are different in the case that the document is being considered for the i= ndependent stream:
  "This is a contribution to the RFC Series, independently of=A0
= 
   any other RFC stream.  The=
 RFC Editor has chosen to publish=A0
   this document at its discr=
etion and makes no statement=A0
   about its value for implementation or deployment.  Documents
   approved for publication by the =
RFC Editor are not a=A0
   candidate for any level of=
 Internet Standard;=A0
   see Section 2 of RFC 5741.

My recommendation is then that the s= ame route is the only reasonable one for any updates to RFC 6044. =A0Note, = that this RFC has a normative dependency on the Diversion-header (RFC 5806)= that was also published in the independent stream.=A0

It should not go to DISPATCH unless we want to waste ou= r time rehashing the debate we had many times and we ultimately decided not= to accept this as a work item in any of the WGs. =A0Some of the earlier di= scussion was in the SIPPING WG prior to the chartering of DISPATCH.=A0

Mary.=A0


=
On Fri, Feb 14, 2014 at 1:22 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
Marianne,

I see you have sent this mail to sipcore, but the individual draft itself d= oesn't indicate a wg. Looking back at how 6044 was handled, all the dis= cussion I can find was on the bliss wg mailing list. But it never became a = wg document there or sipcore. I gather it was progressed as AD sponsored?
IMO sipcore isn't the proper place to discuss this. Maybe dispatch.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul (as sipcore co-chair)


On 2/14/14 1:58 PM, marianne.mohali@orange.com wrote:
Hi folks,

FYI
Following RFC7044 publication (History-Info bis), here is a first version o= f the RFC6044bis (draft-mohali-rfc6044bis-00) proposing a mapping between H= istory-Info header field and Diversion header field (RFC5806).

Best Regards,
Marianne

-----Message d'origine-----
De : internet= -drafts@ietf.org [mailto:internet-drafts@ietf.org]
Envoy=E9 : vendredi 14 f=E9vrier 2014 18:50
=C0 : MOHALI Marianne IMT/OLN; MOHALI Marianne IMT/OLN
Objet : New Version Notification for draft-mohali-rfc6044bis-00.txt


A new version of I-D, draft-mohali-rfc6044bis-00.txt has been successfully = submitted by Marianne Mohali and posted to the IETF repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-mohali-rfc6044bis
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0Mapping and interworking of Diversion information= Between Diversion and History-Info Headers in the Session Initiation Proto= col (SIP)
Document date: =A02014-02-14
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A025
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/inter= net-drafts/draft-mohali-rfc6044bis-00.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/do= c/draft-mohali-rfc6044bis/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-moha= li-rfc6044bis-00


Abstract:
=A0 =A0 [This version of the document is a draft version for an RFC6044bis<= br> =A0 =A0 that will describe the mapping between the Diversion header defined=
=A0 =A0 in RFC5806 and the new History-Info header defined in RFC7044.]
=A0 =A0 Although the SIP History-Info header is the solution adopted in IET= F,
=A0 =A0 the non-standard Diversion header is nevertheless already implement= ed
=A0 =A0 and used for conveying call diversion related information in the =A0 =A0 Session Initiation Protocol (SIP) signaling.
=A0 =A0 This document describes a recommended interworking guideline betwee= n
=A0 =A0 the Diversion header and the History-Info header to handle call
=A0 =A0 diversion information. =A0In addition, an interworking policy is =A0 =A0 proposed to manage the headers' coexistence. =A0The non-standar= d
=A0 =A0 Diversion header is described, as Historic, in [RFC5806]. =A0The =A0 =A0 History-Info header is described in [RFC7044] that obsoletes
=A0 =A0 [RFC4244] initially describing the History-Info header. =A0[RFC7044= ]
=A0 =A0 defines an optional SIP header field, History-Info, for capturing t= he
=A0 =A0 history information in requests and SIP header field parameters for=
=A0 =A0 the History-Info and Contact header fields to tag the method by whi= ch
=A0 =A0 the target of a request is determined. =A0RFC7044 also defines a va= lue
=A0 =A0 for the Privacy header field that directs the anonymization of valu= es
=A0 =A0 in the History-Info header field.

=A0 =A0 Since the Diversion header is used in existing network
=A0 =A0 implementations for the transport of call diversion information, it= s
=A0 =A0 interworking with the SIP History-Info standardized solution is
=A0 =A0 needed. =A0This work is intended to enable the migration from non-<= br> =A0 =A0 standard implementations and deployment toward IETF specification-<= br> =A0 =A0 based implementations and deployment.
=A0 =A0 This document obsoletes [RFC6044].




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_____________________________________________________________= ____________________________________________________________<= br>
Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--20cf300e51e5ebdd9704f2653969-- From nobody Mon Feb 17 00:45:07 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AD31A00C3 for ; Mon, 17 Feb 2014 00:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKVA5b2REFav for ; Mon, 17 Feb 2014 00:44:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 757981A011B for ; Mon, 17 Feb 2014 00:44:58 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id E90DE264199; Mon, 17 Feb 2014 09:44:54 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id C8C9835C09A; Mon, 17 Feb 2014 09:44:54 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 09:44:54 +0100 From: To: Mary Barnes , Paul Kyzivat Thread-Topic: [sipcore] TR: New Version Notification for draft-mohali-rfc6044bis-00.txt Thread-Index: AQHPKborKcY4AUI+vUSo0MeIe60LUJq1QfgAgAPiQRA= Date: Mon, 17 Feb 2014 08:44:53 +0000 Message-ID: <25341_1392626694_5301CC06_25341_15618_1_8B970F90C584EA4E97D5BAAC9172DBB8141FCA4C@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20140214174942.25151.514.idtracker@ietfa.amsl.com> <29855_1392404336_52FE6770_29855_16315_1_8B970F90C584EA4E97D5BAAC9172DBB8141FC680@PEXCVZYM12.corporate.adroot.infra.ftgroup> <52FE6D07.8050706@alum.mit.edu> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB8141FCA4CPEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.17.40915 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/YfE9vDGlPkbH_dUghzCbVyKRGGQ Cc: SIPCORE Subject: Re: [sipcore] TR: New Version Notification for draft-mohali-rfc6044bis-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 08:45:05 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB8141FCA4CPEXCVZYM12corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Paul and Mary, It is clear for me that this draft will follow the same route than RFC6044 = as an independent submission and not a WG document. Because this draft is related to RFC7044 (a sipcore document), my intention= was just to inform people working on that topic about the new draft. That'= s why my email was "for your information". Thank you Best Regards, Marianne De : sipcore [mailto:sipcore-bounces@ietf.org] De la part de Mary Barnes Envoy=E9 : vendredi 14 f=E9vrier 2014 23:21 =C0 : Paul Kyzivat Cc : SIPCORE Objet : Re: [sipcore] TR: New Version Notification for draft-mohali-rfc6044= bis-00.txt Paul, RFC 6044 was not a product of any IETF WG. Robert, was the shepherd and th= e IESG reviewed but the criteria are different in the case that the documen= t is being considered for the independent stream: "This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. My recommendation is then that the same route is the only reasonable one fo= r any updates to RFC 6044. Note, that this RFC has a normative dependency = on the Diversion-header (RFC 5806) that was also published in the independe= nt stream. It should not go to DISPATCH unless we want to waste our time rehashing the= debate we had many times and we ultimately decided not to accept this as a= work item in any of the WGs. Some of the earlier discussion was in the SI= PPING WG prior to the chartering of DISPATCH. Mary. On Fri, Feb 14, 2014 at 1:22 PM, Paul Kyzivat > wrote: Marianne, I see you have sent this mail to sipcore, but the individual draft itself d= oesn't indicate a wg. Looking back at how 6044 was handled, all the discuss= ion I can find was on the bliss wg mailing list. But it never became a wg d= ocument there or sipcore. I gather it was progressed as AD sponsored? IMO sipcore isn't the proper place to discuss this. Maybe dispatch. Thanks, Paul (as sipcore co-chair) On 2/14/14 1:58 PM, marianne.mohali@orange.com wrote: Hi folks, FYI Following RFC7044 publication (History-Info bis), here is a first version o= f the RFC6044bis (draft-mohali-rfc6044bis-00) proposing a mapping between H= istory-Info header field and Diversion header field (RFC5806). Best Regards, Marianne -----Message d'origine----- De : internet-drafts@ietf.org [mailto:inte= rnet-drafts@ietf.org] Envoy=E9 : vendredi 14 f=E9vrier 2014 18:50 =C0 : MOHALI Marianne IMT/OLN; MOHALI Marianne IMT/OLN Objet : New Version Notification for draft-mohali-rfc6044bis-00.txt A new version of I-D, draft-mohali-rfc6044bis-00.txt has been successfully = submitted by Marianne Mohali and posted to the IETF repository. Name: draft-mohali-rfc6044bis Revision: 00 Title: Mapping and interworking of Diversion information Between D= iversion and History-Info Headers in the Session Initiation Protocol (SIP) Document date: 2014-02-14 Group: Individual Submission Pages: 25 URL: http://www.ietf.org/internet-drafts/draft-mohali-rfc6044bis= -00.txt Status: https://datatracker.ietf.org/doc/draft-mohali-rfc6044bis/ Htmlized: http://tools.ietf.org/html/draft-mohali-rfc6044bis-00 Abstract: [This version of the document is a draft version for an RFC6044bis that will describe the mapping between the Diversion header defined in RFC5806 and the new History-Info header defined in RFC7044.] Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless already implemented and used for conveying call diversion related information in the Session Initiation Protocol (SIP) signaling. This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information. In addition, an interworking policy is proposed to manage the headers' coexistence. The non-standard Diversion header is described, as Historic, in [RFC5806]. The History-Info header is described in [RFC7044] that obsoletes [RFC4244] initially describing the History-Info header. [RFC7044] defines an optional SIP header field, History-Info, for capturing the history information in requests and SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. RFC7044 also defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. Since the Diversion header is used in existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This work is intended to enable the migration from non- standard implementations and deployment toward IETF specification- based implementations and deployment. This document obsoletes [RFC6044]. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8B970F90C584EA4E97D5BAAC9172DBB8141FCA4CPEXCVZYM12corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Paul and Mary,=

 <= /p>

It is clear for me that t= his draft will follow the same route than RFC6044 as an independent submiss= ion and not a WG document.

Because this draft is rel= ated to RFC7044 (a sipcore document), my intention was just to inform peopl= e working on that topic about the new draft. That’s why my email was “for your information”.

 <= /p>

Thank you

 <= /p>

Best Regards,<= /span>

Marianne

 <= /p>

De : sipcore [mailto:sipcore-bounces@ietf.org] De la part de Mary Barnes
Envoy=E9 : vendredi 14 f=E9vrier 2014 23:21
=C0 : Paul Kyzivat
Cc : SIPCORE
Objet : Re: [sipcore] TR: New Version Notification for draft-mo= hali-rfc6044bis-00.txt

 

Paul,

 

RFC 6044 was not a product of any IETF WG.  Rob= ert, was the shepherd and the IESG reviewed but the criteria are different = in the case that the document is being considered for the independent strea= m:

 
  "=
This is a contribution to the RFC Series, independently of =

   =
any other RFC stream.  The RFC Editor has chosen to publish =

   =
this document at its discretion and makes no statement 
 
   =
about its value for implementation or deployment.  Documents
   =
approved for publication by the RFC Editor are not a 
   =
candidate for any level of Internet Standard; 
 
   =
see Section 2 of RFC 5741.

=  

My recommendation is then that the same route is the= only reasonable one for any updates to RFC 6044.  Note, that this RFC= has a normative dependency on the Diversion-header (RFC 5806) that was als= o published in the independent stream. 

 

It should not go to DISPATCH unless we want to waste= our time rehashing the debate we had many times and we ultimately decided = not to accept this as a work item in any of the WGs.  Some of the earl= ier discussion was in the SIPPING WG prior to the chartering of DISPATCH. 

 

Mary. 

 

On Fri, Feb 14, 2014 at 1:22 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:

Marianne,

I see you have sent this mail to sipcore, but the individual draft itself d= oesn't indicate a wg. Looking back at how 6044 was handled, all the discuss= ion I can find was on the bliss wg mailing list. But it never became a wg d= ocument there or sipcore. I gather it was progressed as AD sponsored?

IMO sipcore isn't the proper place to discuss this. Maybe dispatch.

        Thanks,
        Paul (as sipcore co-chair)



On 2/14/14 1:58 PM, marianne.mohali@orange.com wrote:

Hi folks,

FYI
Following RFC7044 publication (History-Info bis), here is a first version o= f the RFC6044bis (draft-mohali-rfc6044bis-00) proposing a mapping between H= istory-Info header field and Diversion header field (RFC5806).

Best Regards,
Marianne

-----Message d'origine-----
De : internet= -drafts@ietf.org [mailto:internet-drafts@ietf.org]
Envoy=E9 : vendredi 14 f=E9vrier 2014 18:50
=C0 : MOHALI Marianne IMT/OLN; MOHALI Marianne IMT/OLN
Objet : New Version Notification for draft-mohali-rfc6044bis-00.txt


A new version of I-D, draft-mohali-rfc6044bis-00.txt has been successfully = submitted by Marianne Mohali and posted to the IETF repository.

Name:           draft-mohali-rfc6044bis
Revision:       00
Title:          Mapping and interworking of Divers= ion information Between Diversion and History-Info Headers in the Session I= nitiation Protocol (SIP)
Document date:  2014-02-14
Group:          Individual Submission
Pages:          25
URL:            http://= www.ietf.org/internet-drafts/draft-mohali-rfc6044bis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mohali-rfc6044bis/
Htmlized:       http://tools.ietf.org/html/draft-mohali-rfc6044bis-00


Abstract:
    [This version of the document is a draft version for an RFC60= 44bis
    that will describe the mapping between the Diversion header d= efined
    in RFC5806 and the new History-Info header defined in RFC7044= .]
    Although the SIP History-Info header is the solution adopted = in IETF,
    the non-standard Diversion header is nevertheless already imp= lemented
    and used for conveying call diversion related information in = the
    Session Initiation Protocol (SIP) signaling.
    This document describes a recommended interworking guideline = between
    the Diversion header and the History-Info header to handle ca= ll
    diversion information.  In addition, an interworking pol= icy is
    proposed to manage the headers' coexistence.  The non-st= andard
    Diversion header is described, as Historic, in [RFC5806]. &nb= sp;The
    History-Info header is described in [RFC7044] that obsoletes<= br>     [RFC4244] initially describing the History-Info header.  = ;[RFC7044]
    defines an optional SIP header field, History-Info, for captu= ring the
    history information in requests and SIP header field paramete= rs for
    the History-Info and Contact header fields to tag the method = by which
    the target of a request is determined.  RFC7044 also def= ines a value
    for the Privacy header field that directs the anonymization o= f values
    in the History-Info header field.

    Since the Diversion header is used in existing network
    implementations for the transport of call diversion informati= on, its
    interworking with the SIP History-Info standardized solution = is
    needed.  This work is intended to enable the migration f= rom non-
    standard implementations and deployment toward IETF specifica= tion-
    based implementations and deployment.
    This document obsoletes [RFC6044].




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_8B970F90C584EA4E97D5BAAC9172DBB8141FCA4CPEXCVZYM12corpo_-- From nobody Tue Feb 18 02:14:46 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D521A0651 for ; Tue, 18 Feb 2014 02:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4Z2LOuJz7kO for ; Tue, 18 Feb 2014 02:14:42 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 034661A0466 for ; Tue, 18 Feb 2014 02:14:41 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 5FA6C374353; Tue, 18 Feb 2014 11:14:38 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 2C04AC80CE; Tue, 18 Feb 2014 11:14:38 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 18 Feb 2014 11:14:37 +0100 From: To: "Mary Barnes (mary.ietf.barnes@gmail.com)" , "Shida Schubert (shida@agnada.com)" Thread-Topic: draft-ietf-sipcore-rfc4244bis-callflows-08 Thread-Index: Ac8sAOZEr77wt+E3SPKlGhPnf5OIsg== Date: Tue, 18 Feb 2014 10:14:37 +0000 Message-ID: <14627_1392718478_5303328E_14627_2042_1_8B970F90C584EA4E97D5BAAC9172DBB8141FCD68@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB8141FCD68PEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/QLxE2acEVoZUx768ffTDudjhYYw Cc: "sipcore@ietf.org" Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 10:14:45 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB8141FCD68PEXCVZYM12corpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Mary and Shida, In the History-Info CALL FLOW document, I have a remaining comment: In section 3.6, it is mentioned "The original target is determined by findi= ng the first hi-entry tagged with "rc" or "mp" and using the hi-entry referenced by the index of "rc" or "mp" header field parameter as the target for determining the appropriate mailbox. " whereas, in RFC7044 section 12.1 the same sentence is : "The original target is determined by finding the first hi-entry tagged with "rc" and using the hi-entry referenced by the index of the "rc" header field parameter as the target for determining the appropriate mailbox." which one is correct? Best Regards, Marianne Mohali ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8B970F90C584EA4E97D5BAAC9172DBB8141FCD68PEXCVZYM12corpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Mary and Shida,

 

In the History-Info CALL FLOW document, I have a rem= aining comment:

In section 3.6, it is mentioned “The original target is determined= by finding the first
   hi-entry tagged with "rc" or "mp" and usin= g the hi-entry referenced
   by the index of "rc" or "mp" header field = parameter as the target for
   determining the appropriate mailbox. ”

 

whereas, in RFC7044 section 12.1 the same sentenc= e is :

   “The original target is determined by finding th= e first hi-entry
   tagged with "rc" and using the hi-entry referenced b= y the index of
   the "rc" header field parameter as the target for de= termining the
   appropriate mailbox.”

 

which one is correct?

 

 

Best Regards,

Marianne Mohali

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_8B970F90C584EA4E97D5BAAC9172DBB8141FCD68PEXCVZYM12corpo_-- From nobody Tue Feb 18 09:38:55 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBEA1A06C8 for ; Tue, 18 Feb 2014 09:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uzf0Qe5rfBc4 for ; Tue, 18 Feb 2014 09:38:52 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C775E1A025B for ; Tue, 18 Feb 2014 09:38:47 -0800 (PST) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1IHche1071674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 18 Feb 2014 11:38:44 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <53039A9E.2090002@nostrum.com> Date: Tue, 18 Feb 2014 11:38:38 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "'SIPCORE'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/bqaxS7ui1w21AJwca2Zv2SwpPTQ Cc: SIPCORE Chairs Subject: [sipcore] IETF89 Agenda X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 17:38:53 -0000 [as chair] SIPCORE people: I have put a preliminary agenda up for the London meeting: http://www.ietf.org/proceedings/89/agenda/agenda-89-sipcore You may note that we're taking over part of DISPATCH's slot. DISPATCH has decided to send the DANE document to SIPCORE, so we're simply taking over part of their meeting to talk about that document. (I will note that this arrangement isn't 100% finalized, but it remains highly likely at this time). Please send any feedback to the WG chairs at sipcore-chairs@tools.ietf.org /a From nobody Sun Feb 23 12:40:00 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A261A070F for ; Sun, 23 Feb 2014 12:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.365 X-Spam-Level: **** X-Spam-Status: No, score=4.365 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BAYES_999=0.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id an8PKC6CSJMV for ; Sun, 23 Feb 2014 12:39:56 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACAE1A070A for ; Sun, 23 Feb 2014 12:39:55 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta04.westchester.pa.mail.comcast.net with comcast id Vwby1n00416LCl054wfvWv; Sun, 23 Feb 2014 20:39:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id Vwfv1n0063ZTu2S3Swfvea; Sun, 23 Feb 2014 20:39:55 +0000 Message-ID: <530A5C9B.8070004@alum.mit.edu> Date: Sun, 23 Feb 2014 15:39:55 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393187995; bh=aNOpCbnc1b3836wi39L/FV60xzeAOLJ1CDm41ApyaiE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lorhju/+DPT2AOmm2wgX6qkHJG9mrebCyvrOGcBHG8tFBDGttmYmpIcHb62FOFnCt VZoDq53LEq1YO6j/m7Hjk8Mc9FzqcWRLHVsvh65osE8vzfIR0GL/fL9jHmVf/Qwy/i bmUikGxVgWpAeAZuGaILzWvHdHDUyGMRZ2KhV4BkW8qBreVktTSS2cvafIqRMI5BQ5 +ZjW5KdR/Qo0mQk6OmvVR3s3fW4rISwyobhaUYIoDeZ9SCFLSi9Fq1UVoEYULn7NWd VL7DdvadD0CvS9jlJCHTsW/ijR5X4oamw6XwHAWgpxImaQ2MpojUFzp8/10ag4qYZn 0UN1SawszdFLg== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/7lWIjq8KSXN2du4T9Cx0F746APY Subject: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 20:39:59 -0000 (Catching up on my reading) (Speaking as an individual) This version is much improved over the last one I reviewed. I do have futher comments: Section 2.1 says: RFC3261 specifies only one algorithm, MD5, which is used by default. This document adds two new algorithms, to align with the [HTTP- DIGEST], that SHOULD be used instead of MD5: SHA-256 & SHA-512/256. That is true today. But it is also true that [HTTP-DIGEST] defines a registry of algorithms, and is written so that it is applicable to any algorithm that might be added to that registry in the future. Presumably that is the intent here too - not just to support the two new algorithms. So I suggest something like: RFC3261 specifies only one algorithm, MD5, which is used by default. This document extends RFC3261 to allow use of any registered algorithm. Sections 2.4 & 2.5: When the UAC receives a response with multiple headers with the same realm it SHOULD use the topmost header that it supports, unless a local policy dictates otherwise. The client should ignore any challenge it does not understand. When the UAC receives a response with multiple headers with different realms it SHOULD provide all credentials that it possesses that match any one of the challenges. What does the 2nd paragraph mean? It sounds like it contradicts the first paragraph. I *think* you mean, at least in part: When the UAC receives a 401 response with multiple WWW-Authenticate headers with different realms it SHOULD retry and include an Authorization header containing credentials that match the topmost header of any one of the realms. AFAIK the only way that you would get WWW-Authenticate challenges from multiple realms is with forking, where some of the forks are in different realms. The above means that in the retry the forks from other realms will fail again, and challenge again. This is not ideal. And that doesn't cover proxies. If multiple proxies are challenging, from different realms, then the request won't succeed unless it contains credentials for each of those realms. If there is no forking, then the challenges are going to occur one at a time, and the request will only succeed if the UAC maintains authentication sessions for each, preemptively includes credentials for them in the retries, and the nonces for the earlier ones remain valid until the request succeeds. If there is forking, and proxies on different forks are in distinct realms, then things get more complicated. ISTM that the best answer is for the UAC to provide *one* set of credentials for *each* distinct realm challenged via WWW-Authenticate, and for each distinct realm challenged via Proxy-Authenticate. In each case, using the first (or highest priority) algorithm it supports. This still has a potential problem - different servers in a realm may vary in what algorithms they support. If so, the above may not always provide a good result. But I don't think we can fix that. It would also be helpful to include some explanatory text, and maybe examples, of how all this works when there there are multiple proxies challenging, and when there is forking to multiple destinations in the same and different realms. Section 2.6 says: 1. The URI included in the challenge has the following BNF: URI = SIP-URI / SIPS-URI Note that this assumes the R-URI of a sip request can only be SIP or SIPS. But we to allow other values, e.g., TEL and IM. The sip ABNF is: Request-URI = SIP-URI / SIPS-URI / absoluteURI So why not just say: URI = Request-URI Later in bullet 6 is: H(entity-body) = chosen-algorithm("") For example, when the chosen algorithm is SHA-256, then: (That was my suggestion.) But for consistency with the latest [HTTP-DIGEST], this would probably better be: H(entity-body) = ("") For example, when the is SHA-256, then: That's all for now. Thanks, Paul From nobody Tue Feb 25 15:58:33 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363C31A0326 for ; Tue, 25 Feb 2014 15:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uzsus2enOiTK for ; Tue, 25 Feb 2014 15:58:26 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 10DB81A07C2 for ; Tue, 25 Feb 2014 15:58:25 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id hr13so97415lab.17 for ; Tue, 25 Feb 2014 15:58:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CwWV2tv9uHQ6MEz5Eb9wHEpCbJdcisP+EwiGdCZ9lg4=; b=lSqvbnyRoQ2cm3OuCUpcTUhPg2xU3vHNZxZldWmzP0+o32QHyeK5tafMPCys04CZhC JIKHRwED295kmmSffS5TsrIZ6ZcgYBsw1bGQHFA+KWv2XU7gqcvOAfYXow2SHAYpCgrv kR1gquI4aDGMgG5KAPFwnRF1W/JshJ3CObRPu3zTEMjhDpJlvLdQpnH4srduDr81kSHz UoGKxXx3RbcpfPnwTkf3mvP5G5mmwmDCHgVB8EL/+FNxrdfWIdiPHdXhTMLQEqXR5p1M lO4xuwY1p5C18hJj3LCZ+NlP8fk1u2iLAisV6Qjixn1GEVdnC64Xl8dgJhf2ZZe7rs+U nxwA== MIME-Version: 1.0 X-Received: by 10.152.42.196 with SMTP id q4mr22415lal.52.1393372704320; Tue, 25 Feb 2014 15:58:24 -0800 (PST) Received: by 10.112.242.139 with HTTP; Tue, 25 Feb 2014 15:58:24 -0800 (PST) In-Reply-To: <530A5C9B.8070004@alum.mit.edu> References: <530A5C9B.8070004@alum.mit.edu> Date: Tue, 25 Feb 2014 18:58:24 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c34e8e14afc604f343ddea Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/hz1tFuEiUyxQYTZGmgBWP2mGsUQ Cc: SIPCORE Subject: Re: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 23:58:32 -0000 --001a11c34e8e14afc604f343ddea Content-Type: text/plain; charset=ISO-8859-1 Thanks Paul, Please, see my reply inline... Regards, Rifaat On Sun, Feb 23, 2014 at 3:39 PM, Paul Kyzivat wrote: > (Catching up on my reading) > (Speaking as an individual) > > This version is much improved over the last one I reviewed. > I do have futher comments: > > Section 2.1 says: > > RFC3261 specifies only one algorithm, MD5, which is used by default. > This document adds two new algorithms, to align with the [HTTP- > DIGEST], that SHOULD be used instead of MD5: SHA-256 & SHA-512/256. > > That is true today. But it is also true that [HTTP-DIGEST] defines a > registry of algorithms, and is written so that it is applicable to any > algorithm that might be added to that registry in the future. Presumably > that is the intent here too - not just to support the two new algorithms. > So I suggest something like: > > RFC3261 specifies only one algorithm, MD5, which is used by default. > This document extends RFC3261 to allow use of any registered > algorithm. > > Ok > Sections 2.4 & 2.5: > > When the UAC receives a response with multiple headers with the same > realm it SHOULD use the topmost header that it supports, unless a > local policy dictates otherwise. The client should ignore any > challenge it does not understand. > > When the UAC receives a response with multiple headers with different > realms it SHOULD provide all credentials that it possesses that match > any one of the challenges. > > What does the 2nd paragraph mean? It sounds like it contradicts the first > paragraph. I *think* you mean, at least in part: > > When the UAC receives a 401 response with multiple WWW-Authenticate > headers with different realms it SHOULD retry and include an > Authorization header containing credentials that match the topmost > header of any one of the realms. > > Yes, I like your text better. > AFAIK the only way that you would get WWW-Authenticate challenges from > multiple realms is with forking, where some of the forks are in different > realms. The above means that in the retry the forks from other realms will > fail again, and challenge again. This is not ideal. > Not necessarily. The client can include authorization for more than one challenge. Take a look at the following quote from RFC3261, section 22.3: When resubmitting its request in response to a 401 (Unauthorized) or 407 (Proxy Authentication Required) that contains multiple challenges, a UAC MAY include an Authorization value for each WWW- Authenticate value and a Proxy-Authorization value for each Proxy- Authenticate value for which the UAC wishes to supply a credential. As noted above, multiple credentials in a request SHOULD be differentiated by the "realm" parameter. And that doesn't cover proxies. If multiple proxies are challenging, from > different realms, then the request won't succeed unless it contains > credentials for each of those realms. If there is no forking, then the > challenges are going to occur one at a time, and the request will only > succeed if the UAC maintains authentication sessions for each, preemptively > includes credentials for them in the retries, and the nonces for the > earlier ones remain valid until the request succeeds. > > If there is forking, and proxies on different forks are in distinct > realms, then things get more complicated. > > ISTM that the best answer is for the UAC to provide *one* set of > credentials for *each* distinct realm challenged via WWW-Authenticate, and > for each distinct realm challenged via Proxy-Authenticate. In each case, > using the first (or highest priority) algorithm it supports. > > This still has a potential problem - different servers in a realm may vary > in what algorithms they support. If so, the above may not always provide a > good result. But I don't think we can fix that. > I agree with that, as that was the intention of the text provided in section 2.4. Maybe it was not clear enough. The question is how to do that while maintaining backward compatibility? Do we require the proxies to maintain order of challenges and assume that existing endpoints will select the top challenge? or Do we allow proxies to provide challenges in no particular order and expect the client to select the most preferred, which might not work with existing clients? > It would also be helpful to include some explanatory text, and maybe > examples, of how all this works when there there are multiple proxies > challenging, and when there is forking to multiple destinations in the same > and different realms. > > Ok, I will add more details. > Section 2.6 says: > > 1. The URI included in the challenge has the following BNF: > > URI = SIP-URI / SIPS-URI > > Note that this assumes the R-URI of a sip request can only be SIP or SIPS. > But we to allow other values, e.g., TEL and IM. The sip ABNF is: > > Request-URI = SIP-URI / SIPS-URI / absoluteURI > > So why not just say: > > URI = Request-URI > > OK > Later in bullet 6 is: > > H(entity-body) = chosen-algorithm("") > > For example, when the chosen algorithm is SHA-256, then: > > (That was my suggestion.) But for consistency with the latest > [HTTP-DIGEST], this would probably better be: > > H(entity-body) = ("") > > For example, when the is SHA-256, then: > > Ok > That's all for now. > > Thanks, > Paul > --001a11c34e8e14afc604f343ddea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Paul,

Please, see my reply inlin= e...

Regards,
=A0Rifaat



On Sun, Feb 23,= 2014 at 3:39 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> w= rote:
(Catching up on my reading)
(Speaking as an individual)

This version is much improved over the last one I reviewed.
I do have futher comments:

Section 2.1 says:

=A0 =A0RFC3261 specifies only one algorithm, MD5, which is used by default.=
=A0 =A0This document adds two new algorithms, to align with the [HTTP-
=A0 =A0DIGEST], that SHOULD be used instead of MD5: SHA-256 & SHA-512/2= 56.

That is true today. But it is also true that [HTTP-DIGEST] defines a regist= ry of algorithms, and is written so that it is applicable to any algorithm = that might be added to that registry in the future. Presumably that is the = intent here too - not just to support the two new algorithms. So I suggest = something like:

=A0 =A0RFC3261 specifies only one algorithm, MD5, which is used by default.=
=A0 =A0This document extends RFC3261 to allow use of any registered
=A0 =A0algorithm.


Ok

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> Sections 2.4 & 2.5:

=A0 =A0When the UAC receives a response with multiple headers with the same=
=A0 =A0realm it SHOULD use the topmost header that it supports, unless a =A0 =A0local policy dictates otherwise. The client should ignore any
=A0 =A0challenge it does not understand.

=A0 =A0When the UAC receives a response with multiple headers with differen= t
=A0 =A0realms it SHOULD provide all credentials that it possesses that matc= h
=A0 =A0any one of the challenges.

What does the 2nd paragraph mean? It sounds like it contradicts the first p= aragraph. I *think* you mean, at least in part:

=A0 =A0When the UAC receives a 401 response with multiple WWW-Authenticate<= br> =A0 =A0headers with different realms it SHOULD retry and include an
=A0 =A0Authorization header containing credentials that match the topmost =A0 =A0header of any one of the realms.

Yes, I like your text better.=A0

=
=A0
AFAIK the only way that you would get WWW-Authenticate challenges from mult= iple realms is with forking, where some of the forks are in different realm= s. The above means that in the retry the forks from other realms will fail = again, and challenge again. This is not ideal.

Not necessarily. The client can include au= thorization for more than one challenge. Take a look at the following quote= from RFC3261, section 22.3:

   When resubmitting its request in response to a 401 (Unauthorized) or
   407 (Proxy Authentication Required) that contains multiple
   challenges, a UAC MAY include an Authorization value for each WWW-
   Authenticate value and a Proxy-Authorization value for each Proxy-
   Authenticate value for which the UAC wishes to supply a credential.
   As noted above, multiple credentials in a request SHOULD be
   differentiated by the "realm" parameter.
And that doesn't cover proxies. If multiple proxies are challenging, fr= om different realms, then the request won't succeed unless it contains = credentials for each of those realms. If there is no forking, then the chal= lenges are going to occur one at a time, and the request will only succeed = if the UAC maintains authentication sessions for each, preemptively include= s credentials for them in the retries, and the nonces for the earlier ones = remain valid until the request succeeds.

If there is forking, and proxies on different forks are in distinct realms,= then things get more complicated.

ISTM that the best answer is for the UAC to provide *one* set of credential= s for *each* distinct realm challenged via WWW-Authenticate, and for each d= istinct realm challenged via Proxy-Authenticate. In each case, using the fi= rst (or highest priority) algorithm it supports.

This still has a potential problem - different servers in a realm may vary = in what algorithms they support. If so, the above may not always provide a = good result. But I don't think we can fix that.

I agree with that, as that was the intention of the text pro= vided in section 2.4. Maybe it was not clear enough.

The question is how to do that while maintaining backward compatibi= lity?
Do we require the proxies to maintain order of challenges and assume t= hat existing endpoints will select the top challenge? or
Do we al= low proxies to provide challenges in no particular order and expect the cli= ent to select the most preferred, which might not work with existing client= s?



It would also be helpful to include some explanatory text, and maybe exampl= es, of how all this works when there there are multiple proxies challenging= , and when there is forking to multiple destinations in the same and differ= ent realms.

Ok, I will add more details.

=A0
Section 2.6 says:

=A0 =A01. The URI included in the challenge has the following BNF:

=A0 =A0 =A0 URI =A0=3D =A0SIP-URI / SIPS-URI

Note that this assumes the R-URI of a sip request can only be SIP or SIPS. = But we to allow other values, e.g., TEL and IM. The sip ABNF is:

Request-URI =A0 =A0=3D =A0SIP-URI / SIPS-URI / absoluteURI

So why not just say:

=A0 =A0 =A0 URI =A0=3D =A0Request-URI


OK

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> Later in bullet 6 is:

=A0 =A0 =A0 =A0H(entity-body) =3D chosen-algorithm("")

=A0 =A0 =A0 =A0For example, when the chosen algorithm is SHA-256, then:

(That was my suggestion.) But for consistency with the latest [HTTP-DIGEST]= , this would probably better be:

=A0 =A0 =A0 =A0H(entity-body) =3D <algorithm>("")

=A0 =A0 =A0 =A0For example, when the <algorithm> is SHA-256, then:

Ok

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> That's all for now.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

--001a11c34e8e14afc604f343ddea-- From nobody Thu Feb 27 07:42:19 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4F61A0300 for ; Thu, 27 Feb 2014 07:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maut5eyD-aft for ; Thu, 27 Feb 2014 07:42:14 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEF01A0328 for ; Thu, 27 Feb 2014 07:42:14 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA11.westchester.pa.mail.comcast.net with comcast id XRy31n0050mv7h05BTiC1F; Thu, 27 Feb 2014 15:42:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id XTiC1n0063ZTu2S3XTiCD2; Thu, 27 Feb 2014 15:42:12 +0000 Message-ID: <530F5CD4.9030606@alum.mit.edu> Date: Thu, 27 Feb 2014 10:42:12 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <530A5C9B.8070004@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393515732; bh=L2Jd+hqdYGG5zvU0g/fzb0u+KO7QQC5hzn5OHsHglFI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CVEqTfbugSeqaAOUSaa1crzoO9Qu0g24LpLP7DPfxLsIl6o6YxQaIXk7x75Md30TY 06q5QuRTSKTjwcwsoPVdeNhfTmyqlzkt+fL8SF4T22C8byTWdlPg0TiEPnOnUDQIY9 FRkPwWt7BcWTyrZPiVlrqnenk2tjku4IY2jIQMNVLx1U42QZtLBuIToLJk2gbWqTqO 9s5Z9DJL+z3weSiv4nuqLEg2W4mbL5/1T6svbz7tBs23mWYm/GBatuNyYmPdbCU7w1 9N1EDhLnE3KxUrbYeUvaus9Xl+yVJxpWCpXTZluf+uKyARp9OUcvCiaC86IFnoS6X0 yc7NS3B/WbxEA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/x9QK5fy9soPqxXmb_8fWw28Nouc Cc: SIPCORE Subject: Re: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 15:42:16 -0000 On 2/25/14 6:58 PM, Rifaat Shekh-Yusef wrote: > Thanks Paul, > > Please, see my reply inline... > > Regards, > Rifaat > > > > On Sun, Feb 23, 2014 at 3:39 PM, Paul Kyzivat > wrote: > > (Catching up on my reading) > (Speaking as an individual) > > This version is much improved over the last one I reviewed. > I do have futher comments: > > Section 2.1 says: > > RFC3261 specifies only one algorithm, MD5, which is used by default. > This document adds two new algorithms, to align with the [HTTP- > DIGEST], that SHOULD be used instead of MD5: SHA-256 & SHA-512/256. > > That is true today. But it is also true that [HTTP-DIGEST] defines a > registry of algorithms, and is written so that it is applicable to > any algorithm that might be added to that registry in the future. > Presumably that is the intent here too - not just to support the two > new algorithms. So I suggest something like: > > RFC3261 specifies only one algorithm, MD5, which is used by default. > This document extends RFC3261 to allow use of any registered > algorithm. > > > Ok > > Sections 2.4 & 2.5: > > When the UAC receives a response with multiple headers with the same > realm it SHOULD use the topmost header that it supports, unless a > local policy dictates otherwise. The client should ignore any > challenge it does not understand. > > When the UAC receives a response with multiple headers with > different > realms it SHOULD provide all credentials that it possesses that > match > any one of the challenges. > > What does the 2nd paragraph mean? It sounds like it contradicts the > first paragraph. I *think* you mean, at least in part: > > When the UAC receives a 401 response with multiple WWW-Authenticate > headers with different realms it SHOULD retry and include an > Authorization header containing credentials that match the topmost > header of any one of the realms. > > Yes, I like your text better. But that at least implies *choosing* *one* realm to respond to. I explicitly narrowed the above to 401 responses, where that *might* make sense. But not necessarily, when there is forking. > AFAIK the only way that you would get WWW-Authenticate challenges > from multiple realms is with forking, where some of the forks are in > different realms. The above means that in the retry the forks from > other realms will fail again, and challenge again. This is not ideal. > > > Not necessarily. The client can include authorization for more than one > challenge. Take a look at the following quote from RFC3261, section 22.3: > > When resubmitting its request in response to a 401 (Unauthorized) or > 407 (Proxy Authentication Required) that contains multiple > challenges, a UAC MAY include an Authorization value for each WWW- > Authenticate value and a Proxy-Authorization value for each Proxy- > Authenticate value for which the UAC wishes to supply a credential. > As noted above, multiple credentials in a request SHOULD be > differentiated by the "realm" parameter. Then my suggested text is wrong. Perhaps the goal should be: - supply credentials for *each* realm that has challenged (but omit for those where no credentials are available) - for each realm, use (only) the first (highest priority) algorithm supported - if the same realm is challenged with both WWW-Authenticate and Proxy-Authenticate, then I *think* one must not allow Proxy-Authenticate to bid down to a lower priority algorithm. (That could be an attack.) But this needs more discussion. - I think the logic for preemptively including credentials needs further explanation, so that it works in the presence of proxies that authenticate on different forks. > And that doesn't cover proxies. If multiple proxies are challenging, > from different realms, then the request won't succeed unless it > contains credentials for each of those realms. If there is no > forking, then the challenges are going to occur one at a time, and > the request will only succeed if the UAC maintains authentication > sessions for each, preemptively includes credentials for them in the > retries, and the nonces for the earlier ones remain valid until the > request succeeds. > > If there is forking, and proxies on different forks are in distinct > realms, then things get more complicated. > > ISTM that the best answer is for the UAC to provide *one* set of > credentials for *each* distinct realm challenged via > WWW-Authenticate, and for each distinct realm challenged via > Proxy-Authenticate. In each case, using the first (or highest > priority) algorithm it supports. > > This still has a potential problem - different servers in a realm > may vary in what algorithms they support. If so, the above may not > always provide a good result. But I don't think we can fix that. > > > I agree with that, as that was the intention of the text provided in > section 2.4. Maybe it was not clear enough. > > The question is how to do that while maintaining backward compatibility? > Do we require the proxies to maintain order of challenges and assume > that existing endpoints will select the top challenge? or > Do we allow proxies to provide challenges in no particular order and > expect the client to select the most preferred, which might not work > with existing clients? This is hard. I haven't thought it through in detail. > It would also be helpful to include some explanatory text, and maybe > examples, of how all this works when there there are multiple > proxies challenging, and when there is forking to multiple > destinations in the same and different realms. > > Ok, I will add more details. Getting a good set of use cases would make it easier to explore the issues. Thanks, Paul > Section 2.6 says: > > 1. The URI included in the challenge has the following BNF: > > URI = SIP-URI / SIPS-URI > > Note that this assumes the R-URI of a sip request can only be SIP or > SIPS. But we to allow other values, e.g., TEL and IM. The sip ABNF is: > > Request-URI = SIP-URI / SIPS-URI / absoluteURI > > So why not just say: > > URI = Request-URI > > > OK > > Later in bullet 6 is: > > H(entity-body) = chosen-algorithm("") > > For example, when the chosen algorithm is SHA-256, then: > > (That was my suggestion.) But for consistency with the latest > [HTTP-DIGEST], this would probably better be: > > H(entity-body) = ("") > > For example, when the is SHA-256, then: > > > Ok > > That's all for now. > > Thanks, > Paul > >