From nobody Mon Oct 10 00:12:09 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06EA1294A5 for ; Mon, 10 Oct 2016 00:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 geB0QBaXy97f for ; Mon, 10 Oct 2016 00:12:06 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 2287A1294B3 for ; Mon, 10 Oct 2016 00:12:06 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id s49so45530158qta.0 for ; Mon, 10 Oct 2016 00:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=CyKWPmICtPbIk+v0YQlJ7HCCZuu8AJI7aI+DCxf3+nE=; b=HKPw/jidAR0dyDU/D6EU4xcUnh+H+ZX2PdsdzFFPJvJA6S46+jOoVVfcJgy2b24PNT YiIHIwE8vh6C2B79xzDbFz/ysdCK+QZC4cPfSOpIdoZLaLWwmxApyzCUPow+egCj3iD3 bDWhJROHkRUYDtUjfrPzyzGzMS1e3Xg4picjxiMcTmwBx+hYJcEs56UIMNHA7VHG+GHf IZqdG03IyhBgb7gccCMKfsLCs/c1n5fCtiX7Ga90rfxS7x6LLFUadwH6BnAKi6uhTMUw nBVqn9EZ0nmiXe0W4uWVEg2EhzTalV+duNY7ntq2W6GSqGKg6X+BdpFf6SaDeA9HRJ2z 2xvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CyKWPmICtPbIk+v0YQlJ7HCCZuu8AJI7aI+DCxf3+nE=; b=Wd2D++YPWl9AfePdsTzboW99ungs+z3kXUM/CxoVHldxBpJah4UHD1Hm1Q94kpjRNs 1pNBcTGuWwQlV6YLF5ODtDo6T1TTUftoDP161u55NI59EUljrLPaqoDyWd5CrqCtS7Ur /xnEW6eqalXG3XGZYl/b0k/Oot9gFtNycRttgSna7gnHjl1f3o/VjlMGyTCPnzRnw+2W +0LLKamfVsT6k4twehgL8SxzBjNIn9QOed98zDfkqGPNlE2mzsHI6CXmciDPyliI+LBC 6m8ttMPG49G5DrJ/381x1Rp2fXvEy9FVGdjAeo7SjSuKJjiKYfNsD4O6eE+F5qW0qClx ZyMA== X-Gm-Message-State: AA6/9RkNleutB0vtYtiRX7LfDW+2yFJv8LCOfbTKINSRe3DnHDEbpoqjmOdAdE7KPZTciYb3rus8oYIVw0Wihw== X-Received: by 10.200.45.9 with SMTP id n9mr29538032qta.52.1476083525104; Mon, 10 Oct 2016 00:12:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.147.252 with HTTP; Mon, 10 Oct 2016 00:12:04 -0700 (PDT) From: Yehoshua Gev Date: Mon, 10 Oct 2016 10:12:04 +0300 Message-ID: To: sipcore , draft-sparks-sipcore-name-addr-guidance@tools.ietf.org Content-Type: multipart/alternative; boundary=001a1141cb582c511f053e7d7a01 Archived-At: Subject: [sipcore] draft-sparks-sipcore-name-addr-guidance-01: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 07:12:08 -0000 --001a1141cb582c511f053e7d7a01 Content-Type: text/plain; charset=UTF-8 Hi, Regarding the following paragraph in section 1: It is important to note that a message formed without honoring the constraint will still be syntactically valid, but would be interpreted differently. The characters after the comma, question mark, or semicolon would be interpreted as header field parameters or additional header field values as discussed in section 7.3.1 of [RFC3261]. How about the following often-seen form: Refer-To: sip:123@host?Replaces=1111%3Bto-tag%3Dtag1%3Bfrom-tag%3Dtag2 I don't see how it fits with the paragraph above. It does not honor the constraint, but according to the suggested interpretation (as header field parameters) it will not be syntactically valid. Can it be clarified whether this form is syntactically invalid, and perhaps write the way to interpret it in a normative manner? Thanks, Yehoshua --001a1141cb582c511f053e7d7a01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Regarding the following = paragraph in section 1:

=C2=A0 =C2=A0It is importa= nt to note that a message formed without honoring the
=C2=A0 =C2= =A0constraint will still be syntactically valid, but would be
=C2= =A0 =C2=A0interpreted differently.=C2=A0 The characters after the comma, qu= estion
=C2=A0 =C2=A0mark, or semicolon would be interpreted as he= ader field parameters or
=C2=A0 =C2=A0additional header field val= ues as discussed in section 7.3.1 of
=C2=A0 =C2=A0[RFC3261].

How about the following often-seen form:
=C2=A0 Refer-To: sip:123@host?Replaces=3D1111%3Bto-tag%3Dtag1%3= Bfrom-tag%3Dtag2

I don't see how it fits with = the paragraph above.
It does not honor the constraint, but accord= ing to the suggested interpretation
(as header field parameters) = it will not be syntactically valid.

Can it be clar= ified whether this form is syntactically invalid, and perhaps write
the way to interpret it in a normative manner?

= Thanks,
Yehoshua

--001a1141cb582c511f053e7d7a01-- From nobody Tue Oct 11 06:52:25 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DAE129555 for ; Tue, 11 Oct 2016 06:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=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 J4yMICY7VhcW for ; Tue, 11 Oct 2016 06:52:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BCB1B129542 for ; Tue, 11 Oct 2016 06:52:17 -0700 (PDT) Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9BDqFUO070378 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Tue, 11 Oct 2016 08:52:16 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local To: sipcore@ietf.org References: From: Robert Sparks Message-ID: <306c1f57-4954-1705-2153-76a5d411baff@nostrum.com> Date: Tue, 11 Oct 2016 08:52:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------26659308C5E16FBAFCB06940" Archived-At: Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-01: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 13:52:25 -0000 This is a multi-part message in MIME format. --------------26659308C5E16FBAFCB06940 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Inlin On 10/10/16 2:12 AM, Yehoshua Gev wrote: > Hi, > > Regarding the following paragraph in section 1: > > It is important to note that a message formed without honoring the > constraint will still be syntactically valid, but would be > interpreted differently. The characters after the comma, question > mark, or semicolon would be interpreted as header field parameters or > additional header field values as discussed in section 7.3.1 of > [RFC3261]. > > How about the following often-seen form: > > Refer-To: sip:123@host?Replaces=1111%3Bto-tag%3Dtag1%3Bfrom-tag%3Dtag2 > > I don't see how it fits with the paragraph above. > It does not honor the constraint, It _does_ fit the constraint, and is syntactically valid. The presence of %3D during parsing is not the same as the presence of a semi-colon - that's the point of having the escaped form. Section 19.1 of RFC3261 covers this. > but according to the suggested interpretation > (as header field parameters) it will not be syntactically valid. > > Can it be clarified whether this form is syntactically invalid, and > perhaps write > the way to interpret it in a normative manner? > > Thanks, > Yehoshua > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --------------26659308C5E16FBAFCB06940 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Inlin


On 10/10/16 2:12 AM, Yehoshua Gev wrote:
Hi,

Regarding the following paragraph in section 1:

   It is important to note that a message formed without honoring the
   constraint will still be syntactically valid, but would be
   interpreted differently.  The characters after the comma, question
   mark, or semicolon would be interpreted as header field parameters or
   additional header field values as discussed in section 7.3.1 of
   [RFC3261].

How about the following often-seen form:

  Refer-To: sip:123@host?Replaces=1111%3Bto-tag%3Dtag1%3Bfrom-tag%3Dtag2

I don't see how it fits with the paragraph above.
It does not honor the constraint,
It _does_ fit the constraint, and is syntactically valid.
The presence of %3D during parsing is not the same as the presence of a semi-colon - that's the point of having the escaped form.
Section 19.1 of RFC3261 covers this.
but according to the suggested interpretation
(as header field parameters) it will not be syntactically valid.

Can it be clarified whether this form is syntactically invalid, and perhaps write
the way to interpret it in a normative manner?

Thanks,
Yehoshua



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

--------------26659308C5E16FBAFCB06940-- From nobody Wed Oct 12 11:15:12 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AC6129563 for ; Wed, 12 Oct 2016 11:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 9ZUPWglbNRUA for ; Wed, 12 Oct 2016 11:15:08 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 786B3129552 for ; Wed, 12 Oct 2016 11:15:08 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-07v.sys.comcast.net with SMTP id uO2dboFetff8quO3XbAIcD; Wed, 12 Oct 2016 18:15:07 +0000 Received: from hobgoblin.ariadne.com ([73.16.37.18]) by resomta-ch2-16v.sys.comcast.net with SMTP id uO3Wb3on330PRuO3XbFnRM; Wed, 12 Oct 2016 18:15:07 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u9CIF5pE021525 for ; Wed, 12 Oct 2016 14:15:05 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u9CIF57d021522; Wed, 12 Oct 2016 14:15:05 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-Reply-To: <306c1f57-4954-1705-2153-76a5d411baff@nostrum.com> (rjsparks@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 12 Oct 2016 14:15:05 -0400 Message-ID: <87vawxwi1i.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfKO0xZUTjxG2ySgMCYfHXJmcozTA6kOG58uIwqt7dpz0o/BVvN6Ox3yFY5B8kOromBImoeko3+jgXeJFuFB8NsMG7augimQZaMRIT0a30pZuIRs1Vt4E Pw+Sf9cJDNYE3miH1GVa28PMkHOEvmVIq/1CVb2lxkvVlh7QBpaAyNrE Archived-At: Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-01: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 18:15:11 -0000 Robert Sparks writes: >> Refer-To: sip:123@host?Replaces=1111%3Bto-tag%3Dtag1%3Bfrom-tag%3Dtag2 >> >> I don't see how it fits with the paragraph above. >> It does not honor the constraint, > It _does_ fit the constraint, and is syntactically valid. As far as I can see, the above header is syntactically correct (per the ABNF in section 25.1), and its value can only be interpreted as a single addr-spec, that is, a SIP URI. The URI does contain a "headers" component. Since the URI contains a qustion mark, the constraint requires it to be written: Refer-To: But it can't be mis-interpreted if the angle brackets are omitted. It *seems* to me that the original constraint in section 20 needn't have mentioned question-mark as a problematic character. (Am I overlooking something? I don't have a header parser handy to check this.) Dale From nobody Thu Oct 13 00:32:51 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B7D12963D for ; Thu, 13 Oct 2016 00:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gMElzLCy1GJj for ; Thu, 13 Oct 2016 00:32:48 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 E2BBA128DF6 for ; Thu, 13 Oct 2016 00:32:47 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id z190so71908061qkc.2 for ; Thu, 13 Oct 2016 00:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D0Lg5Vv/3USmyk5HqqFthBMts2HNz/TVzDURU40jVfM=; b=0hYUYhkMzIAqBSfv72+AqRksCrFpxvSghTqzdYkeeXoepbkir1yHNzSwQxV3yFVlzo AjUUWVT+F6dZW/Iz4RtcRfeJURGdqWhIX1fbT+lJ7XyvaWJnuPVgL/t8SmCvhKa1FZuo LRNgjK6efmGf3gBmArMFX6zZhVnb/cm96SEbKHMN6x922qFGRfiLNQ2mxw3TKS/VVQxt 13ljuO+UTYkqdpWViVEWqXcuQ6157pkdB/2Rd7ecc2ixExarAjlQcya6DEkTHMZh9pBZ mwNnww9t2fe0w4X+jAntIlqwXBFGnp7z5pEQXuADUVfR+hld9v2HXwHWqnpys5hmshEn J1cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D0Lg5Vv/3USmyk5HqqFthBMts2HNz/TVzDURU40jVfM=; b=RbPw/x86gclv8mMBoePTMx++3yDnjEMI1YOybnrGcnO0hr99dQfI78ycC3UUNNBAwQ 1BYdSeLBwL4tpfW4r6jBD9arYm9CvauA7MMmO7fAUxPIFE3kLm0+ZavBMGPQFHX2jV3e HJhS70P1T91+Vc3bpRtO8AdBWOEJjMBVQAV+vZ9vO7PEmXqvAz9bq5YwLRD+mfgFRjer gt1Yr744RmyyxFko3hwtJlQ2nWkcfadS6ogNcjtO87LB3d9msW2ZO56OTtcUhtBL/oQY tT34juNR1mXXyYlYc8+x+HKTRwmSprDk6mZwAbUpulyOdf+iX7qi9pWuFwEWF6p0jMJk 2A0A== X-Gm-Message-State: AA6/9RkcboBO+/lIOCp5hKewXO8p5JgqmEFgNqKzyDq1Xe4ZR3s1oQhAIx7AkpE1HBHJ6lW2xvlv2+CHGjP3GQ== X-Received: by 10.55.162.205 with SMTP id l196mr4705554qke.20.1476343966831; Thu, 13 Oct 2016 00:32:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.147.252 with HTTP; Thu, 13 Oct 2016 00:32:46 -0700 (PDT) In-Reply-To: <87vawxwi1i.fsf@hobgoblin.ariadne.com> References: <306c1f57-4954-1705-2153-76a5d411baff@nostrum.com> <87vawxwi1i.fsf@hobgoblin.ariadne.com> From: Yehoshua Gev Date: Thu, 13 Oct 2016 10:32:46 +0300 Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a114fcd36b59a08053eba1dfe Archived-At: Cc: sipcore Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-01: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 07:32:50 -0000 --001a114fcd36b59a08053eba1dfe Content-Type: text/plain; charset=UTF-8 Thank you Robert and Dale for your detailed replies. Let me explain again my understanding of the paragraph I quoted, especially the sentence "The characters after the comma, question mark, or semicolon would be interpreted as header field parameters or additional header field values...". >From my understanding, the following header: (1a) Refer-To: sip:123@host;user=phone should be interpreted the same as: (1b) Refer-To: sip:<123@host>;user=phone Having the characters after the semicolon ("user=phone") interpreted as header field parameters. Using the same logic: (2a) Refer-To: sip:123@host;user=phone?Replaces=1111 will be equivalent to: (2b) Refer-To: ;user=phone?Replaces=1111 And: (3a) Refer-To: sip:123@host?Replaces=1111 equivalent to (3b) Refer-To: ?Replaces=1111 The last two interpretations are not syntactically correct, as the Refer-To header does not allow a question mark after the name-addr/addr-spec. For my point of view, the decision of the interpretation should be simple. The above indeed propose a simple rule (although not worded as a normative one) to decide where is the end of an addr-spec - when encountering a comma, a question mark, or a semicolon. However, this interpretation _does_ render some forms invalid. Am I misreading the paragraph? Thanks, Yehoshua On Wed, Oct 12, 2016 at 9:15 PM, Dale R. Worley wrote: > Robert Sparks writes: > >> Refer-To: sip:123@host?Replaces=1111%3Bto-tag%3Dtag1%3Bfrom-tag% > 3Dtag2 > >> > >> I don't see how it fits with the paragraph above. > >> It does not honor the constraint, > > > It _does_ fit the constraint, and is syntactically valid. > > As far as I can see, the above header is syntactically correct (per the > ABNF in section 25.1), and its value can only be interpreted as a single > addr-spec, that is, a SIP URI. The URI does contain a "headers" > component. > > Since the URI contains a qustion mark, the constraint requires it to be > written: > > Refer-To: 3Dtag2> > > But it can't be mis-interpreted if the angle brackets are omitted. > > It *seems* to me that the original constraint in section 20 needn't have > mentioned question-mark as a problematic character. > > (Am I overlooking something? I don't have a header parser handy to > check this.) > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a114fcd36b59a08053eba1dfe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you Robert and Dale for your detailed replies.
<= br>
Let me explain again my understanding of the paragraph I quot= ed, especially the sentence "The char= acters after the comma, question=C2=A0mark, or semicolon would be interpreted as header field parameters or=C2= =A0additional header field values..= .".

From my understanding, the followi= ng header:

=C2=A0 =C2=A0(1a)=C2=A0Refer-To: sip:123@host;user=3Dphone

should be interpreted the same as:

= =C2=A0 =C2=A0(1b)=C2=A0Refer-To: si= p:<123@host>;user=3Dphone

Having the ch= aracters after the semicolon ("user=3Dphone") interpreted as=C2=A0header field parameters.

Using the same= logic:

=
=C2=A0 =C2=A0(2a)=C2=A0Refer-To: sip:123@host;user=3Dphone?Replaces=3D11= 11

= will be equivalent to:

=C2=A0 =C2=A0(2b)=C2=A0Refer-To: <sip:123@host>;user=3Dphone?Replaces=3D1111

And:

=C2=A0 =C2= =A0(3a) Refer-To: sip:123@host?Repl= aces=3D1111

equivalent to=C2=A0<= /div>

=C2=A0 =C2=A0(3b)=C2=A0Refer-To: <sip:123@host>?Replaces=3D1111
=

The last two=C2=A0interpretations=C2=A0are not=C2= =A0syntactically correct, as the Refer-To header does not allow a question = mark after the name-addr/addr-spec.

For my point of view, the=C2=A0decisi= on=C2=A0of the interpretation should be simple. The above indeed propose a = simple rule (although not worded as a normative one) to decide where is the= end of an addr-spec - when=C2=A0encountering=C2=A0a=C2=A0comma, a question=C2=A0mark, or a semicolon.
However, this=C2=A0interpretation=C2=A0_does_ render some fo= rms invalid.

<= /div>
Am I misreading the paragraph?


Thanks,
Yehoshua=

<= div class=3D"gmail_extra">
On Wed, Oct 12, 20= 16 at 9:15 PM, Dale R. Worley <worley@ariadne.com> wrote:
Robert Sparks <rjsparks@nostrum.com> writes:
>>=C2=A0 =C2=A0Refer-To: sip:123@host?Replaces=3D1111%3Bto-tag%3= Dtag1%3Bfrom-tag%3Dtag2
>>
>> I don't see how it fits with the paragraph above.
>> It does not honor the constraint,

> It _does_ fit the constraint, and is syntactically valid.

As far as I can see, the above header is syntactically correct (per = the
ABNF in section 25.1), and its value can only be interpreted as a single addr-spec, that is, a SIP URI.=C2=A0 The URI does contain a "headers&q= uot;
component.

Since the URI contains a qustion mark, the constraint requires it to be
written:

=C2=A0 =C2=A0Refer-To: <sip:123@host?Replaces=3D1111%3Bto-tag%3Dtag= 1%3Bfrom-tag%3Dtag2>

But it can't be mis-interpreted if the angle brackets are omitted.

It *seems* to me that the original constraint in section 20 needn't hav= e
mentioned question-mark as a problematic character.

(Am I overlooking something?=C2=A0 I don't have a header parser handy t= o
check this.)

Dale

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

--001a114fcd36b59a08053eba1dfe-- From nobody Fri Oct 14 06:59:24 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38074129823 for ; Fri, 14 Oct 2016 06:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 bvP2rtLisPzH for ; Fri, 14 Oct 2016 06:59:13 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 3A60712980E for ; Fri, 14 Oct 2016 06:59:13 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id b81so194698261lfe.1 for ; Fri, 14 Oct 2016 06:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=38mFYP+8a/hsgJVUfXToRCYasKG4YGhu6WIzDOxKDQ8=; b=0nEmEtVoxDgjyYGkITTgBZ4stxVuDhCYRZ9fHdK5eU22iY64vgvnmk4KJhA2rQaLmq +johiA4dWCjWTwGRSMjAwFjV9C2DwoGfhT4gii5CD+dXNDyXRoK5UsaECSEw8i/QjdBe fWfx7Sh+QmhPrrjs9P483qL4hke5Oi7qvsN3AAxZbK03KTLKweG+j5utwe5g8Ow0Wl+r 3LU+atdMeGOe32vK0wBK0mxH9uJHfPo4+MpViWOHNhxF9I4NfCrGGT37OQ7AA5oQPlEV y/iAqnB2hMyPyqn9YH5hLb+t6vL3ui1KSWG89Bj4GLrRfT552Kn7yJJ+t82qi8JfcXgq 9nhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=38mFYP+8a/hsgJVUfXToRCYasKG4YGhu6WIzDOxKDQ8=; b=Lzh8dlTTT0IRfPf5qI1wkGLFqqGitt0p1oo6Xfzu//y61F9CiJkiz9k9vPFQdEqs2c WjbpIDNMaMDrDUUZ8zgbWISoDOFMDJE7dWGyINUJhb5SojaL+GfLzq12935D2yrP5wdI MfkJnE3Yf1AttPbj6DaWCme7SN+LpbBFWB8uYGzzHR7ITAofuhrKCTwZSaOSYV/sNW/l x/H8PgBZiKDioGqVHYarErRbJGjvv+VPWlsDzUz5zB51ERjLefVyA56EnHzktmeS6bys r/zaCSa1RiHEBON020EUweMCJeEwimKIFPUj39FlTOktTGTXRWvmU/ll5g/j+rEtT7Qv I/cQ== X-Gm-Message-State: AA6/9RlY2yjrPX2WnfjSIqX3Vti9vsmKP/8ezTP1xVR290MED9RdJIENzdQ1L5jOeMp1lZJOxFZ+AmDvyZlJeTFE X-Received: by 10.25.198.9 with SMTP id w9mr4081037lff.164.1476453551341; Fri, 14 Oct 2016 06:59:11 -0700 (PDT) From: Brett Tate References: <306c1f57-4954-1705-2153-76a5d411baff@nostrum.com> (rjsparks@nostrum.com) <87vawxwi1i.fsf@hobgoblin.ariadne.com> In-Reply-To: <87vawxwi1i.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIazL05WhswQOSRtIobjWbpTRvAIqAWqJkA Date: Fri, 14 Oct 2016 09:59:09 -0400 Message-ID: To: "Dale R. Worley" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-01: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 13:59:22 -0000 Hi, > It *seems* to me that the original constraint in > section 20 needn't have mentioned question-mark > as a problematic character. If anyone can locate the old 1998 emails, it looks like the question mark became part of the rule when creating draft-ietf-mmusic-sip-10. Based upon the following link, it looks like that was during the last call for comments. http://www.cs.columbia.edu/sip/history.html From nobody Fri Oct 14 07:51:21 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E57D129476 for ; Fri, 14 Oct 2016 07:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=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 jrZaNNvLXHHn for ; Fri, 14 Oct 2016 07:51:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0F74D1295BD for ; Fri, 14 Oct 2016 07:51:16 -0700 (PDT) Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9EEp6M2010978 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Fri, 14 Oct 2016 09:51:15 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local To: sipcore@ietf.org References: <306c1f57-4954-1705-2153-76a5d411baff@nostrum.com> <87vawxwi1i.fsf@hobgoblin.ariadne.com> From: Robert Sparks Message-ID: Date: Fri, 14 Oct 2016 09:51:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-01: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 14:51:20 -0000 On 10/14/16 8:59 AM, Brett Tate wrote: > Hi, > >> It *seems* to me that the original constraint in >> section 20 needn't have mentioned question-mark >> as a problematic character. > If anyone can locate the old 1998 emails, it looks like the question mark > became part of the rule when creating draft-ietf-mmusic-sip-10. I'm not sure what you're hoping to find by spelunking that history, but this will pull it up: https://mailarchive.ietf.org/arch/search/?qdr=c&start_date=1998-9-1&end_date=1998-12-01&email_list=mmusic&q=&as=1&subject=SIP The only thing related I see in there is in one of Anders' comments, but it doesn't directly explain the set of characters that were chosen. On a quick scan of the BNF I see that ? can appear in lots of surprising places unescaped (like in header names) - look at all the productions that include "unreserved" in their name and a literal '?' in their expansion and where those productions are used. But other than historical interest, where are we really going to go with this? > > Based upon the following link, it looks like that was during the last call > for comments. > > http://www.cs.columbia.edu/sip/history.html > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Oct 14 08:48:08 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AFC129855 for ; Fri, 14 Oct 2016 08:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 kQdDEsxB-2pj for ; Fri, 14 Oct 2016 08:48:04 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F8712984F for ; Fri, 14 Oct 2016 08:48:03 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-05v.sys.comcast.net with SMTP id v4ffb6JPD2FGMv4iIbE8tw; Fri, 14 Oct 2016 15:48:02 +0000 Received: from hobgoblin.ariadne.com ([73.16.37.18]) by resomta-ch2-07v.sys.comcast.net with SMTP id v4iHbxIl9V3TXv4iIbDA6G; Fri, 14 Oct 2016 15:48:02 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u9EFm1Dx012249; Fri, 14 Oct 2016 11:48:01 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u9EFm0PG012246; Fri, 14 Oct 2016 11:48:00 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Yehoshua Gev In-Reply-To: (yoshigev@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 14 Oct 2016 11:48:00 -0400 Message-ID: <871szj53v3.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfIgC02Fq9a2g3WZ+13YrZ+tS4QiZko4J19ciF1jgg5UFwPbxAgvcISkVOTWR2CqgMh8KTPB80ffIJxgnm0OpjmR4C6vKzn4FfcCpcCiSzb3vRUPETSoW WFh0VbxnC3NlhDARtPs3qE7ltw/nyUIzxkRf70Sb+EkrHR14ZH9gjP1+slKE6hVF2iqxFNup26qUfqivjcrNdMSC7GX7RYIQOiw= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-01: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:48:06 -0000 Yehoshua Gev writes: > (3a) Refer-To: sip:123@host?Replaces=1111 > > equivalent to > > (3b) Refer-To: ?Replaces=1111 > > The last two interpretations are not syntactically correct, as the Refer-To > header does not allow a question mark after the name-addr/addr-spec. > > For my point of view, the decision of the interpretation should be simple. > The above indeed propose a simple rule (although not worded as a normative > one) to decide where is the end of an addr-spec - when encountering a comma, > a question mark, or a semicolon. > However, this interpretation _does_ render some forms invalid. > > Am I misreading the paragraph? Yes, it looks to me like you are right, in a case like (3a) the rule makes it invalid. I suspect the correct response is "This rule has been in use since RFC 3261, so we're not going to change it now." We could use a different rule for Refer-To than we do for Contact, From, and To, but that would lead to madness... Dale From nobody Fri Oct 14 08:52:37 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4C1129649 for ; Fri, 14 Oct 2016 08:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=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 h1s9txoRe0R0 for ; Fri, 14 Oct 2016 08:52:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 192A01293FF for ; Fri, 14 Oct 2016 08:52:31 -0700 (PDT) Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9EFqUgg017391 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Fri, 14 Oct 2016 10:52:30 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local To: sipcore@ietf.org References: <306c1f57-4954-1705-2153-76a5d411baff@nostrum.com> <87vawxwi1i.fsf@hobgoblin.ariadne.com> From: Robert Sparks Message-ID: <5b7ffe51-424d-baff-c639-79114101ba86@nostrum.com> Date: Fri, 14 Oct 2016 10:52:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-01: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:52:35 -0000 Poking a little further down this path - '?' appears in a couple of places in absoluteURI (one the the alternatives for addr-spec). Now I'm getting deja-vu. RjS On 10/14/16 9:51 AM, Robert Sparks wrote: > > > On 10/14/16 8:59 AM, Brett Tate wrote: >> Hi, >> >>> It *seems* to me that the original constraint in >>> section 20 needn't have mentioned question-mark >>> as a problematic character. >> If anyone can locate the old 1998 emails, it looks like the question >> mark >> became part of the rule when creating draft-ietf-mmusic-sip-10. > I'm not sure what you're hoping to find by spelunking that history, > but this will pull it up: > https://mailarchive.ietf.org/arch/search/?qdr=c&start_date=1998-9-1&end_date=1998-12-01&email_list=mmusic&q=&as=1&subject=SIP > > > The only thing related I see in there is in one of Anders' comments, > but it doesn't directly explain the set of characters that were chosen. > > On a quick scan of the BNF I see that ? can appear in lots of > surprising places unescaped (like in header names) - look at all the > productions that include "unreserved" in their name and a literal '?' > in their expansion and where those productions are used. > > But other than historical interest, where are we really going to go > with this? >> >> Based upon the following link, it looks like that was during the last >> call >> for comments. >> >> http://www.cs.columbia.edu/sip/history.html >> >> _______________________________________________ >> 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 From nobody Fri Oct 14 09:16:46 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870D9129540 for ; Fri, 14 Oct 2016 09:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jTAhjZxPE3FS for ; Fri, 14 Oct 2016 09:16:43 -0700 (PDT) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id 037EF129530 for ; Fri, 14 Oct 2016 09:16:42 -0700 (PDT) X-AuditID: 1207440d-4c5ff700000009a7-f8-580104ea31dc Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 10.FB.02471.AE401085; Fri, 14 Oct 2016 12:16:42 -0400 (EDT) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u9EGGfnf016886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 14 Oct 2016 12:16:42 -0400 To: sipcore@ietf.org References: <306c1f57-4954-1705-2153-76a5d411baff@nostrum.com> <87vawxwi1i.fsf@hobgoblin.ariadne.com> <5b7ffe51-424d-baff-c639-79114101ba86@nostrum.com> From: Paul Kyzivat Message-ID: <16ec43e6-9091-061c-98e4-4b1277cacb33@alum.mit.edu> Date: Fri, 14 Oct 2016 12:16:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <5b7ffe51-424d-baff-c639-79114101ba86@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixO6iqPuKhTHC4OdXMYuvPzaxOTB6LFny kymAMYrLJiU1J7MstUjfLoEr48mHeawFh4UrNqx6ztTA+Ie/i5GTQ0LARKL5+FLGLkYuDiGB y4wSp/onsEA475gk5h/pZwWpEhbwlpjVeJIdxBYREJF4Nv0fG0RRK5PE6QWfGEESbAJaEnMO /WcBsXkF7CU+buplBrFZBFQl7u+eA9YsKpAmsX3dbmaIGkGJkzOfgNVzAtVvW9gHtoxZwFbi zlyIGmYBeYntb+cwT2Dkm4WkZRaSsllIyhYwMq9ilEvMKc3VzU3MzClOTdYtTk7My0st0jXS y80s0UtNKd3ECAk03h2M/9fJHGIU4GBU4uGd8YEhQog1say4MvcQoyQHk5Ior81XoBBfUn5K ZUZicUZ8UWlOavEhRgkOZiUR3iJmxggh3pTEyqrUonyYlDQHi5I4r9oSdT8hgfTEktTs1NSC 1CKYrAwHh5IE7zOQRsGi1PTUirTMnBKENBMHJ8hwHqDhAWDDiwsSc4sz0yHypxgVpcR5zzMB JQRAEhmleXC9sETwilEc6BVh3nsg7TzAJALX/QpoMBPQ4A9tDCCDSxIRUlINjBLVPz6dTDsf vCq/S+vR98Z/JV88pzgYiKzKX1jxuWe1tLbjnPx1yXJHhP4XGE6LvNHXkzS1d9Ek09Ia9oK3 tfv9VH5NeLhz7lVFXf8VBkWHMyRm71hX66kzc8WWjI1P/R998j/t92V29rJNv+WSrJ2qTkWf ros+UC0ZG3Rfi+eRQIscy1SxBCWW4oxEQy3mouJEAIShg07fAgAA Archived-At: Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-01: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 16:16:45 -0000 On 10/14/16 11:52 AM, Robert Sparks wrote: > Poking a little further down this path - '?' appears in a couple of > places in absoluteURI (one the the alternatives for addr-spec). > > Now I'm getting deja-vu. I have begun to think that the "proper" way to address this is to rewrite the syntax to remove the ambiguity. The change is bigger, but should be clearer. However that would make it harder to retrofit to lots of old rfcs. But the big problem is indeed with absoluteURI. ISTM that the best way to handle that is to always require <> around absoluteURI, at least anywhere that follows it with *anything*. Would that break anything currently legal? Thanks, Paul > RjS > > > On 10/14/16 9:51 AM, Robert Sparks wrote: >> >> >> On 10/14/16 8:59 AM, Brett Tate wrote: >>> Hi, >>> >>>> It *seems* to me that the original constraint in >>>> section 20 needn't have mentioned question-mark >>>> as a problematic character. >>> If anyone can locate the old 1998 emails, it looks like the question >>> mark >>> became part of the rule when creating draft-ietf-mmusic-sip-10. >> I'm not sure what you're hoping to find by spelunking that history, >> but this will pull it up: >> https://mailarchive.ietf.org/arch/search/?qdr=c&start_date=1998-9-1&end_date=1998-12-01&email_list=mmusic&q=&as=1&subject=SIP >> >> >> The only thing related I see in there is in one of Anders' comments, >> but it doesn't directly explain the set of characters that were chosen. >> >> On a quick scan of the BNF I see that ? can appear in lots of >> surprising places unescaped (like in header names) - look at all the >> productions that include "unreserved" in their name and a literal '?' >> in their expansion and where those productions are used. >> >> But other than historical interest, where are we really going to go >> with this? >>> >>> Based upon the following link, it looks like that was during the last >>> call >>> for comments. >>> >>> http://www.cs.columbia.edu/sip/history.html >>> >>> _______________________________________________ >>> 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 > From nobody Fri Oct 14 09:19:42 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D146B129855 for ; Fri, 14 Oct 2016 09:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3P9Yh916_whx for ; Fri, 14 Oct 2016 09:19:37 -0700 (PDT) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id 981A512984F for ; Fri, 14 Oct 2016 09:19:36 -0700 (PDT) X-AuditID: 1207440e-c63ff70000000b1c-51-58010596a108 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id C3.03.02844.69501085; Fri, 14 Oct 2016 12:19:34 -0400 (EDT) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u9EGJX2W017081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 14 Oct 2016 12:19:34 -0400 To: sipcore@ietf.org References: <871szj53v3.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: Date: Fri, 14 Oct 2016 12:19:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <871szj53v3.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUixO6iqDudlTHCYHqcxdcfm9gcGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJWx6L5NwVnOiu93nrM1MF5m72Lk5JAQMJHo3z2PsYuRi0NI4DKj xNUXHxhBEkIC75gkJm0rBLGFBbwlZjWeBGsQERCReDb9HxtEjZHEnpUNYDabgJbEnEP/WUBs XgF7iW279rKC2CwCqhL3+9+C9YoKpElsX7ebGaJGUOLkzCdg9ZwCxhKrZ38G28ssYCtxZy5E DbOAvMT2t3OYJzDyzULSMgtJ2SwkZQsYmVcxyiXmlObq5iZm5hSnJusWJyfm5aUW6Rrr5WaW 6KWmlG5ihAQY3w7G9vUyhxgFOBiVeHhnfGCIEGJNLCuuzD3EKMnBpCTKa/MVKMSXlJ9SmZFY nBFfVJqTWnyIUYKDWUmEt4iZMUKINyWxsiq1KB8mJc3BoiTOq7ZE3U9IID2xJDU7NbUgtQgm K8PBoSTBm8wC1ChYlJqeWpGWmVOCkGbi4AQZzgM03BGkhre4IDG3ODMdIn+KUVFKnPc8E1BC ACSRUZoH1wtLAK8YxYFeEebtBWnnASYPuO5XQIOZgAZ/aGMAGVySiJCSamD0dDxWznTAU3s3 /7LO831h7+7aToybqrvtukNJ1M77W0NXnvp6fJvKHwkjnZVZUy0L//7jfvrvjZyD7cF00yXt mrs1P/wKidz/xPm/eH5Q92Xlxh3cHJavK3Ye38b523l1MVeIwy/mS7si33ZLciZXd/eqBiwQ ubTr9plvnHu6Z6tUzvfSCb+oxFKckWioxVxUnAgAr+PgSdsCAAA= Archived-At: Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-01: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 16:19:40 -0000 On 10/14/16 11:48 AM, Dale R. Worley wrote: > Yehoshua Gev writes: >> (3a) Refer-To: sip:123@host?Replaces=1111 >> >> equivalent to >> >> (3b) Refer-To: ?Replaces=1111 >> >> The last two interpretations are not syntactically correct, as the Refer-To >> header does not allow a question mark after the name-addr/addr-spec. >> >> For my point of view, the decision of the interpretation should be simple. >> The above indeed propose a simple rule (although not worded as a normative >> one) to decide where is the end of an addr-spec - when encountering a comma, >> a question mark, or a semicolon. >> However, this interpretation _does_ render some forms invalid. >> >> Am I misreading the paragraph? > > Yes, it looks to me like you are right, in a case like (3a) the rule > makes it invalid. I suspect the correct response is "This rule has been > in use since RFC 3261, so we're not going to change it now." We could > use a different rule for Refer-To than we do for Contact, From, and To, > but that would lead to madness... There is *nothing* special about Refer-To that justifies treating it differently from other header fields. Thanks, Paul From nobody Tue Oct 18 15:28:47 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB6B1294DD for ; Tue, 18 Oct 2016 15:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5Rs7jru2Rngy for ; Tue, 18 Oct 2016 15:28:43 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 C89751294DC for ; Tue, 18 Oct 2016 15:28:43 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id 139so88043131itm.1 for ; Tue, 18 Oct 2016 15:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=1LQkuGDDyP/uKQ8sSe9oTElj+gDsASliAWEIK45+gA0=; b=A39COfMHoYG+egcHYVy5QyQAR2ruRNxmsx2z4XdevgJng7jgYcLP45hO0Hv8VapQ7r w/x0cTROUa6vKgizwQgdnPm/x9926DjrDUaboc8WuL6IHhAPkoTTmdNsc4J5DvzFeLyn 8m1yF4ZNCvIOxdZWRCYtgvffCMU3wME6/475Li9Q3nPaWgzCB6rSb1XwRx/tjgzK0o/x lgqmpSerqLEBzAy/nr6S6ocdcamTqEIu7XEYXqtJVI1VJz9mqdRKhfmk5LD8+xE8fD7T QsfAvFEdhmFjmAoyHp87ySTvEylb+1mLwo8GXrPQXymD0RqtoLunh4w46ZWdSWCFRWpX Ee/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1LQkuGDDyP/uKQ8sSe9oTElj+gDsASliAWEIK45+gA0=; b=mD1v2WEhWGJc8mKdCD8CMDaTd7/GSAsA8CrgXEBOJqBQ76X6wOKuj7peREVD5RBe+l 39wGrkCEq8gudMVA/fiI3fCUHrb0r7PNAWbohr9jAUQzBVoAeuDtgITyhvSrfUZ/tuyl KVjbv4vSE+OR2K045kzPR/4Fqsp/qa3+do57WVZuTAKjqehJkHITOhLaQiiZSMfgf2E+ 6Vrf2eE12mFF/Qq5jH+3u4M/q5nnCKJcY5IGiCR9BQAPED7fZui/T0hmlwr6Z38MjOst L1779JVeVVkgXPZxwerxee0PNNGQSlQPalEOnm8bjIq+ThMwBHNs8a40ZiLSaDcDCUSk yQZQ== X-Gm-Message-State: AA6/9Rn7zrlpSxw+c+c3rs5tj4tq1qSNiZmaoM9zeFEAWRReyXETafrFIlFu+Til/fa3xYlxKhPYcj+CRGw27g== X-Received: by 10.36.184.65 with SMTP id m62mr3650039ite.55.1476829722974; Tue, 18 Oct 2016 15:28:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.188.7 with HTTP; Tue, 18 Oct 2016 15:28:42 -0700 (PDT) From: Adnan Aziz Date: Wed, 19 Oct 2016 00:28:42 +0200 Message-ID: To: sipcore@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0481be082201053f2b3734 Archived-At: Subject: [sipcore] SIP Session setup X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 22:28:45 -0000 --94eb2c0481be082201053f2b3734 Content-Type: text/plain; charset=UTF-8 Hi Everyone, I have couple of basic questions regarding SIP session setup 1) is it compulsory for UAC to REGISTER to SIP server before session setup? 2) does SIP server checks if the UAC is REGISTERED to the SIP server if it has received an INVITE request from a UAC? If yes then how SIP server handle to the INVITE requests from unregistered UAC? Regards, Adnan Aziz --94eb2c0481be082201053f2b3734 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Everyone,
I have couple of= basic questions regarding SIP session setup

1) is it compulso= ry for UAC to REGISTER to SIP server before session setup?
2) doe= s SIP server checks if the UAC is REGISTERED to the SIP server if it has re= ceived an INVITE request from a UAC? If yes then how SIP server handle to t= he INVITE requests from unregistered UAC?

Regards,
Adnan Aziz


<= /div>
--94eb2c0481be082201053f2b3734-- From nobody Tue Oct 18 17:33:44 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778771288B8 for ; Tue, 18 Oct 2016 17:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 QjyCDkpQqBTB for ; Tue, 18 Oct 2016 17:33:41 -0700 (PDT) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id ED27B1293EC for ; Tue, 18 Oct 2016 17:33:40 -0700 (PDT) X-AuditID: 1207440e-c63ff70000000b1c-b5-5806bf623e9a Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id ED.60.02844.26FB6085; Tue, 18 Oct 2016 20:33:39 -0400 (EDT) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u9J0XcrQ013330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 18 Oct 2016 20:33:38 -0400 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: <9a5ef585-e685-028a-3d91-047209b56c59@alum.mit.edu> Date: Tue, 18 Oct 2016 20:33:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixO6iqJu8ny3CYO8zLouvPzaxOTB6LFny kymAMYrLJiU1J7MstUjfLoErY12vTMFkropdh4UbGFs4uhg5OSQETCRmH1/K1MXIxSEkcJlR YlnDdWYI5x2TxMbDD5hBqoQFNCROb3/HCmKLCIhIPJv+jw3EFhIIkPjytgMsziagJTHn0H8W EJtXwF5i0ffZYDaLgKrEnw+vwGpEBdIktq/bzQxRIyhxcuYTsBpOgUCJm7vmgtnMArYSd+ZC 1DALyEtsfzuHeQIj3ywkLbOQlM1CUraAkXkVo1xiTmmubm5iZk5xarJucXJiXl5qka6xXm5m iV5qSukmRkiI8e1gbF8vc4hRgINRiYfXw5otQog1say4MvcQoyQHk5Io7+GpQCG+pPyUyozE 4oz4otKc1OJDjBIczEoivMd3A+V4UxIrq1KL8mFS0hwsSuK8akvU/YQE0hNLUrNTUwtSi2Cy MhwcShK8CvuAGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGq4HU8BYXJOYWZ6ZD5E8xKkqJ8/7eC5QQ AElklObB9cJSwCtGcaBXhHk9QNp5gOkDrvsV0GAmoMHn8lhABpckIqSkGhj9lb5Wzyo4sejg q0X3A41vLFFO2v223Wtdlea2yKu/4p4cO2dyP2BhRFrkbX6VVSLHjSforSmu2dZVPn/JsnPd sae4j25f/ogtX99949wv3ge/MPo+OavRtaRT7MH6jvlXNAW4Z0teErxtxxXy+OYz9j1bVfo/ iGksPVBgfCyFnX+Stdq7rousSizFGYmGWsxFxYkAn5DoB9wCAAA= Archived-At: Subject: Re: [sipcore] SIP Session setup X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 00:33:42 -0000 On 10/18/16 6:28 PM, Adnan Aziz wrote: > Hi Everyone, > I have couple of basic questions regarding SIP session setup > > 1) is it compulsory for UAC to REGISTER to SIP server before session setup? > 2) does SIP server checks if the UAC is REGISTERED to the SIP server if > it has received an INVITE request from a UAC? If yes then how SIP server > handle to the INVITE requests from unregistered UAC? There is no simple answer to your question - it "depends". As far as the core sip specs envisioned things there is no need to register to send or receive calls. The primary reason for registering is so that a device that only has an ephemeral address can receive calls directed to a server with a nice public URL. BUT, the way SIP-based systems have evolved, the expectations are different. Access to the telephone network is gated by providers who have rules. It is quite often a requirement that you first register with a provider, then route outgoing calls through that provider, and it will then deliver incoming calls to you. The bottom line is that you need to do whatever is required by the ecosystem into which you are connecting. BTW, this sort of question is more properly addressed to: sip-implementors@lists.cs.columbia.edu Thanks, Paul From nobody Wed Oct 19 09:03:44 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452091299CB for ; Wed, 19 Oct 2016 09:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 kvxrIhOca200 for ; Wed, 19 Oct 2016 09:03:41 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60131299C7 for ; Wed, 19 Oct 2016 09:03:40 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 31786433881F; Wed, 19 Oct 2016 16:03:36 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9JG3c91023742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Oct 2016 16:03:38 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u9JG3be8000383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Oct 2016 18:03:37 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.150]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Wed, 19 Oct 2016 18:03:37 +0200 From: "Drage, Keith (Nokia - GB)" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP Session setup Thread-Index: AQHSKY8CcKu3hF+gNESWIgJ/iPwQ36CuzDeAgADxqFA= Date: Wed, 19 Oct 2016 16:03:36 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF92B01@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <9a5ef585-e685-028a-3d91-047209b56c59@alum.mit.edu> In-Reply-To: <9a5ef585-e685-028a-3d91-047209b56c59@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] SIP Session setup X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 16:03:43 -0000 It is worth noting that many providers require registration because they co= mbine the registration step with authentication and estabalishment of any s= ecurity association, rather than for any direct need of registration itself= (which at its simplest merely creates bindings in the RFC 3261 location se= rver). Other procedures may also be linked to the registration step, e.g. i= nitiation of SigComp, creation of a chain of proxies for both incoming and = outgoing calls, and so on. Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 19 October 2016 01:34 To: sipcore@ietf.org Subject: Re: [sipcore] SIP Session setup On 10/18/16 6:28 PM, Adnan Aziz wrote: > Hi Everyone, > I have couple of basic questions regarding SIP session setup > > 1) is it compulsory for UAC to REGISTER to SIP server before session setu= p? > 2) does SIP server checks if the UAC is REGISTERED to the SIP server=20 > if it has received an INVITE request from a UAC? If yes then how SIP=20 > server handle to the INVITE requests from unregistered UAC? There is no simple answer to your question - it "depends". As far as the core sip specs envisioned things there is no need to register= to send or receive calls. The primary reason for registering is so that a = device that only has an ephemeral address can receive calls directed to a s= erver with a nice public URL. BUT, the way SIP-based systems have evolved, the expectations are different= . Access to the telephone network is gated by providers who have rules. It = is quite often a requirement that you first register with a provider, then = route outgoing calls through that provider, and it will then deliver incomi= ng calls to you. The bottom line is that you need to do whatever is required by the ecosyste= m into which you are connecting. BTW, this sort of question is more properly addressed to:=20 sip-implementors@lists.cs.columbia.edu Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore