[Sip] Draft SIP Minutes for IETF 58
Dean Willis <dean.willis@softarmor.com> Fri, 14 November 2003 03:53 UTC
Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10031 for <sip-archive@odin.ietf.org>; Thu, 13 Nov 2003 22:53:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKV17-0003gD-AM for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 22:53:06 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE3r5iW014146 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 22:53:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKV14-0003fE-6v; Thu, 13 Nov 2003 22:53:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKV0l-0003eg-FZ for sip@optimus.ietf.org; Thu, 13 Nov 2003 22:52:45 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10022 for <sip@ietf.org>; Thu, 13 Nov 2003 22:52:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKV0h-0004jy-00 for sip@ietf.org; Thu, 13 Nov 2003 22:52:39 -0500
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AKV0h-0004ju-00 for sip@ietf.org; Thu, 13 Nov 2003 22:52:39 -0500
Received: from softarmor.com (dyn131-204.ietf58.ietf.org [130.129.131.204]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hAE3rdv4017285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2003 21:53:41 -0600
Message-ID: <3FB4515C.9030603@softarmor.com>
Date: Thu, 13 Nov 2003 21:51:56 -0600
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sip@ietf.org
CC: rohan@cisco.com, Allison Mankin <mankin@psg.com>, Jon Peterson <jon.peterson@neustar.biz>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by bdsl.greycouncil.com id hAE3rdv4017285
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] Draft SIP Minutes for IETF 58
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Please review the follwing and correct where needed. Master copy posted at: http://www.softarmor.com/sipwg/meets/ietf58/notes/minutes-sipwg-ietf58.html Text follows: ---------------------------------- Draft Minutes, SIP WG, IETF 58 Official Scribe, Ben Campbell Supplementary Scribe, Vijay Gurbani Minutes Edited by Dean Willis Topic: Call to Order and Agenda Bash --------------------------------------- No issues raised. Topic: Status, Chairs --------------------- Slides presented. New milestones proposed. No schedule objections raised, but it was proposed that the app-interaction framework be published as a proposed standard instead of BCP. Concerns about MIB status raised. Noted that SIP should certainly plan to operate at least through the current work-elevation plan from SIPPING, which extends through December 2004. Topic: Congestion Safety, Dean Willis --------------------------------------- Reading list: draft-ietf-sip-congest-safe-02 There appears to be little interest in implementing this draft. Some suggestions for simplifying it were made. It was also suggested that we need to change RFC 3263to prefer TCP over UDP, explain congestion issues and avoidance in a BCP, and complete the connection reuse work in order to encourage TCP deployment. Many endpoints now implement only UDP. We also need to differentiate fragmentation and congestion. It was noted that this problem does not just apply to MESSAGE, but can be frequently expected with NOTIFY, and with INVITES using S/MIME protection. DCCP is only a partial solution. Several people volunteered to work on this proposed BCP. It was also suggested that the current draft could be simplified to eliminate new response codes 515 and 516, providing a minimal "NO UDP" assurance. Topic: RFC 3312 Updates, Gonzalo Camarillo Reading list: draft-camarillo-sip-rfc3312-update-00.txt Slides presented. Suggested that we adopt as WG item. No objections were raised. Conclusion: adopt draft as wg item, negotiate milestone. Topic: Publish, Aki Niemi Reading List: draft-ietf-sip-publish-01 Slides presented. Issue: Should etags be updated on every publish? Consensus: Usage should be made consistent with HTTP. If it cannot be, we should call these something else. Issue: Publication rate. Proposed that rate from event package be used. Noted that this is probably an irrelevant and meaningless number, as there may be multiple publishers with no knowledge of each other. Much debate ensued, with no resolution Further discussion deferred to the mailing list. Topic: Request History, Mary Barnes Reading List: draft-ietf-sip-history-info-01 draft-jennings-sip-voicemail-uri-00.txt RFC 3087 Slides presented. Issue: r-uri captured anytime request is forwarded. Proposal: Only add reason for history entries added due to retargeting. Issue: Privacy. Proposal: information not included when there are privacy considerations. (when uas sets session or header level privacy) . Next steps: complete flow detail. Do we want to fold reqs into doc as front matter? Request more mailing list feedback. Dependency on mid-end security draft. Presentation of applicability to voicemail. Issue: Optionality. Suggested that we apply stronger language to suggest applications gracefully degrade in absence of history. Issue: Implementability: Concerns raised by Robert Sparks, who will detail on mailing list. Issue: Security. Note that this in-general seems to depend on the middle-to-end and end-to-middle security work. Conclusion: Work should continue, but more thinking about optionality is needed. RJS and Mary to talk offline. 1400 Non-Invite Transactions, Robert Sparks Reading list: draft-sparks-sip-noninvite-01.txt Slides presented. Noted that this problem is not related to the transport protocol, but is specific to the SIP-layer transaction reliability mechanism for all transactions other than INVITE. Several alternatives were presented: A) a series of tweaks B) Eliminate Timer F, allowing non-invite transactions to pend. C) USe path-timing estimation techniques to improve UAs knowledge of timing. D) Revise 3263 caching language to reduce severity of impact. E) Ignore the problem Suggested that SIP be revised to use 3-way handshake like INVITE on all transactions. This might be made backward-compatible through use of an option tag. Polls indicated no consensus on any action, and that the working group didn't understand the nature of problem or disagreed as to its severity. Despite the objections of Morton Thiokol engineers, the shuttle was launched in cold-weather conditions under which it had never been tested, and the O-rings in the boosters failed. Conclusion: None. Further discussion deferred to the mailing list. Topic: GRUU, Jonathan Rosenberg Reading list: draft-rosenberg-sip-gruu-00.txt draft-rosenberg-sipping-gruu-reqs-01.txt Slides presented. Issue: GRUU generation for stateless proxy behavior. Consensus that we need a sample algorithm for understanding. Issues: Liftime of a GRUU. Can a gruu change during a registration? Conclusion: No, gruu is good for lifetime of registrations, refreshes get same gruu. Do we need a guarantee of difference between registrations? Probably no, discuss on list. Issue: Dialog reuse—no longer a need with gruu. Should gruu spec deprecate dialog resuse if both peers support gruu? (Impacts refer, other subscribe usage). Conclusion: Do not address in gruu spec, address in other drafts, put pressure on future work to avoid dialog resuse. Issue: Does Gruu interferes with e2e signaling. UA can try to generate a local gruu, could use ice-like mechaninsm to decide if it is reachable. Propose to add to draft, but never try to put local address in contact header without using the mechanism. Chair suggestion: Put statement about not using local gruu in gruu draft, put “iceing” in separate draft. Author agreed. Issue: MUST NOT use locally generated gruu is too strong. Clarified that definition of local gruu is one with a different domain part than AoR, MUST does not apply to the examples given. Topic: Join, Rohan Mahy Reading List: draft-ietf-sip-join-02.txt Slides presented. Noted that no comments in wglc. Room shows interest, but no one has implemented. We want more list discussion before sending to IESG. Topic: REFER Semantics, Rohan Mahy Reading List: draft-olson-sipping-refer-extensions draft-mahy-sip-remote-cc Slides presented. Basic premise is that the semantics of the various uses of REFER are under-specified. Much discussion ensued. Issue: Is this equivalent to specifying fixed services? If we have to specify all the services/features, then the refer approach has failed. Issue: How do you put refer requests in a context? Dialog reuse? Separate GRUUs? Explicit refer-to header parameters? Noted that it may require per-scheme semantics in addition to context. Issue: Need more than context—how do you know what an endpoint will do with a particular URI scheme? Issue: Not useful for authorization, because referee cannot decide if issuing the request could be bad. Another motivation that is relevant is to determine how to render the UI for the action. Sugested: this does not mean fixing refer, it means adding something new to it. Discussion on proceeding: How do we proceed? Refer for other than transfer unlikely to work on today’s UAs. Rohan suggests defining semantics for baskets of functionality. Use option tags to make sure they are supported. Propose explicit dialog parameters for refer-to. Provide guidance for remote call control vs. remote UI invocation. No conclusion, further discussion deferred to list. Interested parties are to contact Rohan and work on it. Final To-Do: ------------- App Interaction Framework -- change from BCP to PS. Add milestone for RFC 3312 update as PS. Discuss publication rate on mailing list. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] Draft SIP Minutes for IETF 58 Dean Willis