Re: [salud] Christer's review of draft-ietf-salud-alert-info-urns-09
Laura Liess <laura.liess.dt@googlemail.com> Wed, 22 January 2014 14:06 UTC
Return-Path: <laura.liess.dt@googlemail.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609081A0236 for <salud@ietfa.amsl.com>; Wed, 22 Jan 2014 06:06:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.396
X-Spam-Level:
X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=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 6DSbMeDNibj4 for <salud@ietfa.amsl.com>; Wed, 22 Jan 2014 06:06:43 -0800 (PST)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 151D71A00D6 for <salud@ietf.org>; Wed, 22 Jan 2014 06:06:42 -0800 (PST)
Received: by mail-lb0-f171.google.com with SMTP id c11so351981lbj.30 for <salud@ietf.org>; Wed, 22 Jan 2014 06:06:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ArKn8BLzNq+TNDvIqF9IIxud8Psv82B/97tTPrYvVwA=; b=kB3Hw0g5WTLrBFqdms+2dasf//8HsDhj2hM7uuV9fft/zq7M7jnbuzjmL0RFAd99ox egyaGdXjpbZxG0G7mxt06QgtwWuISSj+CIb3qITSooNDvAbqP0EIXc2mfaR7qDoTrn90 Jz8AuOGkmjwoV8NS3qatt3Z5JlZg6ihjUUuHLGjumIBH42oI2/y/omfYfT4/upjV27s9 IvFhEBPpOFwpQP98sTH773OY9hdS+pK82jpNUUUXvcNdOt6+Q27l3tQPQwxzVOvRbtVm /U1SAVNRq09QxudUlHlGh2GMfeArNIurDIUMQpVdd0CZZHUlrbTCVfVwJ8p+hbAWcGxR xLpQ==
MIME-Version: 1.0
X-Received: by 10.112.72.70 with SMTP id b6mr1229620lbv.0.1390399601841; Wed, 22 Jan 2014 06:06:41 -0800 (PST)
Received: by 10.114.169.129 with HTTP; Wed, 22 Jan 2014 06:06:41 -0800 (PST)
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B11F58E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <7594FB04B1934943A5C02806D1A2204B1C5EF0E7@ESESSMB209.ericsson.se> <201401072131.s07LVQZs2347719@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C5F00D5@ESESSMB209.ericsson.se> <201401162107.s0GL7AKI2944531@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1D108F92@ESESSMB209.ericsson.se> <CACWXZj033ssRvpJPQ=V8LACYUW9SpySbf+Pi86XR6eu5YWmdcw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D11179F@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B11F58E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Date: Wed, 22 Jan 2014 15:06:41 +0100
Message-ID: <CACWXZj3GD8aEQCb+tpOEJum0rLDODpHR5K37wsjiNesvuuaw+A@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="001a11c23c405d1b6a04f08fa257"
Cc: "salud@ietf.org" <salud@ietf.org>
Subject: Re: [salud] Christer's review of draft-ietf-salud-alert-info-urns-09
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <salud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/salud>, <mailto:salud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/salud/>
List-Post: <mailto:salud@ietf.org>
List-Help: <mailto:salud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/salud>, <mailto:salud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 14:06:46 -0000
Keith, Christer proposed the folowing text: " When present in an INVITE request, the Alert-Info header field specifies an alternative ring tone to the UAS. When present in a non-100 provisional response, the Alert-Info header field specifies an alternative ringback tone to the UAC. A typical usage is for a proxy to insert this header field to provide a distinctive ring feature." I am fine with it but it seems to me that it does not meet your requirements. Would you like some modification to it and if yes could you make a proposal how to modify it? Thank you Laura 2014/1/21 DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> > The agreement we made is that we should not use the tables, but also > that the main text should accurately specify the requirements for which > methods are allowed to include header fields or not, preferably in a > generic way that accommodates new methods. So text that states "all > requests", "all requests initiating a new dialog" and so on. > > Even on an update, it may be preferable to specify it this way. > > regards > > Keith > > ------------------------------ > *From:* salud [mailto:salud-bounces@ietf.org] * On Behalf Of *Christer > Holmberg > *Sent:* 21 January 2014 11:29 > *To:* laura.liess.dt@googlemail.com > *Cc:* salud@ietf.org > > *Subject:* Re: [salud] Christer's review of > draft-ietf-salud-alert-info-urns-09 > > Hi Laura, > > SIPCORE some time ago decided not to use/maintain the header field > tables anymore, so that is why I didn't include it in my change suggestion. > > But, if you want to also change the table, I won’t object 😊 > > Regards, > > Christer > > Sent from Windows Mail > > *From:* laura.liess.dt@googlemail.com > *Sent:* Tuesday, January 21, 2014 12:54 PM > *To:* Hans-Christer Holmberg <christer.holmberg@ericsson.com> > *Cc:* Dale R. Worley <worley@ariadne.com>, salud@ietf.org > > Christer, Dale, > > IMO, the draft updates the RFC 3261 because it allows the usage of the > Alert-Info header field in all provisional responses 1xx except the 100 > response. This is described in the first two paragraphs of Section 1.2. > This paragraphs are OK in this section. > The third paragraph is usefull (it explains what the draft does) but, as > Christer remarked, it does not describe the update of the RFC3261 and so > it does not belong to this section. I would move this paragraph at the end > of Section 1.1. What do you think? > > Concerning the structure if the Section 1.2, I will put the text from > section 1.2 into a new main Section 2 and structure it as Christer proposes > in http://www.ietf.org/mail-archive/web/salud/current/msg00454.html. > But I think there are two places where we should update the 3261 text: > 1) Section 20.4 as proposed by Christer and > > 2) Table 2: Summary of header fields, A--O on page 161, the " 180" in > the row > > Alert-Info 180 ar - - - o - - > > should be changed in "1xx (excepting 100)" > > so we probably need two subsections "New text repalcing the > text.........of RFC 3261" . > Opinions? > > Thank you > Laura > > > > 2014/1/20 Christer Holmberg <christer.holmberg@ericsson.com> > >> Hi, >> >> >> BTW, the following sentence is unclear to me: >> >> >> >> "In practice, this specification extends Alert-Info in that it will >> >> cause the use of a new class of URIs and the use of multiple URIs." >> >> >> >> What does it mean? >> > >> > The idea is that, while 3261 syntactically and semantically *allows* >> non-HTTP URIs in Alert-Info, nobody ever used non-HTTP URIs in Alert-Info, >> and nobody implemented an interpretation of those URIs. >> > Thus, even though we are not changing what is officially permitted, >> implementers will have to change their code because the new *practice* will >> be an extension of the old practice. (And both the new practice and the >> old practice are a small subset of what is permitted by 3261.) >> >> Well, then you should use different wording. Because, the draft does not >> extend Alert-Info, it simply describes the usage of a new URN in the header >> field. >> >> >> >>>> Q9: >> >>>> ----- >> >>>> >> >>>> Section 4 defines the ABNF for the URN, but [there] is no text on >> >>>> how to "map" it into the Alert-Info header field ABNF: >> >>>> >> >>>> For example, I assume that the URN is encoded using the opaque-part >> >>>> format of the absoluteURI, and that the scheme value is "urn". I >> >>>> think it would be good to indicate that. >> >>> >> >>> Actually, we're depending on the fact (unstated in RFC 3261) that >> >>> any "absolute" URI (per RFC 3986) is allowed as a header field value >> >>> in Alert-Info, and that the URNs we are defining conform to the >> >>> absolute URI syntax. If the syntax for <absoluteURI> in RFC 3261 >> >>> didn't allow all absolute URIs, we'd have to amend RFC 3261. >> >> >> >> There are two different "structures" for absolute URI, and the URNs >> >> only fit into the opaque-part structure. >> >> >> >> In addition, as the URI requires a scheme value, I think we should >> >> explicitly say what it is. >> > >> > I guess my point is that the 3261 ABNF already allows all alert URNs to >> appear in Alert-Info, and there is no need to specify exactly how alert >> URNs are compatible with the 3261 ABNF. Anyone who cares exactly how this >> draft is directly compatible with the ABNF can see that by looking at the >> ABNF. >> > >> > Have there been other situations where this sort of syntax explication >> has been provided? >> >> I don't know - I am just commenting on how I think the draft could from >> my perspective be improved :) >> >> Regards, >> >> Christer >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> > >
- [salud] Christer's review of draft-ietf-salud-ale… Christer Holmberg
- Re: [salud] Christer's review of draft-ietf-salud… Dale R. Worley
- Re: [salud] Christer's review of draft-ietf-salud… Paul Kyzivat
- Re: [salud] Christer's review of draft-ietf-salud… Christer Holmberg
- Re: [salud] Christer's review of draft-ietf-salud… Christer Holmberg
- Re: [salud] Christer's review of draft-ietf-salud… Paul Kyzivat
- Re: [salud] Christer's review of draft-ietf-salud… Dale R. Worley
- Re: [salud] Christer's review of draft-ietf-salud… Paul Kyzivat
- Re: [salud] Christer's review of draft-ietf-salud… Christer Holmberg
- Re: [salud] Christer's review of draft-ietf-salud… Laura Liess
- Re: [salud] Christer's review of draft-ietf-salud… Christer Holmberg
- Re: [salud] Christer's review of draft-ietf-salud… Laura Liess
- Re: [salud] Christer's review of draft-ietf-salud… Christer Holmberg
- Re: [salud] Christer's review of draft-ietf-salud… DRAGE, Keith (Keith)
- Re: [salud] Christer's review of draft-ietf-salud… Laura Liess
- Re: [salud] Christer's review of draft-ietf-salud… Laura Liess
- Re: [salud] Christer's review of draft-ietf-salud… Christer Holmberg
- Re: [salud] Christer's review of draft-ietf-salud… Dale R. Worley
- Re: [salud] Christer's review of draft-ietf-salud… Christer Holmberg
- Re: [salud] Christer's review of draft-ietf-salud… Laura Liess
- Re: [salud] Christer's review of draft-ietf-salud… Christer Holmberg
- Re: [salud] Christer's review of draft-ietf-salud… Laura Liess
- Re: [salud] Christer's review of draft-ietf-salud… Christer Holmberg
- [salud] Fwd: Christer's review of draft-ietf-salu… Laura Liess
- Re: [salud] Fwd: Christer's review of draft-ietf-… Christer Holmberg