From laura.liess.dt@googlemail.com Tue Feb 1 09:21:25 2011 Return-Path: X-Original-To: salud@core3.amsl.com Delivered-To: salud@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710943A6BAE for ; Tue, 1 Feb 2011 09:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNjUDRIl1wlb for ; Tue, 1 Feb 2011 09:21:24 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 6F3C83A6915 for ; Tue, 1 Feb 2011 09:21:23 -0800 (PST) Received: by gyd12 with SMTP id 12so2953778gyd.31 for ; Tue, 01 Feb 2011 09:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=lyFMHZNp7Wx4cwYWdhJuGCQ/o5l7JrwKRZtFCl+pXFo=; b=CdYgDXz/NQF6qQlnx97UK6QYEQyo+TH3brpRnuC5VBScyJIZaWYeZkg4Cp6rbTI2n8 pDg30+SmZbKhzbVYjYIPvcJqFM36zrbbH1O2vFWRjm+d3yMn9M+qulMkZBkCgcYkmZef JK0OuAKn99j3xfymBHKfUDYd4SiLXyDNmY3/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=mHiDNp5Y5Qp3iT4OL77/6m/7rGjPdPvzNxdeRD/KWI9pulTA/GYQmfAhiWugG0PQp4 3/X1rJmPMi30+c8Rqm7KwloHy8ggcRUncje3so5V5xEvm+ugQKDMK840qcF/bG/Rnb+V DElaDt0KWi90d9r9muCBY3mJfWg9KkszzIunU= MIME-Version: 1.0 Received: by 10.151.83.7 with SMTP id k7mr862519ybl.68.1296581080593; Tue, 01 Feb 2011 09:24:40 -0800 (PST) Received: by 10.151.145.9 with HTTP; Tue, 1 Feb 2011 09:24:40 -0800 (PST) Date: Tue, 1 Feb 2011 18:24:40 +0100 Message-ID: From: Laura Liess To: Dale Worley , salud@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [salud] Next step for progressing draft-ietf-salud-alert-info-urns X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 17:21:25 -0000 Dale, There is currently no discussion on the draft on the mailing list. Keith proposed a mini last call on the requirements. I think it is a good idea, the mini last call could be even extended for sections 1 to 3. We discussed them in Maastricht and I incorporated the comments. When we are done with the requirements, we can restart the discussion on the key issue of the draft, Multiple URNs vs. Single URN, or have a webex or both. Thanks a lot Laura From dworley@avaya.com Thu Feb 10 10:14:58 2011 Return-Path: X-Original-To: salud@core3.amsl.com Delivered-To: salud@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394AE3A67A4 for ; Thu, 10 Feb 2011 10:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hW2czqzOj3oZ for ; Thu, 10 Feb 2011 10:14:57 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 34B173A659A for ; Thu, 10 Feb 2011 10:14:56 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALe5U02HCzI1/2dsb2JhbACla3OhLAKZF4VcBIUBikQ X-IronPort-AV: E=Sophos;i="4.60,451,1291611600"; d="scan'208";a="231841300" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Feb 2011 13:15:08 -0500 X-IronPort-AV: E=Sophos;i="4.60,451,1291611600"; d="scan'208";a="597699567" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 Feb 2011 13:15:07 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.215]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 10 Feb 2011 13:15:07 -0500 From: "Worley, Dale R (Dale)" To: "salud@ietf.org" Date: Thu, 10 Feb 2011 13:15:07 -0500 Thread-Topic: Everybody get to work! -- LAST CALL on requirements Thread-Index: AQHLyU5yDn0cn1YInkK/Oq3aez+Npg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [salud] Everybody get to work! -- LAST CALL on requirements X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 18:14:58 -0000 [as chair] I apologize that I've not been keeping up with the work in Salud. As you know, there has been little or no discussion of Laura's most recent = draft, draft-ietf-salud-alert-info-urns-00. So I am calling a mini-Last Ca= ll on the context and requirements sections, sections 1, 2, and 3. This LC= will run until Thursday, 24 February. So everybody please read through those sections and respond regarding anyth= ing that is incorrect, incomplete, or unworkable. Also, please examine any= apparent technical issues you have been considering; very often technical = issues are requirements issues in disguise, and we want to make those requi= rements issues explicit. Dale From john.elwell@siemens-enterprise.com Fri Feb 11 02:51:26 2011 Return-Path: X-Original-To: salud@core3.amsl.com Delivered-To: salud@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D693A6AED for ; Fri, 11 Feb 2011 02:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yHFS9JO-tLi for ; Fri, 11 Feb 2011 02:51:24 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 50AA03A694F for ; Fri, 11 Feb 2011 02:51:24 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3364334; Fri, 11 Feb 2011 11:51:37 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 3D9CE1EB82AE; Fri, 11 Feb 2011 11:51:37 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 11 Feb 2011 11:51:37 +0100 From: "Elwell, John" To: "Worley, Dale R (Dale)" , "salud@ietf.org" Date: Fri, 11 Feb 2011 11:51:35 +0100 Thread-Topic: Everybody get to work! -- LAST CALL on requirements Thread-Index: AQHLyU5yDn0cn1YInkK/Oq3aez+NppP7/nUw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [salud] Everybody get to work! -- LAST CALL on requirements X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 10:51:26 -0000 I have reviewed sections 1 to 3. In general this is on the right track, but= some attention to the wording is needed in a number of places. In particul= ar, in section 2, the language in the requirements statements should be a l= ot more precise in some cases. Specific comments: 1. Section 1.1: "The Session Initiation Protocol (SIP) [RFC3261] allows for user agent servers (UAS) and proxies to provide the specific ringback or ring tone to the user agent (UA)." The mention of UAS is confusing and probably not relevant, given the bidire= ctional usage of Alert-Info (in INVITE request, in 180 response). Also, SIP= doesn't provide a specific ringback or ring tone - it merely suggests a ri= ngback tone or ring tone to be used. I would suggest rewording as: "The Session Initiation Protocol (SIP) [RFC3261] includes a means to sugges= t to a user agent (UA) a particular ringback tone or ring tone to be used d= uring session establishment." 2. Section 1.1 "This mechanism does not ensure interoperability when there is no common understanding of the referenced content (different countries or vendors, hearing impaired) or when the user wants his own tones configured in the end device." I think this needs re-organising. The fundamental problem we are trying to = describe is "no common understanding", and this leads to issues when the us= er wants his own tones or other forms of rendering (e.g., hearing impaired)= . I would suggest the following rewording: "This mechanism hinders interoperability when there is no common understand= ing of the meaning of the referenced tone, which might be country- or vendo= r-specific. It can lead to problems for the user tying to interpret the ton= e and problems for the UA wanting to substitute its own tone (e.g., in acco= rdance with user preferences) or provide an alternative alerting mode (e.g.= , for hearing-impaired users)." 3. Section 1.1: "The downside is that if the recipient does not understand the URN then it will only be able to render a default ringback or ring tone. To provide the general awareness about the Alert-Info URNs this document provides IANA template for registering the URNs and defines several typical identifiers." I think these should be two separate paragraphs. Moreover, I think the seco= nd sentence needs some attention - the template is not "to provide general = awareness". Perhaps the following would be better: "This document provides a template for registering alert URNs and defines s= everal typical values." Or alternatively: "This document creates a new URN namespace and registry for alert indicatio= ns and registers some initial values." 4. Section 1.3: "This specification uses a number of terms to refer to the roles played by participants in, and objects of, the SIP Alerting for User Devices." This is hard to understand. What is/are "the SIP Alerting for User Devices"= ? Why can't it just say: "This specification uses a number of terms to refer to the roles involved i= n the use of alerting indications in SIP". 5. Section 2: " This section discusses the requirements for an identifier to transport the semantics of the signaling situation or the characteristics of the rendering." Would it be better to change "signaling situation" to "alerting situation"? 6. Section 2: "REQ-4: Indications include subsets which have distinctly different semantics, that is, they form disjoint "value spaces". For example, some indications should describe the semantics of the signaling situation whereas others should describe the audio characteristics of the signal. This implies that there is no single set of categories that can be used as independent coordinates of the value-space of indications." I am not sure I understand this at all. Are we trying to say that indicatio= ns within a subset have different semantics (in which case, what is the pur= pose of a subset?) or indications within a subset have similar semantics bu= t indications within different subsets have different semantics? Concerning= the last sentence, how do "categories" relate to "subsets" in the first se= ntence? What is meant by "coordinates of the value-space"? What exactly is = the requirement being expressed? It just seems to be a statement of facts. = I can't really propose new text without understanding intentions of the aut= hors. 7. Section 2: " - add further value spaces of indications whose semantics are not related to existing indications, and thus, whose categories differ from and do not interact with existing categories." How does this differ from the earlier bullet: - add further categories that are orthogonal to existing categories"? 8. Section 2: "REQ-7: An indication is transmitted from a specifier to a renderer, which must base its rendering decision only on the indication. In particular, there is no multi-message negotiation process or carrying of context from one indication to the next." This sounds more like a requirement on a recipient (UA) rather than a requi= rement on the mechanism. This section should confine itself to requirements= on the mechanism. Perhaps it should be expressed something like (as two se= parate requirements): "The mechanism must provide only an indication capability, not a negotiatio= n capability" and "The mechanism must not require an indication to depend on context provided= by a previous indication." 9. Section 2: " REQ-9: The renderer may be customized in ways that limit the set of signals that it can render, or it may be provided with a set of signals that have uncommon semantics. (The canonical example is a UA for the hearing-impaired.) (By REQ-7, the renderer has no way of transmitting this fact to the specifier.)" Not sure what the requirement is here. Should it be something along the lin= es of: "The mechanism must accommodate renderers that are limited in the set of si= gnals they can render..." 10. Section 2: " REQ-10: If the specifier and the renderer have designs that are properly coordinated, the indications must be able to reliably carry all extensions that are supported in the coordinated designs. In any other situation, it is not required from the renderer to perform the best possible rendering." Rather than "the indications must be able to reliably carry all extensions = that are supported in the coordinated designs", how about "the mechanism mu= st be capable of supporting all indications needed"? Concerning the last sentence, isn't this covered by REQ-09? 11. Section 2: "REQ-11: In any situation, the renderer must be able to perform close to the best possible rendering that it could do even the specifier had specific knowledge of the renderer's capabilities." I am not sure what this is trying to say. Is it trying to say that the spec= ifier might not know the renderer's capabilities, and that despite this, th= e renderer should try to get as close as possible to what the specifier has= specified? I don't know whether the following captures the intent: "The mechanism should facilitate rendering that is close to the intention o= f the specifier, even when the renderer does not have capabilities for an e= xact rendering." Note that I don't think this can be more than should strength - it will be = hard to measure the mechanism against this requirement. 12. Section 2: " REQ-12: The mechanism will allow interoperability for services as call waiting, forward, transfer-recall, auto-callback, hold-recall." Allowing these services to interoperate is outside the scope of this work. = It is only the indications relating to these services that are relevant. Th= is should say: " REQ-12: The mechanism will support indications relating to services suc= h as call waiting, forward, transfer-recall, auto-callback and hold-recall.= " 13. Section 2: " REQ-19: The mechanism will allow storage of the actual encoding locally rather than fetching it." Should it say "rendering" rather than "encoding"? 14. Section 3.2.1: "As call-waiting information may be subject to the callee's privacy concerns, the exposure of this information SHALL be done only if explicitly required by the user." We should not use RFC 2119 language in use case descriptions. Nits: - Change "header" to "header field" throughout (I don't think there is anyw= here that refers to the entire SIP header) - it is inconsistent at present= . - Use "ringback tone" instead of "ringback" throughout - it is inconsisten= t at present. - Change "Alert-Info SIP-header" to "SIP Alert-Info header field". - The language in the requirements should be made consistent. Sometimes "wi= ll" is used, sometimes "must" is used, and sometimes other constructs. The = subject of any requirement should in general be "the mechanism". Note that = in some requirements documents we have used RFC 2119 language, but there ar= e also opinions it should not be used for requirements. Given that this doc= ument also includes the mechanism, it would be better to avoid RFC 2119 lan= guage for requirements, and keep it for the mechanism. John > -----Original Message----- > From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org]=20 > On Behalf Of Worley, Dale R (Dale) > Sent: 10 February 2011 18:15 > To: salud@ietf.org > Subject: [salud] Everybody get to work! -- LAST CALL on requirements >=20 > [as chair] >=20 > I apologize that I've not been keeping up with the work in Salud. >=20 > As you know, there has been little or no discussion of=20 > Laura's most recent draft,=20 > draft-ietf-salud-alert-info-urns-00. So I am calling a=20 > mini-Last Call on the context and requirements sections,=20 > sections 1, 2, and 3. This LC will run until Thursday, 24 February. >=20 > So everybody please read through those sections and respond=20 > regarding anything that is incorrect, incomplete, or=20 > unworkable. Also, please examine any apparent technical=20 > issues you have been considering; very often technical issues=20 > are requirements issues in disguise, and we want to make=20 > those requirements issues explicit. >=20 > Dale > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > = From laura.liess.dt@googlemail.com Tue Feb 15 05:41:58 2011 Return-Path: X-Original-To: salud@core3.amsl.com Delivered-To: salud@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33D4F3A6D0A for ; Tue, 15 Feb 2011 05:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.017 X-Spam-Level: X-Spam-Status: No, score=-3.017 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iP4YGGloHmb for ; Tue, 15 Feb 2011 05:41:53 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 460533A6A6C for ; Tue, 15 Feb 2011 05:41:53 -0800 (PST) Received: by gxk27 with SMTP id 27so77934gxk.31 for ; Tue, 15 Feb 2011 05:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=0KNvoLf38Aq9pAukogmZycbQ5bbz0iC9yEeLbOwFj4g=; b=cxkO396Q28VCyO7dKhK7wDZ9/12mB6RcvZNgu9gxdZqydzhYovZDPbKKXzIlRx14+Y zJpJWjezGVqfP9x3XRCCigqz7pHYvt5jJ8pQQHIn9Y7ZC1dhaaN3TVz1RMDQC7o/cPKM /Z0GW8HjRBT0VpDPOmuLAb7fzS971APRdZ3vo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=YemiCwyK2RxkOoPuBe3bS6fcY+eK/PP2HP8GB0LhCjIXvJZk+Q47RngJL/LWI5MTeA 0BT4pVMC2RISViZeNpUkVmte4Qwdg5ikF1Yw85qhEbnOOLDvkLmFZ4BlAOr4dyJaWVaa 3zdHGrXyYUv/zly+wTzhTM3QuMaTPlZFJcXUk= MIME-Version: 1.0 Received: by 10.151.39.21 with SMTP id r21mr5936252ybj.296.1297777338588; Tue, 15 Feb 2011 05:42:18 -0800 (PST) Received: by 10.150.195.21 with HTTP; Tue, 15 Feb 2011 05:42:18 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Feb 2011 14:42:18 +0100 Message-ID: From: Laura Liess To: salud@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [salud] Fwd: Everybody get to work! -- LAST CALL on requirements X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 13:41:58 -0000 John, Thank you for the comments and especially for the elaborate text proposals. I agree with you and with your text proposals in most cases. Please see inline. 2011/2/11 Elwell, John : > I have reviewed sections 1 to 3. In general this is on the right track, b= ut some attention to the wording is needed in a number of places. In partic= ular, in section 2, the language in the requirements statements should be a= lot more precise in some cases. Specific comments: > > 1. Section 1.1: > "The Session Initiation Protocol (SIP) [RFC3261] allows for user agent > =A0 servers (UAS) and proxies to provide the specific ringback or ring > =A0 tone to the user agent (UA)." > The mention of UAS is confusing and probably not relevant, given the bidi= rectional usage of Alert-Info (in INVITE request, in 180 response). Also, S= IP doesn't provide a specific ringback or ring tone - it merely suggests a = ringback tone or ring tone to be used. I would suggest rewording as: > "The Session Initiation Protocol (SIP) [RFC3261] includes a means to sugg= est to a user agent (UA) a particular ringback tone or ring tone to be used= during session establishment." [LL] =A0Sounds good. The restriction to the UAS in the draft is wrong. > > 2. Section 1.1 > "This mechanism does not ensure interoperability when there is no > =A0 common understanding of the referenced content (different countries > =A0 or vendors, hearing impaired) or when the user wants his own tones > =A0 configured in the end device." > I think this needs re-organising. The fundamental problem we are trying t= o describe is "no common understanding", and this leads to issues when the = user wants his own tones or other forms of rendering (e.g., hearing impaire= d). I would suggest the following rewording: > "This mechanism hinders interoperability when there is no common understa= nding of the meaning of the referenced tone, which might be country- or ven= dor-specific. It can lead to problems for the user tying to interpret the t= one and problems for the UA wanting to substitute its own tone (e.g., in ac= cordance with user preferences) or provide an alternative alerting mode (e.= g., for hearing-impaired users)." [LL] OK > > 3. Section 1.1: > "The downside is that if the recipient does not understand the URN > =A0 then it will only be able to render a default ringback or ring tone. > =A0 To provide the general awareness about the Alert-Info URNs this > =A0 document provides IANA template for registering the URNs and defines > =A0 several typical identifiers." > I think these should be two separate paragraphs. Moreover, I think the se= cond sentence needs some attention - the template is not "to provide genera= l awareness". Perhaps the following would be better: > "This document provides a template for registering alert URNs and defines= several typical values." > Or alternatively: > "This document creates a new URN namespace and registry for alert indicat= ions and registers some initial values." > [LL] Yes. I am fine with both proposals, with a slight preference for the second. > 4. Section 1.3: > "This specification uses a number of terms to refer to the roles > =A0 played by participants in, and objects of, the SIP Alerting for User > =A0 Devices." > This is hard to understand. What is/are "the SIP Alerting for User Device= s"? Why can't it just say: > "This specification uses a number of terms to refer to the roles involved= in the use of alerting indications in SIP". [LL] Agree. > > 5. Section 2: > " =A0 This section discusses the requirements for an identifier to > =A0 transport the semantics of the signaling situation or the > =A0 characteristics of the rendering." > Would it be better to change "signaling situation" to "alerting situation= "? [LL] OK for me. > > 6. Section 2: > "REQ-4: Indications include subsets which have distinctly different > =A0 semantics, that is, they form disjoint "value spaces". =A0For example= , > =A0 some indications should describe the semantics of the signaling > =A0 situation whereas others should describe the audio characteristics of > =A0 the signal. =A0This implies that there is no single set of categories > =A0 that can be used as independent coordinates of the value-space of > =A0 indications." > I am not sure I understand this at all. Are we trying to say that indicat= ions within a subset have different semantics (in which case, what is the p= urpose of a subset?) or indications within a subset have similar semantics = but indications within different subsets have different semantics? [LL] The second is the case. The text is more an explanation of REQ-3 than an independent requirement, but in fact im makes things more confusing. I think the best thing would be to discard it. > > 7. Section 2: > " - add further value spaces of indications whose semantics are not > =A0 related to existing indications, and thus, whose categories differ > =A0 from and do not interact with existing categories." > How does this differ from the earlier bullet: > - add further categories that are orthogonal to existing categories"? =A0[LL] There is practically no difference between the two bullets. I think the first bullelt is more clear, so let's discard the last bullet. Is this OK? > > 8. Section 2: > "REQ-7: An indication is transmitted from a specifier to a renderer, > =A0 which must base its rendering decision only on the indication. =A0In > =A0 particular, there is no multi-message negotiation process or carrying > =A0 of context from one indication to the next." > This sounds more like a requirement on a recipient (UA) rather than a req= uirement on the mechanism. This section should confine itself to requiremen= ts on the mechanism. Perhaps it should be expressed something like (as two = separate requirements): > "The mechanism must provide only an indication capability, not a negotiat= ion capability" > and > "The mechanism must not require an indication to depend on context provid= ed by a previous indication." [LL ] It's OK for me. > > 9. Section 2: > " =A0REQ-9: The renderer may be customized in ways that limit the set of > =A0 signals that it can render, or it may be provided with a set of > =A0 signals that have uncommon semantics. =A0(The canonical example is a = UA > =A0 for the hearing-impaired.) =A0(By REQ-7, the renderer has no way of > =A0 transmitting this fact to the specifier.)" > Not sure what the requirement is here. Should it be something along the l= ines of: >"The mechanism must accommodate renderers that are limited in the set of s= ignals they can render..." [LL] What do you think about "The mechanism must be able to accommodate renderers that are customized with a limited or uncomon set of signals they can render." =A0Just "Limited" is to me like the renderer would be an old, very simple PSTN-phone. I wouldn't call hearing-impaired phones customized =A0for video and text =A0to be "limited in the set of signals they can render", rather "uncommon". > > 10. Section 2: > " =A0 REQ-10: If the specifier and the renderer have designs that are > =A0 properly coordinated, the indications must be able to reliably carry > =A0 all extensions that are supported in the coordinated designs. =A0In a= ny > =A0 other situation, it is not required from the renderer to perform the > =A0 best possible rendering." > Rather than "the indications must be able to reliably carry all extension= s that are supported in the coordinated designs", how about "the mechanism = must be capable of supporting all indications needed"? [LL]Fine. > Concerning the last sentence, isn't this covered by REQ-09? [ LL] I wouldn't say so. Req-9 means that the mechanism should work well also, e.g., for end devices of hearing impaired, customized to render text or video instead of ringing tones. The last sentence in Req-10 means that, e.g., if we attach an AT&T =A0SIP-phone =A0the DT SIP-network we may not get the rendering intended by DT and this is fine. > > 11. Section 2: > "REQ-11: In any situation, the renderer must be able to perform close > =A0 to the best possible rendering that it could do even the specifier > =A0 had specific knowledge of the renderer's capabilities." > I am not sure what this is trying to say. Is it trying to say that the sp= ecifier might not know the renderer's capabilities, and that despite this, = the renderer should try to get as close as possible to what the specifier h= as specified? I don't know whether the following captures the intent: > "The mechanism should facilitate rendering that is close to the intention= of the specifier, even when the renderer does not have capabilities for an= exact rendering." > Note that I don't think this can be more than should strength - it will b= e hard to measure the mechanism against this requirement. > [LL] Yes, a "no" is missing in the text. I like much better your text proposal. An should is fine. > 12. Section 2: > " =A0 REQ-12: The mechanism will allow interoperability for services as > =A0 call waiting, forward, transfer-recall, auto-callback, hold-recall." > Allowing these services to interoperate is outside the scope of this work= . It is only the indications relating to these services that are relevant. = This should say: > " =A0 REQ-12: The mechanism will support indications relating to services= such as call waiting, forward, transfer-recall, auto-callback and hold-rec= all." [LL] Yes, fine. > > 13. Section 2: > " =A0 REQ-19: The mechanism will allow storage of the actual encoding > =A0 locally rather than fetching it." > Should it say "rendering" rather than "encoding"? [LL] What would you say to "rendering representation" ? But I am OK with "rendering", too. > > 14. Section 3.2.1: > "As > =A0 call-waiting information may be subject to the callee's privacy > =A0 concerns, the exposure of this information SHALL be done only if > =A0 explicitly required by the user." > We should not use RFC 2119 language in use case descriptions. [LL] OK. I will put shall in lower case letters. Otherrwise it is ok, I thi= nk? > > > Nits: > - Change "header" to "header field" throughout (I don't think there is an= ywhere that refers to the entire SIP header) - =A0it is inconsistent at pre= sent. > - Use "ringback tone" instead of "ringback" throughout =A0- it is inconsi= stent at present. > - Change "Alert-Info SIP-header" to "SIP Alert-Info header field". > - The language in the requirements should be made consistent. Sometimes "= will" is used, sometimes "must" is used, and sometimes other constructs. Th= e subject of any requirement should in general be "the mechanism". Note tha= t in some requirements documents we have used RFC 2119 language, but there = are also opinions it should not be used for requirements. Given that this d= ocument also includes the mechanism, it would be better to avoid RFC 2119 l= anguage for requirements, and keep it for the mechanism. [LL] OK. Thanks a lot Laura > > John > >> -----Original Message----- >> From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] >> On Behalf Of Worley, Dale R (Dale) >> Sent: 10 February 2011 18:15 >> To: salud@ietf.org >> Subject: [salud] Everybody get to work! -- LAST CALL on requirements >> >> [as chair] >> >> I apologize that I've not been keeping up with the work in Salud. >> >> As you know, there has been little or no discussion of >> Laura's most recent draft, >> draft-ietf-salud-alert-info-urns-00. =A0So I am calling a >> mini-Last Call on the context and requirements sections, >> sections 1, 2, and 3. =A0This LC will run until Thursday, 24 February. >> >> So everybody please read through those sections and respond >> regarding anything that is incorrect, incomplete, or >> unworkable. =A0Also, please examine any apparent technical >> issues you have been considering; very often technical issues >> are requirements issues in disguise, and we want to make >> those requirements issues explicit. >> >> Dale >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > From john.elwell@siemens-enterprise.com Tue Feb 15 07:35:20 2011 Return-Path: X-Original-To: salud@core3.amsl.com Delivered-To: salud@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768753A6BA0 for ; Tue, 15 Feb 2011 07:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.583 X-Spam-Level: X-Spam-Status: No, score=-103.583 tagged_above=-999 required=5 tests=[AWL=1.016, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3PF1Q8T4ePq for ; Tue, 15 Feb 2011 07:35:19 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 270ED3A6B8E for ; Tue, 15 Feb 2011 07:35:17 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3410032; Tue, 15 Feb 2011 16:35:43 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 23EB01EB82B0; Tue, 15 Feb 2011 16:35:43 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 15 Feb 2011 16:35:43 +0100 From: "Elwell, John" To: Laura Liess , "salud@ietf.org" Date: Tue, 15 Feb 2011 16:35:42 +0100 Thread-Topic: [salud] Fwd: Everybody get to work! -- LAST CALL on requirements Thread-Index: AcvNFjERwAayUNu+S0aL5zVxGl3z1wAAW5rg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [salud] Fwd: Everybody get to work! -- LAST CALL on requirements X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 15:35:20 -0000 Laura, I have stripped out those items where we are in agreement. See below for ot= her comments: > > 3. Section 1.1: > > "The downside is that if the recipient does not understand the URN > > =A0 then it will only be able to render a default ringback or=20 > ring tone. > > =A0 To provide the general awareness about the Alert-Info URNs this > > =A0 document provides IANA template for registering the URNs=20 > and defines > > =A0 several typical identifiers." > > I think these should be two separate paragraphs. Moreover,=20 > I think the second sentence needs some attention - the=20 > template is not "to provide general awareness". Perhaps the=20 > following would be better: > > "This document provides a template for registering alert=20 > URNs and defines several typical values." > > Or alternatively: > > "This document creates a new URN namespace and registry for=20 > alert indications and registers some initial values." > > > [LL] Yes. I am fine with both proposals, with a slight preference for > the second. [JRE] Yes, my slight preference is for the second. > > 6. Section 2: > > "REQ-4: Indications include subsets which have distinctly different > > =A0 semantics, that is, they form disjoint "value spaces". =A0 > For example, > > =A0 some indications should describe the semantics of the signaling > > =A0 situation whereas others should describe the audio=20 > characteristics of > > =A0 the signal. =A0This implies that there is no single set of=20 > categories > > =A0 that can be used as independent coordinates of the value-space of > > =A0 indications." > > I am not sure I understand this at all. Are we trying to=20 > say that indications within a subset have different semantics=20 > (in which case, what is the purpose of a subset?) or=20 > indications within a subset have similar semantics but=20 > indications within different subsets have different semantics? > [LL] The second is the case. The text is more an explanation of REQ-3 > than an independent requirement, but in fact im makes things more > confusing. I think the best thing would be to discard it. [JRE] Deletion would be fine. > > 7. Section 2: > > " - add further value spaces of indications whose semantics are not > > =A0 related to existing indications, and thus, whose categories differ > > =A0 from and do not interact with existing categories." > > How does this differ from the earlier bullet: > > - add further categories that are orthogonal to existing=20 > categories"? > =A0[LL] There is practically no difference between the two bullets. I > think the first bullelt is more clear, so let's discard the last > bullet. Is this OK? [JRE] Yes. > > 9. Section 2: > > " =A0REQ-9: The renderer may be customized in ways that limit=20 > the set of > > =A0 signals that it can render, or it may be provided with a set of > > =A0 signals that have uncommon semantics. =A0(The canonical=20 > example is a UA > > =A0 for the hearing-impaired.) =A0(By REQ-7, the renderer has no way of > > =A0 transmitting this fact to the specifier.)" > > Not sure what the requirement is here. Should it be=20 > something along the lines of: > >"The mechanism must accommodate renderers that are limited=20 > in the set of signals they can render..." > [LL] What do you think about "The mechanism must be able to > accommodate renderers that are customized with a limited or uncomon > set of signals they can render." =A0Just "Limited" is to me like the > renderer would be an old, very simple PSTN-phone. I wouldn't call > hearing-impaired phones customized =A0for video and text =A0to be "limite= d > in the set of signals they can render", rather "uncommon". [JRE] I would be happy with your modified text, although we might wish to c= ite hearing-impaired phones as an example of devices that have uncommon ren= derings - otherwise it might no be clear what is meant. >=20 > > > > 10. Section 2: > > " =A0 REQ-10: If the specifier and the renderer have designs that are > > =A0 properly coordinated, the indications must be able to=20 > reliably carry > > =A0 all extensions that are supported in the coordinated=20 > designs. =A0In any > > =A0 other situation, it is not required from the renderer to=20 > perform the > > =A0 best possible rendering." > > Rather than "the indications must be able to reliably carry=20 > all extensions that are supported in the coordinated=20 > designs", how about "the mechanism must be capable of=20 > supporting all indications needed"? > [LL]Fine. >=20 > > Concerning the last sentence, isn't this covered by REQ-09? > [ LL] I wouldn't say so. Req-9 means that the mechanism should work > well also, e.g., for end devices of hearing impaired, customized to > render text or video instead of ringing tones. The last sentence in > Req-10 means that, e.g., if we attach an AT&T =A0SIP-phone =A0the DT > SIP-network we may not get the rendering intended by DT and this is > fine. [JRE] I think I understand. With REQ-09 the renderer understands the receiv= ed indication and chooses to render in a different way, whereas with REQ-10= the renderer doesn't understand the indication precisely but understands e= nough to render in a way that approximates to what the specifier intended. = So in your example above, the renderer might understand a concept like "ext= ernal ring tone", but not "German external ring tone", and rendering its ow= n external ring tone would be good enough, given that it can't render Germa= n external ring tone. Am I correct? If so, perhaps we should consider rewording, e.g., as follows: "REQ-10: The mechanism will allow a renderer to select a tone that approxim= ates to that intended by the specifier if the renderer is unable to provide= the precise tone indicated." > > 13. Section 2: > > " =A0 REQ-19: The mechanism will allow storage of the actual encoding > > =A0 locally rather than fetching it." > > Should it say "rendering" rather than "encoding"? > [LL] What would you say to "rendering representation" ? But I am OK > with "rendering", too. [JRE] OK >=20 > > > > 14. Section 3.2.1: > > "As > > =A0 call-waiting information may be subject to the callee's privacy > > =A0 concerns, the exposure of this information SHALL be done only if > > =A0 explicitly required by the user." > > We should not use RFC 2119 language in use case descriptions. > [LL] OK. I will put shall in lower case letters. Otherrwise=20 > it is ok, I think? [JRE] Yes, that would be sufficient. John= From laura.liess.dt@googlemail.com Tue Feb 15 08:08:14 2011 Return-Path: X-Original-To: salud@core3.amsl.com Delivered-To: salud@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A547B3A6CAF for ; Tue, 15 Feb 2011 08:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.997 X-Spam-Level: X-Spam-Status: No, score=-3.997 tagged_above=-999 required=5 tests=[AWL=0.980, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5yIAFLcu7m0 for ; Tue, 15 Feb 2011 08:08:13 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id E33223A6AA6 for ; Tue, 15 Feb 2011 08:08:12 -0800 (PST) Received: by yie19 with SMTP id 19so158350yie.31 for ; Tue, 15 Feb 2011 08:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=A18Ru5oaBOMI8nbjrVws1CpUorvaWVONufuWFO7Z2Fc=; b=nb+YiXFtb13HrfdEtTQ6MZhWl70esRmh0IWwopvKcPdtyaXcHIx6tUnSPoT9+c4bET QR+p8iR5hEfOPRGfX58bDy72ghGMulb2RQBGTqsrwYeXdsQ+tew0h6II1uD1YveL9w90 bWA/HhTCfTqQ7f3UJT80xHQgPxsKtWRe+VBFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ju5uZ1CedmxgLb/R/l0Rc2jDz/NjLKJmmZj9r5jyBYH3L0f0NwkRw9/5fsMgGU6bGa SL7U8kHsIwIQPrBYUaL/BDIY0zAcz/7YUAuqsaoykre12r7FCrq+2+JKwQWQtE21pC+R /oeFMrqcM9WdLPWFUQlH4R73m+QzkLxRAv6oQ= MIME-Version: 1.0 Received: by 10.151.154.3 with SMTP id g3mr6170920ybo.239.1297786118397; Tue, 15 Feb 2011 08:08:38 -0800 (PST) Received: by 10.150.195.21 with HTTP; Tue, 15 Feb 2011 08:08:38 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Feb 2011 17:08:38 +0100 Message-ID: From: Laura Liess To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "salud@ietf.org" Subject: Re: [salud] Fwd: Everybody get to work! -- LAST CALL on requirements X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 16:08:14 -0000 John, Thank you. The rewording for REQ-10 is great. Please see below the text proposal for 9. Section 2 >> > 9. Section 2: >> > " REQ-9: The renderer may be customized in ways that limit >> the set of >> > signals that it can render, or it may be provided with a set of >> > signals that have uncommon semantics. (The canonical >> example is a UA >> > for the hearing-impaired.) (By REQ-7, the renderer has no way of >> > transmitting this fact to the specifier.)" >> > Not sure what the requirement is here. Should it be >> something along the lines of: >> >"The mechanism must accommodate renderers that are limited >> in the set of signals they can render..." >> [LL] What do you think about "The mechanism must be able to >> accommodate renderers that are customized with a limited or uncomon >> set of signals they can render." Just "Limited" is to me like the >> renderer would be an old, very simple PSTN-phone. I wouldn't call >> hearing-impaired phones customized for video and text to be "limited >> in the set of signals they can render", rather "uncommon". >> in the set of signals they can render", rather "uncommon". > [JRE] I would be happy with your modified text, although we might wish to= cite hearing-impaired phones as an example of devices that have uncommon r= enderings - otherwise it might no be clear what is meant. [LL] So, the whole text could be: " The mechanism must be able to accommodate renderers that are customized with a limited or uncomon set of signals they can render. The canonical example is a UA for the hearing-impaired, customized with an uncomon set of signals, video or text instead of audio. (By REQ-7, the renderer has no way of transmitting this fact to the specifier.)" Kind regards Laura 2011/2/15 Elwell, John : > Laura, > > I have stripped out those items where we are in agreement. See below for = other comments: > >> > 3. Section 1.1: >> > "The downside is that if the recipient does not understand the URN >> > =A0 then it will only be able to render a default ringback or >> ring tone. >> > =A0 To provide the general awareness about the Alert-Info URNs this >> > =A0 document provides IANA template for registering the URNs >> and defines >> > =A0 several typical identifiers." >> > I think these should be two separate paragraphs. Moreover, >> I think the second sentence needs some attention - the >> template is not "to provide general awareness". Perhaps the >> following would be better: >> > "This document provides a template for registering alert >> URNs and defines several typical values." >> > Or alternatively: >> > "This document creates a new URN namespace and registry for >> alert indications and registers some initial values." >> > >> [LL] Yes. I am fine with both proposals, with a slight preference for >> the second. > [JRE] Yes, my slight preference is for the second. > >> > 6. Section 2: >> > "REQ-4: Indications include subsets which have distinctly different >> > =A0 semantics, that is, they form disjoint "value spaces". >> For example, >> > =A0 some indications should describe the semantics of the signaling >> > =A0 situation whereas others should describe the audio >> characteristics of >> > =A0 the signal. =A0This implies that there is no single set of >> categories >> > =A0 that can be used as independent coordinates of the value-space of >> > =A0 indications." >> > I am not sure I understand this at all. Are we trying to >> say that indications within a subset have different semantics >> (in which case, what is the purpose of a subset?) or >> indications within a subset have similar semantics but >> indications within different subsets have different semantics? >> [LL] The second is the case. The text is more an explanation of REQ-3 >> than an independent requirement, but in fact im makes things more >> confusing. I think the best thing would be to discard it. > [JRE] Deletion would be fine. > >> > 7. Section 2: >> > " - add further value spaces of indications whose semantics are not >> > =A0 related to existing indications, and thus, whose categories differ >> > =A0 from and do not interact with existing categories." >> > How does this differ from the earlier bullet: >> > - add further categories that are orthogonal to existing >> categories"? >> =A0[LL] There is practically no difference between the two bullets. I >> think the first bullelt is more clear, so let's discard the last >> bullet. Is this OK? > [JRE] Yes. > >> > 9. Section 2: >> > " =A0REQ-9: The renderer may be customized in ways that limit >> the set of >> > =A0 signals that it can render, or it may be provided with a set of >> > =A0 signals that have uncommon semantics. =A0(The canonical >> example is a UA >> > =A0 for the hearing-impaired.) =A0(By REQ-7, the renderer has no way o= f >> > =A0 transmitting this fact to the specifier.)" >> > Not sure what the requirement is here. Should it be >> something along the lines of: >> >"The mechanism must accommodate renderers that are limited >> in the set of signals they can render..." >> [LL] What do you think about "The mechanism must be able to >> accommodate renderers that are customized with a limited or uncomon >> set of signals they can render." =A0Just "Limited" is to me like the >> renderer would be an old, very simple PSTN-phone. I wouldn't call >> hearing-impaired phones customized =A0for video and text =A0to be "limit= ed >> in the set of signals they can render", rather "uncommon". > [JRE] I would be happy with your modified text, although we might wish to= cite hearing-impaired phones as an example of devices that have uncommon r= enderings - otherwise it might no be clear what is meant. > >> >> > >> > 10. Section 2: >> > " =A0 REQ-10: If the specifier and the renderer have designs that are >> > =A0 properly coordinated, the indications must be able to >> reliably carry >> > =A0 all extensions that are supported in the coordinated >> designs. =A0In any >> > =A0 other situation, it is not required from the renderer to >> perform the >> > =A0 best possible rendering." >> > Rather than "the indications must be able to reliably carry >> all extensions that are supported in the coordinated >> designs", how about "the mechanism must be capable of >> supporting all indications needed"? >> [LL]Fine. >> >> > Concerning the last sentence, isn't this covered by REQ-09? >> [ LL] I wouldn't say so. Req-9 means that the mechanism should work >> well also, e.g., for end devices of hearing impaired, customized to >> render text or video instead of ringing tones. The last sentence in >> Req-10 means that, e.g., if we attach an AT&T =A0SIP-phone =A0the DT >> SIP-network we may not get the rendering intended by DT and this is >> fine. > [JRE] I think I understand. With REQ-09 the renderer understands the rece= ived indication and chooses to render in a different way, whereas with REQ-= 10 the renderer doesn't understand the indication precisely but understands= enough to render in a way that approximates to what the specifier intended= . So in your example above, the renderer might understand a concept like "e= xternal ring tone", but not "German external ring tone", and rendering its = own external ring tone would be good enough, given that it can't render Ger= man external ring tone. Am I correct? > > If so, perhaps we should consider rewording, e.g., as follows: > "REQ-10: The mechanism will allow a renderer to select a tone that approx= imates to that intended by the specifier if the renderer is unable to provi= de the precise tone indicated." > >> > 13. Section 2: >> > " =A0 REQ-19: The mechanism will allow storage of the actual encoding >> > =A0 locally rather than fetching it." >> > Should it say "rendering" rather than "encoding"? >> [LL] What would you say to "rendering representation" ? But I am OK >> with "rendering", too. > [JRE] OK > >> >> > >> > 14. Section 3.2.1: >> > "As >> > =A0 call-waiting information may be subject to the callee's privacy >> > =A0 concerns, the exposure of this information SHALL be done only if >> > =A0 explicitly required by the user." >> > We should not use RFC 2119 language in use case descriptions. >> [LL] OK. I will put shall in lower case letters. Otherrwise >> it is ok, I think? > [JRE] Yes, that would be sufficient. > > John From john.elwell@siemens-enterprise.com Tue Feb 15 09:10:11 2011 Return-Path: X-Original-To: salud@core3.amsl.com Delivered-To: salud@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05063A6D33 for ; Tue, 15 Feb 2011 09:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.621 X-Spam-Level: X-Spam-Status: No, score=-103.621 tagged_above=-999 required=5 tests=[AWL=0.978, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyW40T4QtEdf for ; Tue, 15 Feb 2011 09:10:09 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 47A543A6CD9 for ; Tue, 15 Feb 2011 09:10:08 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3414086; Tue, 15 Feb 2011 18:10:33 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id DD66C23F0278; Tue, 15 Feb 2011 18:10:33 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 15 Feb 2011 18:10:33 +0100 From: "Elwell, John" To: Laura Liess Date: Tue, 15 Feb 2011 18:10:32 +0100 Thread-Topic: [salud] Fwd: Everybody get to work! -- LAST CALL on requirements Thread-Index: AcvNKpyzjK80xsFLSUmfOhWHtUdOJwACJ0sA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "salud@ietf.org" Subject: Re: [salud] Fwd: Everybody get to work! -- LAST CALL on requirements X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 17:10:11 -0000 OK John=20 > -----Original Message----- > From: Laura Liess [mailto:laura.liess.dt@googlemail.com]=20 > Sent: 15 February 2011 16:09 > To: Elwell, John > Cc: salud@ietf.org > Subject: Re: [salud] Fwd: Everybody get to work! -- LAST CALL=20 > on requirements >=20 > John, >=20 > Thank you. The rewording for REQ-10 is great. > Please see below the text proposal for 9. Section 2 >=20 > >> > 9. Section 2: > >> > " REQ-9: The renderer may be customized in ways that limit > >> the set of > >> > signals that it can render, or it may be provided with a set of > >> > signals that have uncommon semantics. (The canonical > >> example is a UA > >> > for the hearing-impaired.) (By REQ-7, the renderer=20 > has no way of > >> > transmitting this fact to the specifier.)" > >> > Not sure what the requirement is here. Should it be > >> something along the lines of: > >> >"The mechanism must accommodate renderers that are limited > >> in the set of signals they can render..." > >> [LL] What do you think about "The mechanism must be able to > >> accommodate renderers that are customized with a limited or uncomon > >> set of signals they can render." Just "Limited" is to me like the > >> renderer would be an old, very simple PSTN-phone. I wouldn't call > >> hearing-impaired phones customized for video and text to=20 > be "limited > >> in the set of signals they can render", rather "uncommon". > >> in the set of signals they can render", rather "uncommon". > > [JRE] I would be happy with your modified text, although we=20 > might wish to cite hearing-impaired phones as an example of=20 > devices that have uncommon renderings - otherwise it might no=20 > be clear what is meant. > [LL] So, the whole text could be: " The mechanism must be able to > accommodate renderers that are customized with a limited or uncomon > set of signals they can render. The canonical example is a UA for the > hearing-impaired, customized with an uncomon set of signals, video or > text instead of audio. (By REQ-7, the renderer has no way of > transmitting this fact to the specifier.)" >=20 >=20 > Kind regards > Laura >=20 >=20 > 2011/2/15 Elwell, John : > > Laura, > > > > I have stripped out those items where we are in agreement.=20 > See below for other comments: > > > >> > 3. Section 1.1: > >> > "The downside is that if the recipient does not=20 > understand the URN > >> > =A0 then it will only be able to render a default ringback or > >> ring tone. > >> > =A0 To provide the general awareness about the Alert-Info URNs this > >> > =A0 document provides IANA template for registering the URNs > >> and defines > >> > =A0 several typical identifiers." > >> > I think these should be two separate paragraphs. Moreover, > >> I think the second sentence needs some attention - the > >> template is not "to provide general awareness". Perhaps the > >> following would be better: > >> > "This document provides a template for registering alert > >> URNs and defines several typical values." > >> > Or alternatively: > >> > "This document creates a new URN namespace and registry for > >> alert indications and registers some initial values." > >> > > >> [LL] Yes. I am fine with both proposals, with a slight=20 > preference for > >> the second. > > [JRE] Yes, my slight preference is for the second. > > > >> > 6. Section 2: > >> > "REQ-4: Indications include subsets which have=20 > distinctly different > >> > =A0 semantics, that is, they form disjoint "value spaces". > >> For example, > >> > =A0 some indications should describe the semantics of the signaling > >> > =A0 situation whereas others should describe the audio > >> characteristics of > >> > =A0 the signal. =A0This implies that there is no single set of > >> categories > >> > =A0 that can be used as independent coordinates of the=20 > value-space of > >> > =A0 indications." > >> > I am not sure I understand this at all. Are we trying to > >> say that indications within a subset have different semantics > >> (in which case, what is the purpose of a subset?) or > >> indications within a subset have similar semantics but > >> indications within different subsets have different semantics? > >> [LL] The second is the case. The text is more an=20 > explanation of REQ-3 > >> than an independent requirement, but in fact im makes things more > >> confusing. I think the best thing would be to discard it. > > [JRE] Deletion would be fine. > > > >> > 7. Section 2: > >> > " - add further value spaces of indications whose=20 > semantics are not > >> > =A0 related to existing indications, and thus, whose=20 > categories differ > >> > =A0 from and do not interact with existing categories." > >> > How does this differ from the earlier bullet: > >> > - add further categories that are orthogonal to existing > >> categories"? > >> =A0[LL] There is practically no difference between the two bullets. I > >> think the first bullelt is more clear, so let's discard the last > >> bullet. Is this OK? > > [JRE] Yes. > > > >> > 9. Section 2: > >> > " =A0REQ-9: The renderer may be customized in ways that limit > >> the set of > >> > =A0 signals that it can render, or it may be provided with a set of > >> > =A0 signals that have uncommon semantics. =A0(The canonical > >> example is a UA > >> > =A0 for the hearing-impaired.) =A0(By REQ-7, the renderer=20 > has no way of > >> > =A0 transmitting this fact to the specifier.)" > >> > Not sure what the requirement is here. Should it be > >> something along the lines of: > >> >"The mechanism must accommodate renderers that are limited > >> in the set of signals they can render..." > >> [LL] What do you think about "The mechanism must be able to > >> accommodate renderers that are customized with a limited or uncomon > >> set of signals they can render." =A0Just "Limited" is to me like the > >> renderer would be an old, very simple PSTN-phone. I wouldn't call > >> hearing-impaired phones customized =A0for video and text =A0to=20 > be "limited > >> in the set of signals they can render", rather "uncommon". > > [JRE] I would be happy with your modified text, although we=20 > might wish to cite hearing-impaired phones as an example of=20 > devices that have uncommon renderings - otherwise it might no=20 > be clear what is meant. > > > >> > >> > > >> > 10. Section 2: > >> > " =A0 REQ-10: If the specifier and the renderer have=20 > designs that are > >> > =A0 properly coordinated, the indications must be able to > >> reliably carry > >> > =A0 all extensions that are supported in the coordinated > >> designs. =A0In any > >> > =A0 other situation, it is not required from the renderer to > >> perform the > >> > =A0 best possible rendering." > >> > Rather than "the indications must be able to reliably carry > >> all extensions that are supported in the coordinated > >> designs", how about "the mechanism must be capable of > >> supporting all indications needed"? > >> [LL]Fine. > >> > >> > Concerning the last sentence, isn't this covered by REQ-09? > >> [ LL] I wouldn't say so. Req-9 means that the mechanism should work > >> well also, e.g., for end devices of hearing impaired, customized to > >> render text or video instead of ringing tones. The last sentence in > >> Req-10 means that, e.g., if we attach an AT&T =A0SIP-phone =A0the DT > >> SIP-network we may not get the rendering intended by DT and this is > >> fine. > > [JRE] I think I understand. With REQ-09 the renderer=20 > understands the received indication and chooses to render in=20 > a different way, whereas with REQ-10 the renderer doesn't=20 > understand the indication precisely but understands enough to=20 > render in a way that approximates to what the specifier=20 > intended. So in your example above, the renderer might=20 > understand a concept like "external ring tone", but not=20 > "German external ring tone", and rendering its own external=20 > ring tone would be good enough, given that it can't render=20 > German external ring tone. Am I correct? > > > > If so, perhaps we should consider rewording, e.g., as follows: > > "REQ-10: The mechanism will allow a renderer to select a=20 > tone that approximates to that intended by the specifier if=20 > the renderer is unable to provide the precise tone indicated." > > > >> > 13. Section 2: > >> > " =A0 REQ-19: The mechanism will allow storage of the=20 > actual encoding > >> > =A0 locally rather than fetching it." > >> > Should it say "rendering" rather than "encoding"? > >> [LL] What would you say to "rendering representation" ? But I am OK > >> with "rendering", too. > > [JRE] OK > > > >> > >> > > >> > 14. Section 3.2.1: > >> > "As > >> > =A0 call-waiting information may be subject to the callee's privacy > >> > =A0 concerns, the exposure of this information SHALL be=20 > done only if > >> > =A0 explicitly required by the user." > >> > We should not use RFC 2119 language in use case descriptions. > >> [LL] OK. I will put shall in lower case letters. Otherrwise > >> it is ok, I think? > > [JRE] Yes, that would be sufficient. > > > > John > = From dworley@avaya.com Tue Feb 22 13:00:13 2011 Return-Path: X-Original-To: salud@core3.amsl.com Delivered-To: salud@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28CB83A697C for ; Tue, 22 Feb 2011 13:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, J_BACKHAIR_22=1, J_BACKHAIR_26=1, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaVdePq9Gb0a for ; Tue, 22 Feb 2011 13:00:10 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 477BE3A697A for ; Tue, 22 Feb 2011 13:00:08 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGKyY03GmAcF/2dsb2JhbACmIHOkRQKZJoVeBIUNils X-IronPort-AV: E=Sophos;i="4.62,207,1297054800"; d="scan'208";a="60293067" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 22 Feb 2011 16:00:52 -0500 X-IronPort-AV: E=Sophos;i="4.62,207,1297054800"; d="scan'208";a="585333906" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Feb 2011 16:00:45 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.187]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 22 Feb 2011 16:00:45 -0500 From: "Worley, Dale R (Dale)" To: "salud@ietf.org" Date: Tue, 22 Feb 2011 15:59:23 -0500 Thread-Topic: Notes on the requirements Thread-Index: AQHL0tOS2Lddlerc/0OZcAohvoRWnQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [salud] Notes on the requirements X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 21:00:13 -0000 [as individual] Notes on draft-ietf-salud-alert-info-urns-00 Suggested wording changes are mostly indicated by >...<. -- Wording changes that have some technical content - In regard to section 3.1.1 that discusses the "normal" ring tone: The current text considers the "normal" specification as a no-op or placeholder. But we will also need to be able to positively specify normal ringing. I suggest that we add a requirement that there be an explicit "placeholder" URN, and consider "normal" to be an explicit alternative relative to "external", "internal", etc. Or perhaps remove "normal" as such, since the other subsections of 3.1 attempt to enumerate all known possibilities. (E.g., "external" vs. "internal" -- together these cover all possibilities!) - In section 3.2.2 (indicating that a call has been forwarded), we expect that the caller will hear one ringback (the call-forwarding beep) followed by another (ringback from the destination that was reached). Indicating this seems to be straightforward if the second ringback is carried in a 181 Call Is Being Forwarded response. But it would be more complex using only 180 response(s). I suppose that the natural way to do this is to either: Send two 180s in quick succession, the first carrying "forward" and the second coming from the destination. Send one 180, whose Alert-Info is a combination of the "forward" Alert-Info and the Alert-Info from the destination. Send a 181, possibly with "Alert-Info: urn:forward", followed by the 180 from the destination. We probably want to discuss this at some point. The second possibility suggests a requirement that we probably need for other reasons as well: A way to combine two Alert-Info's to create a combined indication, with any contradictions between the two resolved in favor of the first one. This isn't difficult to do within the framework: For example, if we use multiple URNs: "Alert-Info: urn:A, urn:B" combined with "Alert-Info: urn:C, urn:D" gives "Alert-Info: urn:A, urn:B, urn:C, urn:D" If we use single URNs: "Alert-Info: urn:A:B" combined with "Alert-Info: urn:C:D" gives "Alert-Info: urn:A:B:C:D" But we should specify that it must be possible. One way to express this is: REQ-XX: The mechanism must provide a simple way to combine two indications to produce an indication that requests a combination of the intentions of the two indications, where any contradictions or conflicts between the two indications are resolved in favor of the intention of the first indication. -- Wording changes that I don't think are technically interesting - In section 1.1 para 1, "URI" is used repeatedly. This is correct in general, but what we are complaining about is that Alert-Info is always used with *URLs* (which are a subset of URIs). So it would clarify the situation to phrase it this way: tone to the user agent (UA). In [RFC3261] this is done by including a URI >[delete "reference"]< in the Alert-Info header field, that >specifies< the tone. The URI >[delete "reference"]< is most commonly the HTTP >URL< to the audio file. On the receipt of the Alert-Info header the user agent may fetch the referenced ringback or ring tone and play it to the user. Similarly, toward the bottom of section 1.1: Some advantages of a URN rather than a >URL of< a downloadable resource: - Section 1.2 changes how Alert-Info is used compared to RFC 3261. We should clarify exactly how we are changing its usage. This specification changes the usage of the SIP Alert-Info header defined in the [RFC3261] >by additionally allowing its use in all provisional responses to INVITE (except the 100 response)<. Backward compatibility issues are not expected, >as< devices that do not >expect an Alert-Info header in a particular response should ignore it<. >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. Backward compatibility issues are not expected, as devices that do not understand an Alert-Info URN should ignore it, and devices should not malfunction upon receiving multiple Alert-Info alert-params (which was syntactically permitted before, but rarely used).< - In section 1.3, there is an "indication" or "identifier" (a URN in an Alert-Info header)=20 But that text is only accurate in the "one URN" solution. To allow the multiple URN solution, this should be changed to an "indication" or "identifier" (one or more URNs in an Alert-Info heade= r)=20 - In section 2, REQ-7, add a clause to include that the ringback indications are rendered by the caller independently of the ring tone indications sent by the caller: REQ-7: An indication is transmitted from a specifier to a renderer, which must base its rendering decision only on the indication. In particular, there is no multi-message negotiation process>,< carrying of context from one indication to the next, >or carrying of context from the caller's indication of the ring tone to the rendering decision by the caller of the ringback tone<. This makes sure that the caller doesn't interpret the ringback indication as an "answer" that is somehow based on the ring indication. - We may not need the last sentence of REQ-10, as what it describes is covered by REQ-11. The text would become: REQ-10: If the specifier and the renderer have designs that are properly coordinated, the indications must be able to reliably carry all extensions that are supported in the coordinated designs. >[delete sentence]< - There is a word missing in REQ-11: REQ-11: In any situation, the renderer must be able to perform close to the best possible rendering that it could do even >if< the specifier had specific knowledge of the renderer's capabilities. - I think we want to adjust the wording of REQ-12: REQ-12: The mechanism will allow interoperability for >indicating< services, such as call waiting, forward, transfer-recall, auto-callback, hold-recall. - Adjust wording of REQ-18 and REQ-19: REQ-18: The mechanism must ensure that >if< a UA >receives< Alert-Info URNs or portions of an Alert-Info URN it does not understand, it can ignore them. REQ-19: The mechanism will allow storage of the actual encoding >of the rendering< locally rather than fetching it. - We should add for completeness the possibility of service-provider specific indications: 3.4 Service-provider-specific ringback tone indications for the public telephone network In the PSTN, different tones can be used by different service providers, even with one country. End users are accustomed to hear the provider's specific ringback tone and would like to have this feature for SIP. This is technically interesting only in that it may require subdivision of the country categories, or allowing an extension category for indicating service providers. Dale From pkyzivat@cisco.com Tue Feb 22 13:21:49 2011 Return-Path: X-Original-To: salud@core3.amsl.com Delivered-To: salud@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCE93A6916 for ; Tue, 22 Feb 2011 13:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.585 X-Spam-Level: X-Spam-Status: No, score=-110.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fVSo8xgtUkC for ; Tue, 22 Feb 2011 13:21:47 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BCCC63A67F1 for ; Tue, 22 Feb 2011 13:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=835; q=dns/txt; s=iport; t=1298409753; x=1299619353; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ifmhfQtn0h2DadQNbUz89edEUn0EqL37EK5fhq3CnD8=; b=IvR2XPlyiaVWAQC5So66Do8vfi4PDgnrBguNbiwJ/GlD1tJ9ZEGkFn+n 3ndMDcNpm/1UFXT/vvP7HUeaDSs/bnmrZ55Q1Ve2Uq9J8rP8GmATMSZJH NJSlFXWZBmmZh06708YX55od0hZDaGipBcuGQc/VNAl2wVfig1XLM7ED3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIHAD+4Y01AZnwN/2dsb2JhbACYFo4Nc6IYm1eFXgSFDYcGgzs X-IronPort-AV: E=Sophos;i="4.62,208,1297036800"; d="scan'208";a="218747397" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Feb 2011 21:22:32 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1MLMWto014945 for ; Tue, 22 Feb 2011 21:22:32 GMT Message-ID: <4D642918.5010103@cisco.com> Date: Tue, 22 Feb 2011 16:22:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: salud@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [salud] Notes on the requirements X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 21:21:49 -0000 Dale, I generally agree. One comment: On 2/22/2011 3:59 PM, Worley, Dale R (Dale) wrote: > - We should add for completeness the possibility of service-provider > specific indications: > > 3.4 Service-provider-specific ringback tone indications for the > public telephone network > > In the PSTN, different tones can be used by different service > providers, even with one country. End users are accustomed to hear > the provider's specific ringback tone and would like to have this > feature for SIP. > > This is technically interesting only in that it may require > subdivision of the country categories, or allowing an extension > category for indicating service providers. Do you see a reason why the SP can't use the "private" mechanism for this purpose? Thanks, Paul From laura.liess.dt@googlemail.com Fri Feb 25 08:03:18 2011 Return-Path: X-Original-To: salud@core3.amsl.com Delivered-To: salud@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D5E3A6A0E for ; Fri, 25 Feb 2011 08:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpqTlNCKhpJ2 for ; Fri, 25 Feb 2011 08:03:16 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 95EA53A6A13 for ; Fri, 25 Feb 2011 08:03:16 -0800 (PST) Received: by vws6 with SMTP id 6so1663247vws.31 for ; Fri, 25 Feb 2011 08:04:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Jgrsn9OoE4rxQGbL7RUyip13QUo59yPPEetp1CTlfek=; b=gzTC2N+k3FLebW1k++0mC1euQw+f4zHn10p0aEDylKlvbxvCFgW6k4q1xLsoJCc46D J35zSnH2klZaTD3nmVc58xd6TaSO5y0LCzXESoW0QAjnTd1E5uXvm7dw/6GQ0rWPFP5s +lnFTItkAtR7JZxDtWDBpCskXPpqXnPtRLQc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WFBjHppUD6+ZZl+KSA8VysUU5AgHAVrI8eHdW2Gwi9Oz1KMesfaOhOfkQ1+428ttOJ +gxLHxkpEdBkllFLmuIYOzs2lq7UcqnY0EFtIOWUZ9Kl9KexiZIxqEyW1GgjhAoU2YXT IIJWVd2uay4oWeIUARHTC2ytxWh7O7MYXG8cE= MIME-Version: 1.0 Received: by 10.52.91.108 with SMTP id cd12mr4216631vdb.277.1298649845159; Fri, 25 Feb 2011 08:04:05 -0800 (PST) Received: by 10.52.166.232 with HTTP; Fri, 25 Feb 2011 08:04:05 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Feb 2011 17:04:05 +0100 Message-ID: From: Laura Liess To: "Worley, Dale R (Dale)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "salud@ietf.org" Subject: Re: [salud] Notes on the requirements X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 16:03:18 -0000 Dale, Thank you for the comments- Please see inline. 2011/2/22 Worley, Dale R (Dale) : > [as individual] > > Notes on draft-ietf-salud-alert-info-urns-00 > Suggested wording changes are mostly indicated by >...<. > > -- Wording changes that have some technical content > > - In regard to section 3.1.1 that discusses the "normal" ring tone: > The current text considers the "normal" specification as a no-op or > placeholder. =A0But we will also need to be able to positively specify > normal ringing. =A0I suggest that we add a requirement that there be an > explicit "placeholder" URN, and consider "normal" to be an explicit > alternative relative to "external", "internal", etc. =A0Or perhaps > remove "normal" as such, since the other subsections of 3.1 attempt to > enumerate all known possibilities. =A0(E.g., "external" vs. "internal" > -- together these cover all possibilities!) > [LL] We could use "default" instead of "normal". Would this meet your needs= ? > - In section 3.2.2 (indicating that a call has been forwarded), we > expect that the caller will hear one ringback (the call-forwarding > beep) followed by another (ringback from the destination that was > reached). =A0Indicating this seems to be straightforward if the second > ringback is carried in a 181 Call Is Being Forwarded response. =A0But it > would be more complex using only 180 response(s). =A0I suppose that the > natural way to do this is to either: > > Send two 180s in quick succession, the first carrying "forward" and > the second coming from the destination. > > Send one 180, whose Alert-Info is a combination of the "forward" > Alert-Info and the Alert-Info from the destination. > > Send a 181, possibly with "Alert-Info: urn:forward", followed by the > 180 from the destination. > > We probably want to discuss this at some point. > > The second possibility suggests a requirement that we probably need > for other reasons as well: =A0A way to combine two Alert-Info's to > create a combined indication, with any contradictions between the two > resolved in favor of the first one. =A0This isn't difficult to do within > the framework: > > For example, if we use multiple URNs: > > =A0 =A0 =A0 =A0"Alert-Info: urn:A, urn:B" combined with "Alert-Info: urn:= C, urn:D" > =A0 =A0 =A0 =A0gives "Alert-Info: urn:A, urn:B, urn:C, urn:D" > > If we use single URNs: > > =A0 =A0 =A0 =A0"Alert-Info: urn:A:B" combined with "Alert-Info: urn:C:D" > =A0 =A0 =A0 =A0gives "Alert-Info: urn:A:B:C:D" > > But we should specify that it must be possible. =A0One way to express > this is: > > =A0 REQ-XX: The mechanism must provide a simple way to combine two > =A0 indications to produce an indication that requests a combination of > =A0 the intentions of the two indications, where any contradictions or > =A0 conflicts between the two indications are resolved in favor of the > =A0 intention of the first indication. [LL] Agree. I will add this requirement as REQ-20. > -- Wording changes that I don't think are technically interesting > > - In section 1.1 para 1, "URI" is used repeatedly. =A0This is correct in > general, but what we are complaining about is that Alert-Info is > always used with *URLs* (which are a subset of URIs). =A0So it would > clarify the situation to phrase it this way: > > =A0 tone to the user agent (UA). =A0In [RFC3261] this is done by > =A0 including a URI >[delete "reference"]< in the Alert-Info header > =A0 field, that >specifies< the tone. =A0The URI >[delete "reference"]< i= s > =A0 most commonly the HTTP >URL< to the audio file. =A0On the receipt of > =A0 the Alert-Info header the user agent may fetch the referenced > =A0 ringback or ring tone and play it to the user. > > Similarly, toward the bottom of section 1.1: > > =A0 Some advantages of a URN rather than a >URL of< a downloadable > =A0 resource: [LL] OK > > - Section 1.2 changes how Alert-Info is used compared to RFC 3261. > We should clarify exactly how we are changing its usage. > > =A0 This specification changes the usage of the SIP Alert-Info header > =A0 defined in the [RFC3261] >by additionally allowing its use in all > =A0 provisional responses to INVITE (except the 100 response)<. > =A0 Backward compatibility issues are not expected, >as< devices that do > =A0 not >expect an Alert-Info header in a particular response should > =A0 ignore it<. > > =A0 >In practice, this specification extends Alert-Info in that it will > =A0 cause the use of a new class of URIs and the use of multiple URIs. > =A0 Backward compatibility issues are not expected, as devices that do > =A0 not understand an Alert-Info URN should ignore it, and devices > =A0 should not malfunction upon receiving multiple Alert-Info > =A0 alert-params (which was syntactically permitted before, but rarely > =A0 used).< [LL] OK > > - In section 1.3, there is > > =A0 an "indication" or "identifier" (a URN in an Alert-Info header) > > But that text is only accurate in the "one URN" solution. =A0To allow > the multiple URN solution, this should be changed to > > =A0 an "indication" or "identifier" (one or more URNs in an Alert-Info he= ader) [LL] OK > > - In section 2, REQ-7, add a clause to include that the ringback > indications are rendered by the caller independently of the ring tone > indications sent by the caller: > > =A0 REQ-7: An indication is transmitted from a specifier to a renderer, > =A0 which must base its rendering decision only on the indication. =A0In > =A0 particular, there is no multi-message negotiation process>,< > =A0 carrying of context from one indication to the next, >or carrying > =A0 of context from the caller's indication of the ring tone to the > =A0 rendering decision by the caller of the ringback tone<. > > This makes sure that the caller doesn't interpret the ringback > indication as an "answer" that is somehow based on the ring > indication. [LL] John already sent a comment and proposed a new text for REQ-7: "The mechanism must provide only an indication capability, not a negotiation capability. The mechanism must not require an indication to depend on the context provided by a previous indication." If we add "in any direction" at the end of the sentence, would this cover your comment? > > - We may not need the last sentence of REQ-10, as what it describes is > covered by REQ-11. =A0The text would become: > > =A0 REQ-10: If the specifier and the renderer have designs that are > =A0 properly coordinated, the indications must be able to reliably carry > =A0 all extensions that are supported in the coordinated designs. > =A0 >[delete sentence]< > > - There is a word missing in REQ-11: > > =A0 REQ-11: In any situation, the renderer must be able to perform close > =A0 to the best possible rendering that it could do even >if< the specifi= er > =A0 had specific knowledge of the renderer's capabilities. [LL] For both REQ-10 and REQ-11, I agree with you. John also had comments for these requirements and had text proposals. Looking at your and John's comments, I would propose following text: "REQ-10: The mechanism will allow an indication to reliably carry all extensions if the specifier and the renderer have designs that are properly coordinated. REQ-11: The mechanism will allow a renderer to select a tone that approximates to that intended by the specifier if the renderer is unable to provide the precise tone indicated." What do you think? > > - I think we want to adjust the wording of REQ-12: > > =A0 REQ-12: The mechanism will allow interoperability for >indicating< > =A0 services, such as call waiting, forward, transfer-recall, > =A0 auto-callback, hold-recall. [LL] OK. > > - Adjust wording of REQ-18 and REQ-19: > > =A0 REQ-18: The mechanism must ensure that >if< a UA >receives< Alert-Inf= o > =A0 URNs or portions of an Alert-Info URN it does not understand, it can > =A0 ignore them. [LL] OK. > > =A0 REQ-19: The mechanism will allow storage of the actual encoding >of > =A0 the rendering< locally rather than fetching it. [LL] OK. > > - We should add for completeness the possibility of service-provider > =A0specific indications: > > =A0 3.4 =A0Service-provider-specific ringback tone indications for the > =A0 public telephone network > > =A0 In the PSTN, different tones can be used by different service > =A0 providers, even with one country. =A0End users are accustomed to hear > =A0 the provider's specific ringback tone and would like to have this > =A0 feature for SIP. > > This is technically interesting only in that it may require > subdivision of the country categories, or allowing an extension > category for indicating service providers. [LL] We can add this, but, in my opinion, we would not be consistent with the first sentence in Section 3 and with a decision taken in the past. During a discussion at the salud meeting in connection with US-specific ring tones brougt up by Adam, we agreed include in Section 3 and define the identifiers only for use cases where the Alert-Info URN mechanism is needed today. We also agreed to require the mechanism to be flexible, so people can add identifiers when new use cases arise. Currently, I don't know of any SIP service provider requiring a specific identifier for ringback tone. If, in the future at&t needs such an identifier, it can either register a new identifier with IANA or just use . My personal opinion is to not add this use case. But I am open if people would like to have it in this specification. Thanks a lot Laura > > Dale > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > From dworley@avaya.com Fri Feb 25 13:54:20 2011 Return-Path: X-Original-To: salud@core3.amsl.com Delivered-To: salud@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296CB3A6A5F for ; Fri, 25 Feb 2011 13:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsA8aKxmf8kf for ; Fri, 25 Feb 2011 13:54:18 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E282A3A6A72 for ; Fri, 25 Feb 2011 13:54:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHu0Z02HCzI1/2dsb2JhbACmPHSkAAKZGIVgBIUQimU X-IronPort-AV: E=Sophos;i="4.62,227,1297054800"; d="scan'208";a="266756064" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 Feb 2011 16:55:06 -0500 X-IronPort-AV: E=Sophos;i="4.62,227,1297054800"; d="scan'208";a="605779861" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 Feb 2011 16:55:06 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.187]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Fri, 25 Feb 2011 16:55:06 -0500 From: "Worley, Dale R (Dale)" To: "salud@ietf.org" Date: Fri, 25 Feb 2011 16:53:55 -0500 Thread-Topic: Another requirement Thread-Index: AQHL1TapxziwzNKJD0yk2AHxTKwagA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [salud] Another requirement X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 21:54:20 -0000 [as individual] I'm behind on reading e-mail, so this may have been mentioned. But I think= that due to draft-ietf-bliss-shared-appearances, we have a requirement tha= t the specific URN urn:alert:service:normal must function as a placeholder, that is, it has no particular semantics. Dale From dworley@avaya.com Fri Feb 25 14:14:51 2011 Return-Path: X-Original-To: salud@core3.amsl.com Delivered-To: salud@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1AF3A6A5C for ; Fri, 25 Feb 2011 14:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6Iko4omzRVA for ; Fri, 25 Feb 2011 14:14:50 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id ECF793A6A5B for ; Fri, 25 Feb 2011 14:14:49 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADS5Z03GmAcF/2dsb2JhbACmPHSjcQKZF4VgBIUQimU X-IronPort-AV: E=Sophos;i="4.62,228,1297054800"; d="scan'208";a="266759154" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 Feb 2011 17:15:43 -0500 X-IronPort-AV: E=Sophos;i="4.62,228,1297054800"; d="scan'208";a="586802819" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Feb 2011 17:15:43 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.187]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Fri, 25 Feb 2011 17:15:42 -0500 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , "salud@ietf.org" Date: Fri, 25 Feb 2011 17:15:42 -0500 Thread-Topic: [salud] Notes on the requirements Thread-Index: AcvS1q1LjnEnGOagRY+b3sJ4INkr0wCYWYlx Message-ID: References: , <4D642918.5010103@cisco.com> In-Reply-To: <4D642918.5010103@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [salud] Notes on the requirements X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 22:14:51 -0000 [as individual] ________________________________________ From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Paul Kyz= ivat [pkyzivat@cisco.com] > In the PSTN, different tones can be used by different service > providers, even with one country. End users are accustomed to hear > the provider's specific ringback tone and would like to have this > feature for SIP. Do you see a reason why the SP can't use the "private" mechanism for this purpose? _______________________________________________ At the level of requirements, this is just another form of extensibility. In regard to the mechanism, I hope that this case can be accommodated by th= e same mechanism as all other extensibility. In detail, though, it touches on an architectural issue: The "private" mec= hanism in the draft does not have the properties I want. In particular, th= e current mechanism makes a ring indication into essentially a series of na= me-value pairs. E.g. one can say: urn:alert:source:internal, urn:alert:priority:high or urn:alert:source:internal, urn:alert:priority:high, urn:country.hu Adding "private" gives: urn:alert:source:internal, urn:alert:priority:high, urn:country:hu, urn:pri= vate:carrier The only way to know how to interpret that is to know what the URNs mean, a= nd we can't assume that the recipient understands all the URNs. The problem is that we want to specify "the tones used by carrier A within = Hungary, understood as a subdivision of the tones used within Hungary". An= d we want to do it in a way that can be understood as a subdivision of Hung= ary even if one does not know the name of the subdivision. So I want to se= e something like . If one understands , then one will understand that URN as a subdivision of Hungary, even= if one does not know what it is. If we were to specify that specialization by "urn:country:hu, urn:carrier-A= ", there is no way to know that is intended as a subdivisio= n of Hungary unless one knows what "carrier-A" means. Dale From pkyzivat@cisco.com Fri Feb 25 15:19:02 2011 Return-Path: X-Original-To: salud@core3.amsl.com Delivered-To: salud@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70A853A6A77 for ; Fri, 25 Feb 2011 15:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.579 X-Spam-Level: X-Spam-Status: No, score=-110.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxraJ9rbcvmC for ; Fri, 25 Feb 2011 15:19:01 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 134353A6A75 for ; Fri, 25 Feb 2011 15:19:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2661; q=dns/txt; s=iport; t=1298675994; x=1299885594; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=BXT6cWOsnftFfoKvohlix9h9oezHmvb9+9z9Q+B1zEs=; b=VRYSH6ceFDFZaUApDRvYp1ARyEakZjcxG/AhFIMjfN5d4qHej9TCgUle M0dI2ZFsJASuU/LBnV0fU6ksP9hpD1IP2VuefuXfAmVCSTbY8I7DMH02S XGKnpt0HbeBbgwuZxBLm4HzeHzK1YjTGJlpi9R5Bwghzndu09CcDINVQS s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL3HZ01AZnwM/2dsb2JhbACmP3ShJJtNhWAEhRCHDYM+ X-IronPort-AV: E=Sophos;i="4.62,228,1297036800"; d="scan'208";a="220160821" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Feb 2011 23:19:54 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1PNJsli006300; Fri, 25 Feb 2011 23:19:54 GMT Message-ID: <4D683919.4050207@cisco.com> Date: Fri, 25 Feb 2011 18:19:53 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: , <4D642918.5010103@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "salud@ietf.org" Subject: Re: [salud] Notes on the requirements X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 23:19:02 -0000 Dale, Comments at end... On 2/25/2011 5:15 PM, Worley, Dale R (Dale) wrote: > [as individual] > > ________________________________________ > From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > >> In the PSTN, different tones can be used by different service >> providers, even with one country. End users are accustomed to hear >> the provider's specific ringback tone and would like to have this >> feature for SIP. > > Do you see a reason why the SP can't use the "private" mechanism for > this purpose? > _______________________________________________ > > At the level of requirements, this is just another form of extensibility. > > In regard to the mechanism, I hope that this case can be accommodated by the same mechanism as all other extensibility. > > In detail, though, it touches on an architectural issue: The "private" mechanism in the draft does not have the properties I want. In particular, the current mechanism makes a ring indication into essentially a series of name-value pairs. E.g. one can say: > > urn:alert:source:internal, urn:alert:priority:high > > or > > urn:alert:source:internal, urn:alert:priority:high, urn:country.hu > > Adding "private" gives: > > urn:alert:source:internal, urn:alert:priority:high, urn:country:hu, urn:private:carrier > > The only way to know how to interpret that is to know what the URNs mean, and we can't assume that the recipient understands all the URNs. > > The problem is that we want to specify "the tones used by carrier A within Hungary, understood as a subdivision of the tones used within Hungary". And we want to do it in a way that can be understood as a subdivision of Hungary even if one does not know the name of the subdivision. So I want to see something like. If one understands, then one will understand that URN as a subdivision of Hungary, even if one does not know what it is. > > If we were to specify that specialization by "urn:country:hu, urn:carrier-A", there is no way to know that is intended as a subdivision of Hungary unless one knows what "carrier-A" means. If that particular semantic is what you want, then I will assert that we must treat some agence of Hungary as the "naming authority" responsible for subdivisions of urn:country:hu. If they (whoever "they" are) want to carve out a subspace for carriers, then they can do so. In practice I doubt that will work out well. Its much like the problem ENUM has in delegating through the enum numbering space. Thanks, Paul