Re: [Insipid] draft-ietf-insipid-session-id-13
"Paul E. Jones" <paulej@packetizer.com> Fri, 30 January 2015 07:15 UTC
Return-Path: <paulej@packetizer.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B5A1A891C for <insipid@ietfa.amsl.com>; Thu, 29 Jan 2015 23:15:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.688
X-Spam-Level:
X-Spam-Status: No, score=0.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 dHiR0DQ8NmKL for <insipid@ietfa.amsl.com>; Thu, 29 Jan 2015 23:15:51 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2E31A88AF for <insipid@ietf.org>; Thu, 29 Jan 2015 23:15:51 -0800 (PST)
Received: from [192.168.1.20] (cpe-098-027-048-015.nc.res.rr.com [98.27.48.15]) (authenticated bits=0) by dublin.packetizer.com (8.14.9/8.14.9) with ESMTP id t0U7FmUJ018256 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2015 02:15:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1422602150; bh=JymXdgyXyN8sa+dPoVv4YZ8G9Bm+FWtEtiCX6YuxOq4=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=ETCrL/RPbdj1WklKzIzHg7gvfmBlmgXKD2Xc/dyp84QECO0Mk1rjFrz/kgOEbGBLi UlPnFe7JnF0a5PfTC/2GjbI/lMnxEx3Ftc5k0BoUnLBSUoEa7X0o9sh9L89Qisjjkg wLrJ4oYt6mJl5yk9WhBEOr8O/Kp1lIHbwiVTqq50=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, insipid@ietf.org
Date: Fri, 30 Jan 2015 07:16:05 +0000
Message-Id: <em6756914a-d169-45b6-94a0-374745d54029@sydney>
In-Reply-To: <54C81052.2010003@alum.mit.edu>
User-Agent: eM_Client/6.0.21372.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/4QKptt92ZIvoA6qZkYsEwMJHJIA>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-13
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jan 2015 07:15:54 -0000
Paul, >OK. I'm now reviewing -13 somewhat carefully. Appreciate it! > >Regarding the new text in section 5: > > The Session-ID header-value is technically case-INSENSITIVE, but >only > lowercase characters are allowed in the sess-uuid components. > Receiving entities MUST treat sess-uuid components as case- > insensitive and not produce an error if an uppercase character is > received in a sess-uuid. > >That can be interpreted to mean that an error should not be reported if >the uuid contains a "Z". I suggest a tweak to that: > > Receiving entities MUST treat sess-uuid components as case- > insensitive and not produce an error if an uppercase HEXDIG > character is received in a sess-uuid. Good. Changed. > >Now that the intent has been specified, the actual syntax needs to >match. It currently doesn't. Currently we have: > > sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > >which isn't consistent with the new statement. Instead, now about: > > sess-uuid = 32(HEXDIG) > >And then replace "The production DIGIT is defined in [RFC5234]" with >"The production HEXDIG is defined in [RFC5234]". HEXDIG is defined only using uppercase characters. I fear that might introduce more confusion. How about I just write this: "not produce an error if an uppercase hexadecimal character is received" And then leave the syntax alone. > >Also in section 5: > > The "local-uuid" in the Session-ID header represents the UUID value > of the UA transmitting the message. If the UA transmitting the > message previously received a UUID value from its peer endpoint, it > MUST include that UUID as the "remote" parameter in each message it > transmits. For example, a Session-ID header might appear like this: > >This doesn't mention the possibility that *different* remote-uuids are >received over the course of the session. I suggest: > > The "local-uuid" in the Session-ID header represents the UUID value > of the UA transmitting the message. If the UA transmitting the > message previously received one or more UUID values from its peer > endpoint in a session, it SHOULD include the most recently received > UUID as the "remote" parameter in each message it transmits within > that session. (Exceptions are explicitly called out elsewhere in >this > document.) For example, a Session-ID header might appear like > this: Everything sounds good, except the change from MUST to SHOULD? Do we really want to do that? >Section 7: > >The term "3PCC" is used without definition. Should include a definition >and a reference to RFC3725. Sure. Done. > >Section 8: > >Here and elsewhere are references to "cascaded MCUs". Neither "MCU" nor >"cascaded MCU" are defined. I don't know where you go for those >definitions. (There is a definition of MCU in >draft-ietf-avtext-rtp-grouping-taxonomy, but it focuses on media and >isn't sip-specific.) I don't know where this is defined, either, though there are many documents that discuss cascaded MCUs (e.g., ITU-T F.702). Let me see if I can find a definition we can reference. > >Also, s/When creating a cascaded conferencing/When creating a cascaded >conference/ Fixed that. > >Section 9.3: > >It would be very helpful to see subsequent signaling in this case. >Suppose Alice subsequently sends a reINVITE. What will that look like? >(Alice will send it with {A,B}. Does the B2BUA change it to {A,C} or >leave it alone? Either way I presume Carol sends back {A,C}.) OK. Done. That would be: | (Suppose Alice modifies the session) | {A,B} |--------------------re-INVITE------------------->| {C,A} |<--------------------200 OK----------------------| {A,C} |-----------------------ACK---------------------->| The text description to go with that is: "Since Alice never received Carol’s UUID from the B2BUA, when Alice later attempts to modify the session with a re-INVITE, Alice would send the “remote-uuid” = “B” toward Carol. Carol replies with the “local-uuid” = “A”, “remote-uuid” = “A” to reflect what was received in the INVITE (which Carol already knew from previous exchanges with the B2BUA). Alice then include “remote-uuid” = “C” in the following ACK message." Sound OK? Paul
- [Insipid] draft-ietf-insipid-session-id-13 Paul E. Jones
- Re: [Insipid] draft-ietf-insipid-session-id-13 Paul E. Jones
- Re: [Insipid] draft-ietf-insipid-session-id-13 DRAGE, Keith (Keith)
- Re: [Insipid] draft-ietf-insipid-session-id-13 Paul E. Jones
- Re: [Insipid] draft-ietf-insipid-session-id-13 DRAGE, Keith (Keith)
- Re: [Insipid] draft-ietf-insipid-session-id-13 R.Jesske
- Re: [Insipid] draft-ietf-insipid-session-id-13 Paul Kyzivat
- Re: [Insipid] draft-ietf-insipid-session-id-13 Paul E. Jones
- Re: [Insipid] draft-ietf-insipid-session-id-13 Paul Kyzivat
- Re: [Insipid] draft-ietf-insipid-session-id-13 Paul E. Jones
- Re: [Insipid] draft-ietf-insipid-session-id-13 Paul E. Jones
- Re: [Insipid] draft-ietf-insipid-session-id-13 Paul Kyzivat