From hannes.tschofenig@gmx.net Wed May 1 02:19:15 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EA921F8E45 for ; Wed, 1 May 2013 02:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDrnC9CPu5XA for ; Wed, 1 May 2013 02:19:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id D152821F8E06 for ; Wed, 1 May 2013 02:19:10 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MEHTC-1UmsTN1rMO-00FTOt for ; Wed, 01 May 2013 11:19:09 +0200 Received: (qmail invoked by alias); 01 May 2013 09:19:09 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp017) with SMTP; 01 May 2013 11:19:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+LEkYpELOL1mTRYPt3Ct8rk0+miczLbsylTvl7Se olOsVf18u+CrY9 Message-ID: <5180DE05.5090703@gmx.net> Date: Wed, 01 May 2013 12:19:01 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [Ecrit] Additional Data: XML Schema and Instance Documents X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 09:19:15 -0000 Hi all, I went through the document and validated various XML schemas. I also added examples. You can find them here: https://github.com/hannestschofenig/tschofenig-ids/tree/master/additional-data/xml One problem I ran into was with regard to the XML-based VCard structure (called xCard). RFC 6351, see http://tools.ietf.org/html/rfc6351, defines a Relax NG schema rather than an XML schema and I was not able to use it directly within the additional data XML schemas. I don't know whether someone of you had ever tried to mix XML schemas and Relax NG schemas but it does not seem to be completely easy. Help appreciated. Here is what I did: I excluded the xCard structures from the XML schema but due to the extensibility mechanism with the any namespace="##other" construct you can add pretty much everything anyway. Here is an example of the resulting XML schema: https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-data/xml/emergencyCall.SubInfo.xsd Here is an instance document: https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-data/xml/emergencyCall.SubInfo-example.xml If you are not happy with the result there are three other ways to solve the problem: 1) Create an XML schema of the XCard structure 2) Remove all XML schemas from the additional data document 3) Find out whether there is a way to import Relax NG schemas into an XML schema Ciao Hannes From hannes.tschofenig@gmx.net Wed May 1 02:22:35 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF67E21F8B38 for ; Wed, 1 May 2013 02:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wiCXJMXMnsU for ; Wed, 1 May 2013 02:22:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 85BD621F899E for ; Wed, 1 May 2013 02:22:30 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MGDg9-1UmbfW2o6B-00FCso for ; Wed, 01 May 2013 11:22:29 +0200 Received: (qmail invoked by alias); 01 May 2013 09:22:29 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp001) with SMTP; 01 May 2013 11:22:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/HNBJYeCDHOMO0iQVtLP87d0qotgDLPdCmZ3c4sU nRNR9/BApuboQQ Message-ID: <5180DECF.4080405@gmx.net> Date: Wed, 01 May 2013 12:22:23 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Gunnar Hellstrom References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> <517F623C.9050909@omnitor.se> In-Reply-To: <517F623C.9050909@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 09:22:35 -0000 Hi Gunnar, thanks for the feedback. Based on your input I added the following text to the terminology section of the draft. " This document also uses terminology from [RFC5012]. We use the term service provider to refer to an Application Service Provider (ASP) or to Voice Service Provider (VSP), which is a specific type of ASP. With the term "Access Network Provider" we refer to the Internet Access Provider (IAP) and the Internet Service Provider (ISP) without further distinguishing these two entities, since the difference between the two is not relevant for this document. Note that the roles of ASP and access network provider may be provided by a single company. " Do you think that this change will help to improve readability of the document? Ciao Hannes On 04/30/2013 09:18 AM, Gunnar Hellstrom wrote: > > ------------------------------------------------------------------------ > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > +46708204288 > On 2013-04-29 23:22, Hannes Tschofenig wrote: >> Hi James, >> >> I am trying to incorporate some of your review comments and I have a couple of questions. >> >> On Mar 18, 2013, at 5:41 AM, Winterbottom, James wrote: >> >>> Hi Authors, >>> >>> I have reviewed this document and have the following comments, some of which I have already posted to the list and have not had a reply to. >>> >>> Comments: >>> ================= >>> The term “Service Provider” is used extensively throughout this document but the term doesn’t seem to be obviously defined in the document, nor is there is a reference to an external definition. To add to this, Service Provider is a defined type in section 14.1.2, but used more generally throughout the rest of the document. This needs a clarification. >> I searched for an appropriate definition in IETF RFCs and it turns out that others have defined this term either. >> >> Do you have a recommendation what we should use? Do you think it is really necessary to describe it? > I had a similar problem in another SDO recently. I used "service > provider" or "communication service provider" for an organization > handling calls and subscribers. > The conclusion there was to change it to "Application Service Provider" > with the following definition: > > *"Application Service Provider (ASP): *organization or entity that > provides application-layer services, which may include voice, video and > text communication" > > The reason for confusion was apparently that some thought of the network > access service provider while others thought about the call control > service provider when using the term "service provider". > > It stands out clear in section14.1.2. that it is a problem. > The table with service provider types contains "service provider" as one > of the types. > > At least this recursive use of the term needs to be broken. > > I briefly checked RFC 6881 and RFC 4504 to check how they handled > "service provider" and found that you are in good company. The term is > just used without definition and seems to mean an organization working > on the SIP or other call control level and manages subscribers. > > I suggest that this definition is used: > > *"Application Service Provider (ASP): *organization or entity that > provides application-layer services, which may include real-time > communication" > > And then check through the occurrences and replace the ones that have > the narrow meaning of "Application Service Provider". > > > /Gunnar > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From br@brianrosen.net Wed May 1 07:26:59 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216C821F986F for ; Wed, 1 May 2013 07:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxS1Sn9RatMI for ; Wed, 1 May 2013 07:26:55 -0700 (PDT) Received: from mm2.idig.net (raphotoclub.ca [70.33.247.99]) by ietfa.amsl.com (Postfix) with ESMTP id D01DF21F964C for ; Wed, 1 May 2013 07:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=V3UETAFF7xXSkUOAztEind6X6dM7u1EGBKWrfRTxMDw=; b=ONMyKsV9j0gspjDdRuXIKBqTw0b69oS1PGWWV89n6Da1vRcRsslLKoQQ1tqTtFZh0NqIfkpJPjad97sk4+qTh2WQbSMysBP13aIXi7ZiG1VDZ8aPCqG6//gmosnHnwlruRUawahgZzretBzFcED+FdFVQROYCe0rGGaNv5couO8=; Received: from neustargw.va.neustar.com ([209.173.53.233]:28548 helo=[10.33.192.26]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UXXzi-0002DG-1g; Wed, 01 May 2013 10:26:54 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <5180DE05.5090703@gmx.net> Date: Wed, 1 May 2013 10:26:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6761E4D2-5CFA-4280-9EAA-E1CFF97E66E2@brianrosen.net> References: <5180DE05.5090703@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: XML Schema and Instance Documents X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 14:26:59 -0000 There is a 4) Make Relax NG schemas for additional-data. But, actually, unless 3) is realistic, I vote for 1). It's not hard, = and NENA would really appreciate a referenceable XML schema for XCard. Brian On May 1, 2013, at 5:19 AM, Hannes Tschofenig = wrote: > Hi all, >=20 > I went through the document and validated various XML schemas. I also = added examples. >=20 > You can find them here: > = https://github.com/hannestschofenig/tschofenig-ids/tree/master/additional-= data/xml >=20 > One problem I ran into was with regard to the XML-based VCard = structure (called xCard). RFC 6351, see = http://tools.ietf.org/html/rfc6351, defines a Relax NG schema rather = than an XML schema and I was not able to use it directly within the = additional data XML schemas. >=20 > I don't know whether someone of you had ever tried to mix XML schemas = and Relax NG schemas but it does not seem to be completely easy. >=20 > Help appreciated. >=20 > Here is what I did: I excluded the xCard structures from the XML = schema but due to the extensibility mechanism with the any = namespace=3D"##other" construct you can add pretty much everything = anyway. >=20 > Here is an example of the resulting XML schema: > = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/emergencyCall.SubInfo.xsd >=20 > Here is an instance document: > = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/emergencyCall.SubInfo-example.xml >=20 > If you are not happy with the result there are three other ways to = solve the problem: >=20 > 1) Create an XML schema of the XCard structure > 2) Remove all XML schemas from the additional data document > 3) Find out whether there is a way to import Relax NG schemas into an = XML schema >=20 > Ciao > Hannes > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From martin.thomson@gmail.com Wed May 1 07:49:11 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A4421F9C92 for ; Wed, 1 May 2013 07:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEJFheOa71Hw for ; Wed, 1 May 2013 07:49:11 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CECFD21F9997 for ; Wed, 1 May 2013 07:49:10 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id c11so1402799wgh.34 for ; Wed, 01 May 2013 07:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=cHcL74htieIfHpgGjAQjOqr974nwRNd3xIVMLLjDuC4=; b=YdlWW2iNFBbttY0yJiG2iy8/H+HGE4tE8xSYMgMWq2RurIprSSUPLfQM3AT4iq2jDL +gGHNuTj9ROIOr9+dGGuIPLsKrZPgaIpFTwRETbRIRall+19Snez8bVU/mb/GKl4kcPl fg2O5sHmIeYLhwir1FiRdKI/vMFXnKc85y5suL3en/wvBL+t+pNI3jfwTqMjMW206DOy 7ASEZCmwh7OeDOIijLeRMs/80P949Jx6uWPefCjz3On5mkhTCQ1khyEiLO1MFWSS2CYh WZlnx4ZusQ46dCv6TW2QZKz+4FYjg17mZ6ukRPqKK2tWSIMj/flcqiilBqv3DS1NBnrk B6jg== MIME-Version: 1.0 X-Received: by 10.194.63.239 with SMTP id j15mr3216363wjs.30.1367419745480; Wed, 01 May 2013 07:49:05 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Wed, 1 May 2013 07:49:05 -0700 (PDT) In-Reply-To: <6761E4D2-5CFA-4280-9EAA-E1CFF97E66E2@brianrosen.net> References: <5180DE05.5090703@gmx.net> <6761E4D2-5CFA-4280-9EAA-E1CFF97E66E2@brianrosen.net> Date: Wed, 1 May 2013 07:49:05 -0700 Message-ID: From: Martin Thomson To: Brian Rosen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Additional Data: XML Schema and Instance Documents X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 14:49:11 -0000 http://relaxng.org/#conversion On 1 May 2013 07:26, Brian Rosen wrote: > There is a 4) Make Relax NG schemas for additional-data. > > But, actually, unless 3) is realistic, I vote for 1). It's not hard, and= NENA would really appreciate a referenceable XML schema for XCard. > > Brian > > On May 1, 2013, at 5:19 AM, Hannes Tschofenig = wrote: > >> Hi all, >> >> I went through the document and validated various XML schemas. I also ad= ded examples. >> >> You can find them here: >> https://github.com/hannestschofenig/tschofenig-ids/tree/master/additiona= l-data/xml >> >> One problem I ran into was with regard to the XML-based VCard structure = (called xCard). RFC 6351, see http://tools.ietf.org/html/rfc6351, defines a= Relax NG schema rather than an XML schema and I was not able to use it dir= ectly within the additional data XML schemas. >> >> I don't know whether someone of you had ever tried to mix XML schemas an= d Relax NG schemas but it does not seem to be completely easy. >> >> Help appreciated. >> >> Here is what I did: I excluded the xCard structures from the XML schema = but due to the extensibility mechanism with the any namespace=3D"##other" c= onstruct you can add pretty much everything anyway. >> >> Here is an example of the resulting XML schema: >> https://github.com/hannestschofenig/tschofenig-ids/blob/master/additiona= l-data/xml/emergencyCall.SubInfo.xsd >> >> Here is an instance document: >> https://github.com/hannestschofenig/tschofenig-ids/blob/master/additiona= l-data/xml/emergencyCall.SubInfo-example.xml >> >> If you are not happy with the result there are three other ways to solve= the problem: >> >> 1) Create an XML schema of the XCard structure >> 2) Remove all XML schemas from the additional data document >> 3) Find out whether there is a way to import Relax NG schemas into an XM= L schema >> >> Ciao >> Hannes >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From gunnar.hellstrom@omnitor.se Wed May 1 10:26:37 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F9921F9399 for ; Wed, 1 May 2013 10:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OswG9IbAS+1w for ; Wed, 1 May 2013 10:26:32 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 8E0B121F99B5 for ; Wed, 1 May 2013 10:26:31 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP; Wed, 1 May 2013 19:26:24 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id D3DA13A161; Wed, 1 May 2013 19:26:23 +0200 (CEST) Message-ID: <51815044.9050309@omnitor.se> Date: Wed, 01 May 2013 19:26:28 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Hannes Tschofenig References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> <517F623C.9050909@omnitor.se> <5180DECF.4080405@gmx.net> In-Reply-To: <5180DECF.4080405@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 17:26:37 -0000 On 2013-05-01 11:22, Hannes Tschofenig wrote: > Hi Gunnar, > > thanks for the feedback. > > Based on your input I added the following text to the terminology > section of the draft. > > " > This document also uses terminology from [RFC5012]. We use the term > service provider to refer to an Application Service Provider (ASP) or > to Voice Service Provider (VSP), which is a specific type of ASP. > With the term "Access Network Provider" we refer to the Internet > Access Provider (IAP) and the Internet Service Provider (ISP) without > further distinguishing these two entities, since the difference > between the two is not relevant for this document. Note that the > roles of ASP and access network provider may be provided by a single > company. > " > > Do you think that this change will help to improve readability of the > document? Yes. You need also do something to the table in section 14.1.2. There you say that the whole table is about service providers, and then one of the kinds of service providers is called just "service provider". That is unclear logic. /Gunnar > > Ciao > Hannes > > > > On 04/30/2013 09:18 AM, Gunnar Hellstrom wrote: >> >> ------------------------------------------------------------------------ >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46708204288 >> On 2013-04-29 23:22, Hannes Tschofenig wrote: >>> Hi James, >>> >>> I am trying to incorporate some of your review comments and I have a >>> couple of questions. >>> >>> On Mar 18, 2013, at 5:41 AM, Winterbottom, James wrote: >>> >>>> Hi Authors, >>>> >>>> I have reviewed this document and have the following comments, some >>>> of which I have already posted to the list and have not had a reply >>>> to. >>>> >>>> Comments: >>>> ================= >>>> The term “Service Provider” is used extensively throughout this >>>> document but the term doesn’t seem to be obviously defined in the >>>> document, nor is there is a reference to an external definition. To >>>> add to this, Service Provider is a defined type in section 14.1.2, >>>> but used more generally throughout the rest of the document. This >>>> needs a clarification. >>> I searched for an appropriate definition in IETF RFCs and it turns >>> out that others have defined this term either. >>> >>> Do you have a recommendation what we should use? Do you think it is >>> really necessary to describe it? >> I had a similar problem in another SDO recently. I used "service >> provider" or "communication service provider" for an organization >> handling calls and subscribers. >> The conclusion there was to change it to "Application Service Provider" >> with the following definition: >> >> *"Application Service Provider (ASP): *organization or entity that >> provides application-layer services, which may include voice, video and >> text communication" >> >> The reason for confusion was apparently that some thought of the network >> access service provider while others thought about the call control >> service provider when using the term "service provider". >> >> It stands out clear in section14.1.2. that it is a problem. >> The table with service provider types contains "service provider" as one >> of the types. >> >> At least this recursive use of the term needs to be broken. >> >> I briefly checked RFC 6881 and RFC 4504 to check how they handled >> "service provider" and found that you are in good company. The term is >> just used without definition and seems to mean an organization working >> on the SIP or other call control level and manages subscribers. >> >> I suggest that this definition is used: >> >> *"Application Service Provider (ASP): *organization or entity that >> provides application-layer services, which may include real-time >> communication" >> >> And then check through the occurrences and replace the ones that have >> the narrow meaning of "Application Service Provider". >> >> >> /Gunnar >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > From gunnar.hellstrom@omnitor.se Wed May 1 11:53:08 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C0621F9907 for ; Wed, 1 May 2013 11:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJBIdbF6snHS for ; Wed, 1 May 2013 11:52:56 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 69C1121F98E8 for ; Wed, 1 May 2013 11:52:45 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Wed, 1 May 2013 20:52:36 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 837753A16A for ; Wed, 1 May 2013 20:52:36 +0200 (CEST) Message-ID: <51816479.409@omnitor.se> Date: Wed, 01 May 2013 20:52:41 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ecrit@ietf.org References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> In-Reply-To: <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> Content-Type: multipart/alternative; boundary="------------090603010301010203030401" Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 18:53:08 -0000 This is a multi-part message in MIME format. --------------090603010301010203030401 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hannes, Looking at the contents of the list of different service providers, I wonder if there should be more types defined. It depends of course on what usage this information is expected to have. It seems that the various language translation and expert advice services that can be involved in emergency calls could be of interest to include here. Current list ------------------------------------------------------------ 14.1.2 . Additional Call Data Service Provider Type Registry +------------------------------+------------------------------------+ | Name | Description | +------------------------------+------------------------------------+ |Access Infrastructure Provider| Access network service provider | |Service Provider | Calling or Origination telecom SP | |Service Provider Subcontractor| A contractor to another kind of SP | |Telematics Provider | A sensor based SP, especially | | | vehicle based | |Relay Provider | A interpretation SP, for example, | | | video relay for sign language | | | interpretors | |Other | Any other type of service provider | +------------------------------+------------------------------------+ ------------------------------------- Proposal with more types +------------------------------+------------------------------------+ | Name | Description | +------------------------------+------------------------------------+ |Access Infrastructure Provider| Access network service provider | |Application Service Provider | Calling or Origination telecom SP | |Service Provider Subcontractor| A contractor to another kind of SP | |Telematics Provider | A sensor based SP, especially | | | vehicle based | |Language translation Provider | A spoken language translation SP | |Expert advice provider | An SP giving expert advice | |Emergency Modality translation| An emergency call specific | | | modality translation service | | | e.g. for sign language | |Relay Provider | A interpretation SP, for example, | | | video relay for sign language | | | interpreting | |Other | Any other type of service provider | +------------------------------+------------------------------------+ ----------------------------------- I inserted the "Emergency Modality translation", because there is a tendency in USA to not use the term "relay service" for cases when the service is arranged specifically for handling modality conversion in emergency call and when the PSAP can participate in all media communication but need this extra service to mediate the communication. The expert advice provider is usually added in a bridge operation after the original incoming call. But I can imagine that the additional-data is of interest also for such situations For deciding on this, I think it would be good to have an idea of the use of this information. Will it be used for a review if a call was properly handled? If so, maybe even more detail is needs, such as what kind of relay service was invoked, so that it is possible to check if it was of a suitable kind. Or are such details provided in some other parameter? I think this should be checked with EENA and NENA to verify if more needs in this area have been developed lately. /Gunnar --------------090603010301010203030401 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hannes,

Looking at the contents of the list of different service providers, I wonder if there should be more types defined.
It depends of course on what usage this information is expected to have.

It seems that the various language translation and expert advice services that can be involved in emergency calls could be of interest to include here.

Current list
------------------------------------------------------------
14.1.2.  Additional Call Data Service Provider Type Registry


   +------------------------------+------------------------------------+
   | Name                         | Description                        |
   +------------------------------+------------------------------------+
   |Access Infrastructure Provider| Access network service provider    |
   |Service Provider              | Calling or Origination telecom SP  |
   |Service Provider Subcontractor| A contractor to another kind of SP |
   |Telematics Provider           | A sensor based SP, especially      |
   |                              | vehicle based                      |
   |Relay Provider                | A interpretation SP, for example,  |
   |                              | video relay for sign language      |
   |                              | interpretors                       |
   |Other                         | Any other type of service provider |
   +------------------------------+------------------------------------+
-------------------------------------
Proposal with more types
   +------------------------------+------------------------------------+
   | Name                         | Description                        |
   +------------------------------+------------------------------------+
   |Access Infrastructure Provider| Access network service provider    |
   |Application Service Provider  | Calling or Origination telecom SP  |
   |Service Provider Subcontractor| A contractor to another kind of SP |
   |Telematics Provider           | A sensor based SP, especially      |
   |                              | vehicle based                      |
   |Language translation Provider | A spoken language translation SP   |
   |Expert advice provider        | An SP giving expert advice         |
   |Emergency Modality translation| An emergency call specific         |
   |                              | modality translation service       |
   |                              | e.g. for sign language             |
   |Relay Provider                | A interpretation SP, for example,  |
   |                              | video relay for sign language      |
   |                              | interpreting                        |
   |Other                         | Any other type of service provider |
   +------------------------------+------------------------------------+
-----------------------------------
I inserted the "Emergency Modality translation", because there is a tendency in USA to not use the term "relay service" for cases when the service is arranged specifically for
handling modality conversion in emergency call and when the PSAP can participate in all media communication but need this extra service to mediate the communication.

The expert advice provider is usually added in a bridge operation after the original incoming call. But I can imagine that the additional-data is of interest also for such situations

For deciding on this, I think it would be good to have an idea of the use of this information.

Will it be used for a review if a call was properly handled?  If so, maybe even more detail is needs, such as what kind of relay service was invoked, so that it is possible to check if it was of a suitable kind.

Or are such details provided in some other parameter?

I think this should be checked with EENA and NENA to verify if more needs in this area have been developed lately.

/Gunnar







--------------090603010301010203030401-- From mserra@ravemobilesafety.com Wed May 1 12:37:14 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABD421F9A2A for ; Wed, 1 May 2013 12:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldyK1QcWKNQM for ; Wed, 1 May 2013 12:37:09 -0700 (PDT) Received: from server505.appriver.com (server505f.appriver.com [98.129.35.10]) by ietfa.amsl.com (Postfix) with ESMTP id 912D221F99CC for ; Wed, 1 May 2013 12:37:09 -0700 (PDT) X-Note-AR-ScanTimeLocal: 5/1/2013 2:37:08 PM X-Policy: GLOBAL - ravemobilesafety.com X-Policy: GLOBAL - ravemobilesafety.com X-Policy: GLOBAL - ravemobilesafety.com X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @ravemobilesafety.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: smtp.exg5.exghost.com X-Note-Return-Path: mserra@ravemobilesafety.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G319 G320 G321 G322 G326 G327 G338 G434 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 376819687; Wed, 01 May 2013 14:37:08 -0500 Received: from MBX05.exg5.exghost.com ([169.254.1.177]) by HT09-e5.exg5.exghost.com ([98.129.23.242]) with mapi; Wed, 1 May 2013 14:37:06 -0500 From: Matt Serra To: Gunnar Hellstrom , Hannes Tschofenig Date: Wed, 1 May 2013 14:36:33 -0500 Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-07 Thread-Index: Ac5GnSoTrY97AFDvTF2z5guA13AdMQABN8wQ Message-ID: <6B92B1E73D1E7B468E5C97CAE569CBA1215369EB0B@MBX05.exg5.exghost.com> References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> <517F623C.9050909@omnitor.se> <5180DECF.4080405@gmx.net> <51815044.9050309@omnitor.se> In-Reply-To: <51815044.9050309@omnitor.se> 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: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 19:37:14 -0000 One thought: It may be worthwhile to distinguish "Internet Access Provider= " over Internet Service Provider, no? For the purposes of this RFC, the "access" provider we are referring to is = expected to be the provider of the location associated with the call's PIDF= -LO. This is the entity that knows the location of the device placing the call. = Typically this will be the "last mile" provider, as opposed to a different= internet service provider in the middle of the call path (who probably doe= sn't even know the data is associated with an emergency call). If we can use language that helps make this distinction, I think that would= be a good thing. Matthew A. Serra, ENP Sr. Director, Product Management=20 Rave Mobile Safety | Smart911 Mobile:=A0=A0201.245.1557 mserra@ravemobilesafety.com =20 -----Original Message----- From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se]=20 Sent: Wednesday, May 01, 2013 1:26 PM To: Hannes Tschofenig Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 On 2013-05-01 11:22, Hannes Tschofenig wrote: > Hi Gunnar, > > thanks for the feedback. > > Based on your input I added the following text to the terminology=20 > section of the draft. > > " > This document also uses terminology from [RFC5012]. We use the term > service provider to refer to an Application Service Provider (ASP) or > to Voice Service Provider (VSP), which is a specific type of ASP. > With the term "Access Network Provider" we refer to the Internet > Access Provider (IAP) and the Internet Service Provider (ISP) without > further distinguishing these two entities, since the difference > between the two is not relevant for this document. Note that the > roles of ASP and access network provider may be provided by a single > company. > " > > Do you think that this change will help to improve readability of the=20 > document? Yes. You need also do something to the table in section 14.1.2. There you say that the whole table is about service providers, and then one= of the kinds of service providers is called just "service provider".=20 That is unclear logic. /Gunnar > > Ciao > Hannes > > > > On 04/30/2013 09:18 AM, Gunnar Hellstrom wrote: >> >> ------------------------------------------------------------------------ >> Gunnar Hellstr=F6m >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46708204288 >> On 2013-04-29 23:22, Hannes Tschofenig wrote: >>> Hi James, >>> >>> I am trying to incorporate some of your review comments and I have a=20 >>> couple of questions. >>> >>> On Mar 18, 2013, at 5:41 AM, Winterbottom, James wrote: >>> >>>> Hi Authors, >>>> >>>> I have reviewed this document and have the following comments, some=20 >>>> of which I have already posted to the list and have not had a reply=20 >>>> to. >>>> >>>> Comments: >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> The term "Service Provider" is used extensively throughout this=20 >>>> document but the term doesn't seem to be obviously defined in the=20 >>>> document, nor is there is a reference to an external definition. To=20 >>>> add to this, Service Provider is a defined type in section 14.1.2,=20 >>>> but used more generally throughout the rest of the document. This=20 >>>> needs a clarification. >>> I searched for an appropriate definition in IETF RFCs and it turns=20 >>> out that others have defined this term either. >>> >>> Do you have a recommendation what we should use? Do you think it is=20 >>> really necessary to describe it? >> I had a similar problem in another SDO recently. I used "service >> provider" or "communication service provider" for an organization >> handling calls and subscribers. >> The conclusion there was to change it to "Application Service Provider" >> with the following definition: >> >> *"Application Service Provider (ASP): *organization or entity that >> provides application-layer services, which may include voice, video and >> text communication" >> >> The reason for confusion was apparently that some thought of the network >> access service provider while others thought about the call control >> service provider when using the term "service provider". >> >> It stands out clear in section14.1.2. that it is a problem. >> The table with service provider types contains "service provider" as one >> of the types. >> >> At least this recursive use of the term needs to be broken. >> >> I briefly checked RFC 6881 and RFC 4504 to check how they handled >> "service provider" and found that you are in good company. The term is >> just used without definition and seems to mean an organization working >> on the SIP or other call control level and manages subscribers. >> >> I suggest that this definition is used: >> >> *"Application Service Provider (ASP): *organization or entity that >> provides application-layer services, which may include real-time >> communication" >> >> And then check through the occurrences and replace the ones that have >> the narrow meaning of "Application Service Provider". >> >> >> /Gunnar >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > From hannes.tschofenig@gmx.net Wed May 1 14:22:36 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB5421F9B09 for ; Wed, 1 May 2013 14:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJcRA-sLO1tO for ; Wed, 1 May 2013 14:22:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id F3C4A21F9AE2 for ; Wed, 1 May 2013 14:22:28 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0ME0kj-1UoTjX0EjX-00HOi2 for ; Wed, 01 May 2013 23:22:28 +0200 Received: (qmail invoked by alias); 01 May 2013 21:22:27 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp027) with SMTP; 01 May 2013 23:22:27 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/vRXoizvbvGbGJ37cAaDkjqaM4xq9111nn2Nq88J xdiM+Q87ANBh/I Message-ID: <5181878C.8090301@gmx.net> Date: Thu, 02 May 2013 00:22:20 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Brian Rosen References: <5180DE05.5090703@gmx.net> <6761E4D2-5CFA-4280-9EAA-E1CFF97E66E2@brianrosen.net> In-Reply-To: <6761E4D2-5CFA-4280-9EAA-E1CFF97E66E2@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: XML Schema and Instance Documents X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 21:22:36 -0000 Hi Brian, I converted the vCard Relax NG schema into an XML schema (using trang and changed it slightly) and incorporated it into one of the XML schemas from the draft. Here is the vCard XML schema: https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-data/xml/vcard.xsd Here is the updated subscriber info schema: https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-data/xml/emergencyCall.SubInfo.xsd Here is the one instance document: https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-data/xml/emergencyCall.SubInfo-example.xml I hope I got it right. So, I could put the vCard XML schema into the draft. Ciao Hannes On 05/01/2013 05:26 PM, Brian Rosen wrote: > There is a 4) Make Relax NG schemas for additional-data. > > But, actually, unless 3) is realistic, I vote for 1). It's not hard, and NENA would really appreciate a referenceable XML schema for XCard. > > Brian > > On May 1, 2013, at 5:19 AM, Hannes Tschofenig wrote: > >> Hi all, >> >> I went through the document and validated various XML schemas. I also added examples. >> >> You can find them here: >> https://github.com/hannestschofenig/tschofenig-ids/tree/master/additional-data/xml >> >> One problem I ran into was with regard to the XML-based VCard structure (called xCard). RFC 6351, see http://tools.ietf.org/html/rfc6351, defines a Relax NG schema rather than an XML schema and I was not able to use it directly within the additional data XML schemas. >> >> I don't know whether someone of you had ever tried to mix XML schemas and Relax NG schemas but it does not seem to be completely easy. >> >> Help appreciated. >> >> Here is what I did: I excluded the xCard structures from the XML schema but due to the extensibility mechanism with the any namespace="##other" construct you can add pretty much everything anyway. >> >> Here is an example of the resulting XML schema: >> https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-data/xml/emergencyCall.SubInfo.xsd >> >> Here is an instance document: >> https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-data/xml/emergencyCall.SubInfo-example.xml >> >> If you are not happy with the result there are three other ways to solve the problem: >> >> 1) Create an XML schema of the XCard structure >> 2) Remove all XML schemas from the additional data document >> 3) Find out whether there is a way to import Relax NG schemas into an XML schema >> >> Ciao >> Hannes >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > From br@brianrosen.net Wed May 1 14:29:21 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E080421F8648 for ; Wed, 1 May 2013 14:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0DZuptlLhQu for ; Wed, 1 May 2013 14:29:17 -0700 (PDT) Received: from mm2.idig.net (raphotoclub.ca [70.33.247.99]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0F821F9B20 for ; Wed, 1 May 2013 14:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=he1r6baRs5fba/GZU7sJgNtiy7aFikFFOvWKC2e/u6Q=; b=dh9gkcC/Hln9yvaQPdg2/SGhmdKDOY3cRoPdr/mH/MxxVY5vlT8yJaGexk/e2ao4fA6kE2GQo5pSpkGatTYsSdD5YcGNzuoEHIAJCPUrZ5q4aq1GqtRude7YYNx2JvMtQGo2qtraomI/w36M8IPXl+2uXn2oGl/DuhYo2PvI82Y=; Received: from neustargw.va.neustar.com ([209.173.53.233]:42931 helo=[10.33.192.26]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UXeaR-0003GO-T8; Wed, 01 May 2013 17:29:15 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <5181878C.8090301@gmx.net> Date: Wed, 1 May 2013 17:29:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7FB7BBC1-8F3D-4BEC-BE71-9515A2D15B2C@brianrosen.net> References: <5180DE05.5090703@gmx.net> <6761E4D2-5CFA-4280-9EAA-E1CFF97E66E2@brianrosen.net> <5181878C.8090301@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: XML Schema and Instance Documents X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 21:29:22 -0000 I'll look it over, but I think you should put it in the draft. Brian On May 1, 2013, at 5:22 PM, Hannes Tschofenig = wrote: > Hi Brian, >=20 > I converted the vCard Relax NG schema into an XML schema (using trang = and changed it slightly) and incorporated it into one of the XML schemas = from the draft. >=20 > Here is the vCard XML schema: > = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/vcard.xsd >=20 > Here is the updated subscriber info schema: > = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/emergencyCall.SubInfo.xsd >=20 > Here is the one instance document: > = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/emergencyCall.SubInfo-example.xml >=20 > I hope I got it right. >=20 > So, I could put the vCard XML schema into the draft. >=20 > Ciao > Hannes >=20 >=20 > On 05/01/2013 05:26 PM, Brian Rosen wrote: >> There is a 4) Make Relax NG schemas for additional-data. >>=20 >> But, actually, unless 3) is realistic, I vote for 1). It's not hard, = and NENA would really appreciate a referenceable XML schema for XCard. >>=20 >> Brian >>=20 >> On May 1, 2013, at 5:19 AM, Hannes Tschofenig = wrote: >>=20 >>> Hi all, >>>=20 >>> I went through the document and validated various XML schemas. I = also added examples. >>>=20 >>> You can find them here: >>> = https://github.com/hannestschofenig/tschofenig-ids/tree/master/additional-= data/xml >>>=20 >>> One problem I ran into was with regard to the XML-based VCard = structure (called xCard). RFC 6351, see = http://tools.ietf.org/html/rfc6351, defines a Relax NG schema rather = than an XML schema and I was not able to use it directly within the = additional data XML schemas. >>>=20 >>> I don't know whether someone of you had ever tried to mix XML = schemas and Relax NG schemas but it does not seem to be completely easy. >>>=20 >>> Help appreciated. >>>=20 >>> Here is what I did: I excluded the xCard structures from the XML = schema but due to the extensibility mechanism with the any = namespace=3D"##other" construct you can add pretty much everything = anyway. >>>=20 >>> Here is an example of the resulting XML schema: >>> = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/emergencyCall.SubInfo.xsd >>>=20 >>> Here is an instance document: >>> = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/emergencyCall.SubInfo-example.xml >>>=20 >>> If you are not happy with the result there are three other ways to = solve the problem: >>>=20 >>> 1) Create an XML schema of the XCard structure >>> 2) Remove all XML schemas from the additional data document >>> 3) Find out whether there is a way to import Relax NG schemas into = an XML schema >>>=20 >>> Ciao >>> Hannes >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 From James.Winterbottom@commscope.com Wed May 1 14:52:45 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF14D21F9AAF for ; Wed, 1 May 2013 14:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLVyEXvSQMd8 for ; Wed, 1 May 2013 14:52:40 -0700 (PDT) Received: from cdcsmgw02.commscope.com (smtp1.andrew.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id B73B721F9AAD for ; Wed, 1 May 2013 14:52:40 -0700 (PDT) X-AuditID: 0a0404e9-b7f996d000000830-16-51818ea72e15 Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id B7.DA.02096.7AE81815; Wed, 1 May 2013 16:52:39 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 1 May 2013 16:52:33 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 2 May 2013 05:52:30 +0800 From: "Winterbottom, James" To: Brian Rosen , Hannes Tschofenig Date: Thu, 2 May 2013 05:52:28 +0800 Thread-Topic: [Ecrit] Additional Data: XML Schema and Instance Documents Thread-Index: Ac5GsvWuMqWgp9opT6CaiQodWeovLAAAyyFA Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140958C31@SISPE7MB1.commscope.com> References: <5180DE05.5090703@gmx.net> <6761E4D2-5CFA-4280-9EAA-E1CFF97E66E2@brianrosen.net> <5181878C.8090301@gmx.net> <7FB7BBC1-8F3D-4BEC-BE71-9515A2D15B2C@brianrosen.net> In-Reply-To: <7FB7BBC1-8F3D-4BEC-BE71-9515A2D15B2C@brianrosen.net> 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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCKsWRmVeSWpSXmKPExsXCFSYjqru8rzHQYMJ8PYun96exWTQuespq sXTnPVYHZo/73/6yeyzetJ/NY8mSn0wBzFFcNimpOZllqUX6dglcGcfvz2AveChdcXL6RsYG xl7xLkYODgkBE4lzzVldjJxAppjEhXvr2UBsIYFdjBJrbmt3MXIB2esZJU51X2KGcNYxSlx+ +5YZpIpNwE7i8PobYLaIQIjEh4cTmEBsZgFViXONj1lAbBYBFYnOiVsYQWxhAXeJZ2+Ps0HU e0i8uvMSqtdI4sPkaWA1vAJBEgeWHWeEWLaZUWL2xENgDZwCThI7rkAsZgQ69fupNVDLxCVu PZnPBPGCgMSSPeeZIWxRiZeP/7FC1ItK3GlfzwhRryOxYPcnNghbW2LZwtfMEIsFJU7OfMIC 8b6uRNPOr6wTGCVmIVkxC0n7LCTts5C0L2BkWcUonpySXJybXm5gpJecn5tbnJxfkApibWIE RSILy8sdjGc3aB9iFOBgVOLh/aDbGCjEmlhWXJl7iFGSg0lJlPdoF1CILyk/pTIjsTgjvqg0 J7X4EKMEB7OSCO+M3w2BQrwpiZVVqUX5MCkNDg6B00/un2KUYsnLz0tVkuBN7gUaIViUmp5a kZaZA0xDMKVMHJwgo3iARk0DqeEtLkjMLc5Mh8ifYtTmmLX1yWtGjhWbX75mFAIbJyXOWwRS KgBSmlGaBzftFaM40AvCvKUgWR5gUoWb8wpoBRPQip1V9SArShIRUlINjEUOVrPsj/NG/a1e uHNL+R1vk/fX2fwXWC8QSJm4MHxvaqF8xqF3ZX0iGqVGGhz8Vnk5FZqHIgvtY38w9W48+VpP yXofd6aJp/m9q9ZPdaY+D+PL/iw0TX2b9uPSxxKNb4oDNh4Ta9cKNAjruvtfqtdGIo3/WsOh aTvjpF8w13YtW9SsanNaiaU4I9FQi7moOBEAJZ0U92cDAAA= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data: XML Schema and Instance Documents X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 21:52:45 -0000 As a non-normative appendix. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of B= rian Rosen Sent: Thursday, 2 May 2013 7:29 AM To: Hannes Tschofenig Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: XML Schema and Instance Documents I'll look it over, but I think you should put it in the draft. Brian On May 1, 2013, at 5:22 PM, Hannes Tschofenig w= rote: > Hi Brian, >=20 > I converted the vCard Relax NG schema into an XML schema (using trang and= changed it slightly) and incorporated it into one of the XML schemas from = the draft. >=20 > Here is the vCard XML schema: > https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional= -data/xml/vcard.xsd >=20 > Here is the updated subscriber info schema: > https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional= -data/xml/emergencyCall.SubInfo.xsd >=20 > Here is the one instance document: > https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional= -data/xml/emergencyCall.SubInfo-example.xml >=20 > I hope I got it right. >=20 > So, I could put the vCard XML schema into the draft. >=20 > Ciao > Hannes >=20 >=20 > On 05/01/2013 05:26 PM, Brian Rosen wrote: >> There is a 4) Make Relax NG schemas for additional-data. >>=20 >> But, actually, unless 3) is realistic, I vote for 1). It's not hard, an= d NENA would really appreciate a referenceable XML schema for XCard. >>=20 >> Brian >>=20 >> On May 1, 2013, at 5:19 AM, Hannes Tschofenig wrote: >>=20 >>> Hi all, >>>=20 >>> I went through the document and validated various XML schemas. I also a= dded examples. >>>=20 >>> You can find them here: >>> https://github.com/hannestschofenig/tschofenig-ids/tree/master/addition= al-data/xml >>>=20 >>> One problem I ran into was with regard to the XML-based VCard structure= (called xCard). RFC 6351, see http://tools.ietf.org/html/rfc6351, defines = a Relax NG schema rather than an XML schema and I was not able to use it di= rectly within the additional data XML schemas. >>>=20 >>> I don't know whether someone of you had ever tried to mix XML schemas a= nd Relax NG schemas but it does not seem to be completely easy. >>>=20 >>> Help appreciated. >>>=20 >>> Here is what I did: I excluded the xCard structures from the XML schema= but due to the extensibility mechanism with the any namespace=3D"##other" = construct you can add pretty much everything anyway. >>>=20 >>> Here is an example of the resulting XML schema: >>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/addition= al-data/xml/emergencyCall.SubInfo.xsd >>>=20 >>> Here is an instance document: >>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/addition= al-data/xml/emergencyCall.SubInfo-example.xml >>>=20 >>> If you are not happy with the result there are three other ways to solv= e the problem: >>>=20 >>> 1) Create an XML schema of the XCard structure >>> 2) Remove all XML schemas from the additional data document >>> 3) Find out whether there is a way to import Relax NG schemas into an X= ML schema >>>=20 >>> Ciao >>> Hannes >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@commscope.com Wed May 1 15:01:54 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160F921F9B35 for ; Wed, 1 May 2013 15:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udiWGXx+dPQF for ; Wed, 1 May 2013 15:01:49 -0700 (PDT) Received: from cdcsmgw02.commscope.com (cdcsmgw02.commscope.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id BC5AC21F9B21 for ; Wed, 1 May 2013 15:01:39 -0700 (PDT) X-AuditID: 0a0404e9-b7f996d000000830-b0-518190c320db Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id 00.0B.02096.3C091815; Wed, 1 May 2013 17:01:39 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 1 May 2013 17:01:38 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 2 May 2013 06:01:36 +0800 From: "Winterbottom, James" To: Matt Serra , Gunnar Hellstrom , Hannes Tschofenig Date: Thu, 2 May 2013 06:01:34 +0800 Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-07 Thread-Index: Ac5GnSoTrY97AFDvTF2z5guA13AdMQABN8wQAAUP0sA= Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140958C32@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> <517F623C.9050909@omnitor.se> <5180DECF.4080405@gmx.net> <51815044.9050309@omnitor.se> <6B92B1E73D1E7B468E5C97CAE569CBA1215369EB0B@MBX05.exg5.exghost.com> In-Reply-To: <6B92B1E73D1E7B468E5C97CAE569CBA1215369EB0B@MBX05.exg5.exghost.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJKsWRmVeSWpSXmKPExsXCFSaSpnt4QmOgwf8T4haNi56yWux4f4bF YunOe6wWV5/+Z3dg8Vi8aT+bx5IlP5k8Ji7+xOxxZd4OtgCWKC6blNSczLLUIn27BK6M7v/v 2Quemla0T/vM3sC4T7uLkZNDQsBE4sD8zewQtpjEhXvr2boYuTiEBHYzSpyc+ocdwlnPKLHj wXJmCGcto8TRpU/AWtgE7CQOr7/BDGKLCPQySsxfGgViMwuoSpxrfMwCYrMIqEjs6bkFZgsL WEi8XHKNCaLeUuLq7PtsELaVRNvhuawgNq9AkMTiTfvA4kICi5gkXs/nArE5BQIkdv1YDraL EejU76fWMEHsEpe49WQ+E8QLAhJL9pxnhrBFJV4+/scKUS8qcad9PSNEvZ7EjalT2CBsbYll C18zQ+wVlDg58wkLxF5diaadX1knMErMQrJiFpL2WUjaZyFpX8DIsopRPDkluTg3vdzASC85 Pze3ODm/IBXE2sQIik8Wlpc7GM9u0D7EKMDBqMTD+0G3MVCINbGsuDL3EKMkB5OSKK9NP1CI Lyk/pTIjsTgjvqg0J7X4EKMEB7OSCO+M3w2BQrwpiZVVqUX5MCkNDg6B00/un2KUYsnLz0tV kuBtBxkhWJSanlqRlpkDTE4wpUwcnCCjeIBGlYHU8BYXJOYWZ6ZD5E8xqnKs2PzyNaMQ2CAp cV5XkCIBkKKM0jy4Oa8YxYGOF+YNB8nyANMr3IRXQMOZgIbvrKoHGV6SiJCSamDMvx/SYuGj +SZUwMJa9VDL2a8rMpY7rVn9ZemfGdtNJ1zm522/Xad7xk/xcNUaoWyFDWI3eY597TObNNF2 frZdSfhH/YPLuZ//4LsUfFdgkeqWh1Z/X2XMPLThZXuO2NSUWV2pfA/qRUu2rjIpnmm/Sd4h 4iPvkufxU86FHv7afWSTW9yEqlN9SizFGYmGWsxFxYkA+K9Fc2wDAAA= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 22:01:54 -0000 Hi Matt, I am not sure that I follow your assertion. In the cases that I know of, a subscriber gets an Internet subscription fro= m an ISP. How that ISP implements that service and makes it available to th= e subscriber is largely unknown to the subscriber. The subscriber only has = a relationship with the ISP, so it is quite possible that the physical "las= t-mile" provider has no idea of the service being run over the physical med= ium or who the person is that is running this data, all they know is where = the able terminates and that the ISP (the organization that they have the c= ontract with) has the other information.=20 So I think that the question really boils down to who is providing the serv= ice and to whom. So far, all the entities really relate to the service actu= ally subscribed to by the caller. If we take this approach, then I don't se= e a need to go down to the level you describe, or even how we would get the= re in a timely fashion. I think that this could be provided as follow-up in= formation manually if really required. Cheers James =20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= att Serra Sent: Thursday, 2 May 2013 5:37 AM To: Gunnar Hellstrom; Hannes Tschofenig Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 One thought: It may be worthwhile to distinguish "Internet Access Provider= " over Internet Service Provider, no? For the purposes of this RFC, the "access" provider we are referring to is = expected to be the provider of the location associated with the call's PIDF= -LO. This is the entity that knows the location of the device placing the call. = Typically this will be the "last mile" provider, as opposed to a different= internet service provider in the middle of the call path (who probably doe= sn't even know the data is associated with an emergency call). If we can use language that helps make this distinction, I think that would= be a good thing. Matthew A. Serra, ENP Sr. Director, Product Management=20 Rave Mobile Safety | Smart911 Mobile:=A0=A0201.245.1557 mserra@ravemobilesafety.com =20 -----Original Message----- From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se]=20 Sent: Wednesday, May 01, 2013 1:26 PM To: Hannes Tschofenig Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 On 2013-05-01 11:22, Hannes Tschofenig wrote: > Hi Gunnar, > > thanks for the feedback. > > Based on your input I added the following text to the terminology=20 > section of the draft. > > " > This document also uses terminology from [RFC5012]. We use the term > service provider to refer to an Application Service Provider (ASP) or > to Voice Service Provider (VSP), which is a specific type of ASP. > With the term "Access Network Provider" we refer to the Internet > Access Provider (IAP) and the Internet Service Provider (ISP) without > further distinguishing these two entities, since the difference > between the two is not relevant for this document. Note that the > roles of ASP and access network provider may be provided by a single > company. > " > > Do you think that this change will help to improve readability of the=20 > document? Yes. You need also do something to the table in section 14.1.2. There you say that the whole table is about service providers, and then one= of the kinds of service providers is called just "service provider".=20 That is unclear logic. /Gunnar > > Ciao > Hannes > > > > On 04/30/2013 09:18 AM, Gunnar Hellstrom wrote: >> >> ------------------------------------------------------------------------ >> Gunnar Hellstr=F6m >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46708204288 >> On 2013-04-29 23:22, Hannes Tschofenig wrote: >>> Hi James, >>> >>> I am trying to incorporate some of your review comments and I have a=20 >>> couple of questions. >>> >>> On Mar 18, 2013, at 5:41 AM, Winterbottom, James wrote: >>> >>>> Hi Authors, >>>> >>>> I have reviewed this document and have the following comments, some=20 >>>> of which I have already posted to the list and have not had a reply=20 >>>> to. >>>> >>>> Comments: >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> The term "Service Provider" is used extensively throughout this=20 >>>> document but the term doesn't seem to be obviously defined in the=20 >>>> document, nor is there is a reference to an external definition. To=20 >>>> add to this, Service Provider is a defined type in section 14.1.2,=20 >>>> but used more generally throughout the rest of the document. This=20 >>>> needs a clarification. >>> I searched for an appropriate definition in IETF RFCs and it turns=20 >>> out that others have defined this term either. >>> >>> Do you have a recommendation what we should use? Do you think it is=20 >>> really necessary to describe it? >> I had a similar problem in another SDO recently. I used "service >> provider" or "communication service provider" for an organization >> handling calls and subscribers. >> The conclusion there was to change it to "Application Service Provider" >> with the following definition: >> >> *"Application Service Provider (ASP): *organization or entity that >> provides application-layer services, which may include voice, video and >> text communication" >> >> The reason for confusion was apparently that some thought of the network >> access service provider while others thought about the call control >> service provider when using the term "service provider". >> >> It stands out clear in section14.1.2. that it is a problem. >> The table with service provider types contains "service provider" as one >> of the types. >> >> At least this recursive use of the term needs to be broken. >> >> I briefly checked RFC 6881 and RFC 4504 to check how they handled >> "service provider" and found that you are in good company. The term is >> just used without definition and seems to mean an organization working >> on the SIP or other call control level and manages subscribers. >> >> I suggest that this definition is used: >> >> *"Application Service Provider (ASP): *organization or entity that >> provides application-layer services, which may include real-time >> communication" >> >> And then check through the occurrences and replace the ones that have >> the narrow meaning of "Application Service Provider". >> >> >> /Gunnar >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Wed May 1 17:06:36 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09C821F9B3B for ; Wed, 1 May 2013 17:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+krHdS766DQ for ; Wed, 1 May 2013 17:06:31 -0700 (PDT) Received: from mm2.idig.net (raphotoclub.ca [70.33.247.99]) by ietfa.amsl.com (Postfix) with ESMTP id A703D21F9B27 for ; Wed, 1 May 2013 17:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=nfsvvcE4xhnrS43AQSV8iSuqvYy/481R4ajLLBXaGbs=; b=P9LXFtrheyfZx95npsG7hmpXjhyO3zNrabnNUEA5uf1gu2ArFYSzxWxEmE6ZJFf2tpYZd0eGcpUziCrCAq4M6moZ1CGcKkGzuqSZuesHbLaetFzrGLOGQ/4vQs06RO85uftqcuzglK9oXWPejaNTVQelaTmgyye+2cOACHrGIUM=; Received: from neustargw.va.neustar.com ([209.173.53.233]:33002 helo=[10.33.192.26]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UXh2c-0006aO-Nd; Wed, 01 May 2013 20:06:30 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188012140958C31@SISPE7MB1.commscope.com> Date: Wed, 1 May 2013 20:06:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5180DE05.5090703@gmx.net> <6761E4D2-5CFA-4280-9EAA-E1CFF97E66E2@brianrosen.net> <5181878C.8090301@gmx.net> <7FB7BBC1-8F3D-4BEC-BE71-9515A2D15B2C@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC8188012140958C31@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data: XML Schema and Instance Documents X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 00:06:36 -0000 non normative? How do you get interoperability? On May 1, 2013, at 5:52 PM, "Winterbottom, James" = wrote: > As a non-normative appendix. >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Brian Rosen > Sent: Thursday, 2 May 2013 7:29 AM > To: Hannes Tschofenig > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Additional Data: XML Schema and Instance = Documents >=20 > I'll look it over, but I think you should put it in the draft. >=20 > Brian > On May 1, 2013, at 5:22 PM, Hannes Tschofenig = wrote: >=20 >> Hi Brian, >>=20 >> I converted the vCard Relax NG schema into an XML schema (using trang = and changed it slightly) and incorporated it into one of the XML schemas = from the draft. >>=20 >> Here is the vCard XML schema: >> = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/vcard.xsd >>=20 >> Here is the updated subscriber info schema: >> = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/emergencyCall.SubInfo.xsd >>=20 >> Here is the one instance document: >> = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/emergencyCall.SubInfo-example.xml >>=20 >> I hope I got it right. >>=20 >> So, I could put the vCard XML schema into the draft. >>=20 >> Ciao >> Hannes >>=20 >>=20 >> On 05/01/2013 05:26 PM, Brian Rosen wrote: >>> There is a 4) Make Relax NG schemas for additional-data. >>>=20 >>> But, actually, unless 3) is realistic, I vote for 1). It's not = hard, and NENA would really appreciate a referenceable XML schema for = XCard. >>>=20 >>> Brian >>>=20 >>> On May 1, 2013, at 5:19 AM, Hannes Tschofenig = wrote: >>>=20 >>>> Hi all, >>>>=20 >>>> I went through the document and validated various XML schemas. I = also added examples. >>>>=20 >>>> You can find them here: >>>> = https://github.com/hannestschofenig/tschofenig-ids/tree/master/additional-= data/xml >>>>=20 >>>> One problem I ran into was with regard to the XML-based VCard = structure (called xCard). RFC 6351, see = http://tools.ietf.org/html/rfc6351, defines a Relax NG schema rather = than an XML schema and I was not able to use it directly within the = additional data XML schemas. >>>>=20 >>>> I don't know whether someone of you had ever tried to mix XML = schemas and Relax NG schemas but it does not seem to be completely easy. >>>>=20 >>>> Help appreciated. >>>>=20 >>>> Here is what I did: I excluded the xCard structures from the XML = schema but due to the extensibility mechanism with the any = namespace=3D"##other" construct you can add pretty much everything = anyway. >>>>=20 >>>> Here is an example of the resulting XML schema: >>>> = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/emergencyCall.SubInfo.xsd >>>>=20 >>>> Here is an instance document: >>>> = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/emergencyCall.SubInfo-example.xml >>>>=20 >>>> If you are not happy with the result there are three other ways to = solve the problem: >>>>=20 >>>> 1) Create an XML schema of the XCard structure >>>> 2) Remove all XML schemas from the additional data document >>>> 3) Find out whether there is a way to import Relax NG schemas into = an XML schema >>>>=20 >>>> Ciao >>>> Hannes >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@commscope.com Wed May 1 17:20:02 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342EF21F9B61 for ; Wed, 1 May 2013 17:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aD1qAfgIcTik for ; Wed, 1 May 2013 17:19:58 -0700 (PDT) Received: from cdcsmgw02.commscope.com (cdcsmgw02.commscope.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id 21F0B21F9B27 for ; Wed, 1 May 2013 17:19:58 -0700 (PDT) X-AuditID: 0a0404e9-b7f996d000000830-3c-5181b12d9939 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id 5F.8C.02096.D21B1815; Wed, 1 May 2013 19:19:57 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 1 May 2013 19:19:56 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 2 May 2013 08:19:54 +0800 From: "Winterbottom, James" To: Brian Rosen Date: Thu, 2 May 2013 08:19:52 +0800 Thread-Topic: [Ecrit] Additional Data: XML Schema and Instance Documents Thread-Index: Ac5GyOh7+ypwYO7sT0S6cPaRFWm5gwAAcqDw Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140958C3E@SISPE7MB1.commscope.com> References: <5180DE05.5090703@gmx.net> <6761E4D2-5CFA-4280-9EAA-E1CFF97E66E2@brianrosen.net> <5181878C.8090301@gmx.net> <7FB7BBC1-8F3D-4BEC-BE71-9515A2D15B2C@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC8188012140958C31@SISPE7MB1.commscope.com> 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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGKsWRmVeSWpSXmKPExsXCFSaSrqu7sTHQ4MlMJYun96exWTQuespq sXTnPVYHZo/73/6yeyzetJ/NY8mSn0wBzFFcNimpOZllqUX6dglcGcfPdrMXHFKoeNrwg62B sVO6i5GTQ0LAROLij9eMELaYxIV769m6GLk4hAR2M0q8uPaWBcJZzyix8+4TqMxaRokHZ16z gLSwCdhJHF5/gxnEFhFQlth5q5MdxGYWCJPYe/M22FgWARWJPQd2gtUIC7hLPHt7nA2i3kPi 1Z2XUL1GEnMf7gSbySsQJHFixS5GiGVbmCQeP98DluAUcJJofXgZzGYEuvX7qTVMEMvEJW49 mc8E8YOAxJI955khbFGJl4//sULUi0rcaV/PCFGvI7Fg9yc2CFtbYtnC18wQiwUlTs58AjZf SEBXomnnV9YJjBKzkKyYhaR9FpL2WUjaFzCyrGIUT05JLs5NLzcw0kvOz80tTs4vSAWxNjGC opGF5eUOxrMbtA8xCnAwKvHwftBtDBRiTSwrrsw9xCjJwaQkyjt1LVCILyk/pTIjsTgjvqg0 J7X4EKMEB7OSCO/PaUA53pTEyqrUonyYlAYHh8DpJ/dPMUqx5OXnpSpJ8OptACoTLEpNT61I y8wBpiKYUiYOTpBRPECj7q4HGVVckJhbnJkOkT/FqM0xa+uT14wcKza/fM0oBDZOSpz3LUip AEhpRmke3LRXjOJALwjzsoEs4wEmVrg5r4BWMAGt2FlVD7KiJBEhJdXAaDDx6nWhlNCef2zK Bo8i39/aN+Wqytm4U0sT/8z6LRZ+Ja/pt3FlfvEZhUlftK31j5w1N1vKZi3yazrbyuowTf6p 80Imn6xL+1nRaBTu/aqgt0bU9ob6nprydYG81hciIrmlp3bst7nPJ3vhuFPOquNNH/ZJdWhs iFpc9iHXiiX/3N/YAxYJSizFGYmGWsxFxYkAN3Pdm2kDAAA= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data: XML Schema and Instance Documents X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 00:20:02 -0000 The XSD at the back of LoST is non-normative. Why is this different? -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, 2 May 2013 10:06 AM To: Winterbottom, James Cc: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: XML Schema and Instance Documents non normative? How do you get interoperability? On May 1, 2013, at 5:52 PM, "Winterbottom, James" wrote: > As a non-normative appendix. >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Brian Rosen > Sent: Thursday, 2 May 2013 7:29 AM > To: Hannes Tschofenig > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Additional Data: XML Schema and Instance Documents >=20 > I'll look it over, but I think you should put it in the draft. >=20 > Brian > On May 1, 2013, at 5:22 PM, Hannes Tschofenig = wrote: >=20 >> Hi Brian, >>=20 >> I converted the vCard Relax NG schema into an XML schema (using trang an= d changed it slightly) and incorporated it into one of the XML schemas from= the draft. >>=20 >> Here is the vCard XML schema: >> https://github.com/hannestschofenig/tschofenig-ids/blob/master/additiona= l-data/xml/vcard.xsd >>=20 >> Here is the updated subscriber info schema: >> https://github.com/hannestschofenig/tschofenig-ids/blob/master/additiona= l-data/xml/emergencyCall.SubInfo.xsd >>=20 >> Here is the one instance document: >> https://github.com/hannestschofenig/tschofenig-ids/blob/master/additiona= l-data/xml/emergencyCall.SubInfo-example.xml >>=20 >> I hope I got it right. >>=20 >> So, I could put the vCard XML schema into the draft. >>=20 >> Ciao >> Hannes >>=20 >>=20 >> On 05/01/2013 05:26 PM, Brian Rosen wrote: >>> There is a 4) Make Relax NG schemas for additional-data. >>>=20 >>> But, actually, unless 3) is realistic, I vote for 1). It's not hard, a= nd NENA would really appreciate a referenceable XML schema for XCard. >>>=20 >>> Brian >>>=20 >>> On May 1, 2013, at 5:19 AM, Hannes Tschofenig wrote: >>>=20 >>>> Hi all, >>>>=20 >>>> I went through the document and validated various XML schemas. I also = added examples. >>>>=20 >>>> You can find them here: >>>> https://github.com/hannestschofenig/tschofenig-ids/tree/master/additio= nal-data/xml >>>>=20 >>>> One problem I ran into was with regard to the XML-based VCard structur= e (called xCard). RFC 6351, see http://tools.ietf.org/html/rfc6351, defines= a Relax NG schema rather than an XML schema and I was not able to use it d= irectly within the additional data XML schemas. >>>>=20 >>>> I don't know whether someone of you had ever tried to mix XML schemas = and Relax NG schemas but it does not seem to be completely easy. >>>>=20 >>>> Help appreciated. >>>>=20 >>>> Here is what I did: I excluded the xCard structures from the XML schem= a but due to the extensibility mechanism with the any namespace=3D"##other"= construct you can add pretty much everything anyway. >>>>=20 >>>> Here is an example of the resulting XML schema: >>>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/additio= nal-data/xml/emergencyCall.SubInfo.xsd >>>>=20 >>>> Here is an instance document: >>>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/additio= nal-data/xml/emergencyCall.SubInfo-example.xml >>>>=20 >>>> If you are not happy with the result there are three other ways to sol= ve the problem: >>>>=20 >>>> 1) Create an XML schema of the XCard structure >>>> 2) Remove all XML schemas from the additional data document >>>> 3) Find out whether there is a way to import Relax NG schemas into an = XML schema >>>>=20 >>>> Ciao >>>> Hannes >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Thu May 2 06:12:11 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441E321F8976 for ; Thu, 2 May 2013 06:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDMNh4U+xfBj for ; Thu, 2 May 2013 06:12:07 -0700 (PDT) Received: from mm2.idig.net (raphotoclub.ca [70.33.247.99]) by ietfa.amsl.com (Postfix) with ESMTP id D1E5121F8AF8 for ; Thu, 2 May 2013 06:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=KG/QHIUXeTf4YE1H6q3TW/6VWsTiulRpdjAJ1G2X1aw=; b=mEwwvoCmDe6xHS5i9IpA3OQoZi7k7Sbmfq6ixDyPV8FtM+/TSPfQZm57P8zFqYichhZ2AwLgMtC0hzoHYPV8qzsR0lBNAV9N4Nd4Y/WU8KJTXU1zZPsl+ZLmUpGyliaaohVSkxjN3zyhgvkzHHoEESx6l12i7IrFr6YerajJ9AQ=; Received: from neustargw.va.neustar.com ([209.173.53.233]:33927 helo=[10.33.192.26]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UXtIg-0004Uw-6P; Thu, 02 May 2013 09:11:54 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188012140958C3E@SISPE7MB1.commscope.com> Date: Thu, 2 May 2013 09:11:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1DA8FB31-13E7-4B78-8BEA-6FC9C143D179@brianrosen.net> References: <5180DE05.5090703@gmx.net> <6761E4D2-5CFA-4280-9EAA-E1CFF97E66E2@brianrosen.net> <5181878C.8090301@gmx.net> <7FB7BBC1-8F3D-4BEC-BE71-9515A2D15B2C@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC8188012140958C31@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188012140958C3E@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data: XML Schema and Instance Documents X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 13:12:11 -0000 Because the normative schema is in section 15. In 5222 the normative = schema is Relax NG, and they provide an informative xsd in the appendix. Of course, with XCard the normative Relax NG schema is in 6351, but in = this case, we have a normative XSD in the body of the document, and we = need a normative XSD for the XCard somewhere. If we changed the entire doc to Relax NG and provided non-normative xsd = for that in an appendix, then a non-normative appendix for the XCard = could be included. The appendix, if normative, should include text that says that this does = not change 6351 in any way. I would venture to guess this is not the first time this problem has = arisen and we should be able to get guidance. Brian On May 1, 2013, at 8:19 PM, "Winterbottom, James" = wrote: > The XSD at the back of LoST is non-normative. Why is this different? >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Thursday, 2 May 2013 10:06 AM > To: Winterbottom, James > Cc: Brian Rosen; Hannes Tschofenig; ecrit@ietf.org > Subject: Re: [Ecrit] Additional Data: XML Schema and Instance = Documents >=20 > non normative? How do you get interoperability? >=20 > On May 1, 2013, at 5:52 PM, "Winterbottom, James" = wrote: >=20 >> As a non-normative appendix. >>=20 >>=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of Brian Rosen >> Sent: Thursday, 2 May 2013 7:29 AM >> To: Hannes Tschofenig >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Additional Data: XML Schema and Instance = Documents >>=20 >> I'll look it over, but I think you should put it in the draft. >>=20 >> Brian >> On May 1, 2013, at 5:22 PM, Hannes Tschofenig = wrote: >>=20 >>> Hi Brian, >>>=20 >>> I converted the vCard Relax NG schema into an XML schema (using = trang and changed it slightly) and incorporated it into one of the XML = schemas from the draft. >>>=20 >>> Here is the vCard XML schema: >>> = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/vcard.xsd >>>=20 >>> Here is the updated subscriber info schema: >>> = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/emergencyCall.SubInfo.xsd >>>=20 >>> Here is the one instance document: >>> = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/emergencyCall.SubInfo-example.xml >>>=20 >>> I hope I got it right. >>>=20 >>> So, I could put the vCard XML schema into the draft. >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>> On 05/01/2013 05:26 PM, Brian Rosen wrote: >>>> There is a 4) Make Relax NG schemas for additional-data. >>>>=20 >>>> But, actually, unless 3) is realistic, I vote for 1). It's not = hard, and NENA would really appreciate a referenceable XML schema for = XCard. >>>>=20 >>>> Brian >>>>=20 >>>> On May 1, 2013, at 5:19 AM, Hannes Tschofenig = wrote: >>>>=20 >>>>> Hi all, >>>>>=20 >>>>> I went through the document and validated various XML schemas. I = also added examples. >>>>>=20 >>>>> You can find them here: >>>>> = https://github.com/hannestschofenig/tschofenig-ids/tree/master/additional-= data/xml >>>>>=20 >>>>> One problem I ran into was with regard to the XML-based VCard = structure (called xCard). RFC 6351, see = http://tools.ietf.org/html/rfc6351, defines a Relax NG schema rather = than an XML schema and I was not able to use it directly within the = additional data XML schemas. >>>>>=20 >>>>> I don't know whether someone of you had ever tried to mix XML = schemas and Relax NG schemas but it does not seem to be completely easy. >>>>>=20 >>>>> Help appreciated. >>>>>=20 >>>>> Here is what I did: I excluded the xCard structures from the XML = schema but due to the extensibility mechanism with the any = namespace=3D"##other" construct you can add pretty much everything = anyway. >>>>>=20 >>>>> Here is an example of the resulting XML schema: >>>>> = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/emergencyCall.SubInfo.xsd >>>>>=20 >>>>> Here is an instance document: >>>>> = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/xml/emergencyCall.SubInfo-example.xml >>>>>=20 >>>>> If you are not happy with the result there are three other ways to = solve the problem: >>>>>=20 >>>>> 1) Create an XML schema of the XCard structure >>>>> 2) Remove all XML schemas from the additional data document >>>>> 3) Find out whether there is a way to import Relax NG schemas into = an XML schema >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From prvs=2834ca5633=christer.holmberg@ericsson.com Thu May 2 06:20:40 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7C421F84A6 for ; Thu, 2 May 2013 06:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hofU09lo2Q8 for ; Thu, 2 May 2013 06:20:33 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id F29B021F8314 for ; Thu, 2 May 2013 06:20:31 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-3f-5182681ec169 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5C.A5.32006.E1862815; Thu, 2 May 2013 15:20:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 2 May 2013 15:20:30 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: draft-holmberg-ecrit-country-emg-urn: Modifications to suggested new text for section 4.2 of RFC 5031 Thread-Index: Ac5HN8eJkr18YLEeSgK6JXaqZssQ9g== Date: Thu, 2 May 2013 13:20:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3699D3@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3699D3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvra5cRlOgwddjBhaNi56yWlzpW8nk wOTx9dZBJo8lS34yBTBFcdskJZaUBWem5+nbJXBn9O24xlxwUaJi/fbpbA2Md0S7GDk4JARM JP5+kupi5AQyxSQu3FvP1sXIxSEkcJhRYu7FHcwQzmJGiftrzrOBNLAJWEh0/9MGaRARUJXY cGYlI4jNLOAqcX/TFiYQW1igQKLpxSxGiJpSiWvb37NB2HoS23v7wGwWARWJhb3/WUFsXgFf iQeTdoPVMwId8f3UGiaImeISt57MZ4I4TkBiyZ7zzBC2qMTLx/9YIWxFiavTl0PV50v0t0xn h5gpKHFy5hOWCYzCs5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkT03 MTMnvdxoEyMwRg5u+a26g/HOOZFDjNIcLErivMlcjYFCAumJJanZqakFqUXxRaU5qcWHGJk4 OEEEl1QD44Z95/VvBwflmMdPfGu40zdF5gbTWgvmzj0udxbO+6MVbNuQEHFKr16pVzFt5Yf9 B3ps4/63f/2ksYn9hLj5ubDYY+JdvTfycu7+5AhXVGf9J3Xo8VmBPZMdjl7YltbupPzuDmPF ksZSTh5GL+Hpwv5nwuasqX9lsODnlDVBnQtn3T/47wE7nxJLcUaioRZzUXEiAHYTjVFkAgAA Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn: Modifications to suggested new text for section 4.2 of RFC 5031 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 13:20:40 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3699D3ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In Orlando, at least Henning indicated that he would like to modify, and ex= pand, the suggested new text for section 4.2 of RFC 5031. I would appreciate if those who want modifications provide some text - or a= t least some explanation of what modifications they would like to see :) Thanks! Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C3699D3ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In Orlando, at least Henning indicated that he would= like to modify, and expand, the suggested new text for section 4.2 of RFC = 5031.

 

I would appreciate if those who want modifications p= rovide some text – or at least some explanation of what modifications= they would like to see :)

 

Thanks!

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1C3699D3ESESSMB209erics_-- From martin.thomson@gmail.com Thu May 2 10:25:47 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CF021F8FB6 for ; Thu, 2 May 2013 10:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8S5KUo1sB5Df for ; Thu, 2 May 2013 10:25:46 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE1C21F85EE for ; Thu, 2 May 2013 10:25:43 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id x12so866298wgg.9 for ; Thu, 02 May 2013 10:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=O3osiScXnIsTTbK7UJC4+sKELjgEMHGziYDiAJLJnlQ=; b=HS65KHa6mhBbWebNV/8j9ChoxhVP3KVbZFKxsb5W1oBDj9RflKlRz6sndbDPx94IIs FTFIaycrL5O4fVA+HXPPBwy4VggQ279wuv8DkXkqTstj9JCk9ZxIQYjwdErDMOVOARvG SaCBUUavs4ymhpIEo9zNmMkRRJHywxUH0dHag1L7Ojo+4an1c49WH2DN7lEJiAuYuSaG ep9VgSSUq5g0I9XxVeQwSA6ayIoONQSJvZ87BVCZ5ebl4pNOIWZrxj3xFDwJEUB1JARR Xo3hWv03nu1OsbNVhB9gQ7AMjyIVuUQlgNCjeIas+7lIPckl6TbNMAzltGRw/3uEC2HK MEcw== MIME-Version: 1.0 X-Received: by 10.194.109.227 with SMTP id hv3mr9428411wjb.32.1367515535593; Thu, 02 May 2013 10:25:35 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Thu, 2 May 2013 10:25:35 -0700 (PDT) In-Reply-To: <1DA8FB31-13E7-4B78-8BEA-6FC9C143D179@brianrosen.net> References: <5180DE05.5090703@gmx.net> <6761E4D2-5CFA-4280-9EAA-E1CFF97E66E2@brianrosen.net> <5181878C.8090301@gmx.net> <7FB7BBC1-8F3D-4BEC-BE71-9515A2D15B2C@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC8188012140958C31@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188012140958C3E@SISPE7MB1.commscope.com> <1DA8FB31-13E7-4B78-8BEA-6FC9C143D179@brianrosen.net> Date: Thu, 2 May 2013 10:25:35 -0700 Message-ID: From: Martin Thomson To: Brian Rosen Content-Type: text/plain; charset=UTF-8 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data: XML Schema and Instance Documents X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 17:25:47 -0000 On 2 May 2013 06:11, Brian Rosen wrote: > Of course, with XCard the normative Relax NG schema is in 6351, but in this case, we have a normative XSD in the body of the document, and we need a normative XSD for the XCard somewhere. Not true. A normative schema might be necessary, but for this the RelaxNG in 6351 is sufficient. The XSD is a validation and implementation convenience. Include the XSD to inform readers that this (not the RelaxNG) was used to construct and validate the examples. This XSD can't be normative unless you want to update 6351. Don't do that. From hannes.tschofenig@gmx.net Thu May 2 12:12:26 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F8A21F871C for ; Thu, 2 May 2013 12:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwUZqZuFbHz7 for ; Thu, 2 May 2013 12:12:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id B8B2B21F86F4 for ; Thu, 2 May 2013 12:12:21 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MbNNK-1UqknX2NCG-00ImtE for ; Thu, 02 May 2013 21:12:19 +0200 Received: (qmail invoked by alias); 02 May 2013 19:12:19 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp002) with SMTP; 02 May 2013 21:12:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18990YjzgU949GgrK0FhWXrzVmWiqeyvaKmwK7LCw 8G6AYEhF6Iyphn Message-ID: <5182BA90.30208@gmx.net> Date: Thu, 02 May 2013 22:12:16 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Martin Thomson References: <5180DE05.5090703@gmx.net> <6761E4D2-5CFA-4280-9EAA-E1CFF97E66E2@brianrosen.net> <5181878C.8090301@gmx.net> <7FB7BBC1-8F3D-4BEC-BE71-9515A2D15B2C@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC8188012140958C31@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188012140958C3E@SISPE7MB1.commscope.com> <1DA8FB31-13E7-4B78-8BEA-6FC9C143D179@brianrosen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data: XML Schema and Instance Documents X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 19:12:26 -0000 You guys are all correct. First, there is no need to have any XML / Relax NG schema to accomplish interoperability. Second, in LoST we provided two types of Relax NG schemas: Section 15 of RFC 5222 specifies the compact Relax NG schema and Appendix A of RFC 5222 has the "verbose" version of the Relax NG schema version of it (for improved readability - whatever that means with schemas anyway). In this specific case we could, as Martin suggested, include the XML schema in the document but indicate that the normative version is in RFC 6351. I am fine with that approach. I will prepare an update; there are still a number of other review comments to address. Ciao Hannes On 05/02/2013 08:25 PM, Martin Thomson wrote: > On 2 May 2013 06:11, Brian Rosen wrote: >> Of course, with XCard the normative Relax NG schema is in 6351, but in this case, we have a normative XSD in the body of the document, and we need a normative XSD for the XCard somewhere. > > Not true. A normative schema might be necessary, but for this the > RelaxNG in 6351 is sufficient. > > The XSD is a validation and implementation convenience. Include the > XSD to inform readers that this (not the RelaxNG) was used to > construct and validate the examples. This XSD can't be normative > unless you want to update 6351. Don't do that. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From James.Winterbottom@commscope.com Thu May 2 13:13:37 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D6421F8EC1 for ; Thu, 2 May 2013 13:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM99uSQFjoCP for ; Thu, 2 May 2013 13:13:32 -0700 (PDT) Received: from cdcsmgw02.commscope.com (smtp1.andrew.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id 77FB721F8E96 for ; Thu, 2 May 2013 13:13:32 -0700 (PDT) X-AuditID: 0a0404e9-b7f996d000000830-f9-5182c8eb9606 Received: from CDCE10HC2.commscope.com ( [10.86.28.22]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id 91.CD.02096.BE8C2815; Thu, 2 May 2013 15:13:31 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 2 May 2013 15:13:31 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 3 May 2013 04:13:28 +0800 From: "Winterbottom, James" To: "'martin.thomson@gmail.com'" , "'br@brianrosen.net'" Date: Fri, 3 May 2013 04:13:27 +0800 Thread-Topic: [Ecrit] Additional Data: XML Schema and Instance Documents Thread-Index: Ac5HWha7Tz+ysstfShmQbBtq7Q3dYgAF2q7w Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121407DA0E5@SISPE7MB1.commscope.com> 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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIKsWRmVeSWpSXmKPExsXCFSYjpvv6RFOgwZ5jUhZP709js2hc9JTV 4tqZf4wOzB73v/1l99g56y67x5IlP5kCmKO4bFJSczLLUov07RK4Mv51tLAV7GavmLNmGnsD YwdbFyMnh4SAicSZTbPZIWwxiQv31gPFuTiEBHYxSjyaNpsVwlnPKDH7wyEWCGcto8SVKU+Z QFrYBOwkDq+/wQxiiwhkSLyacZ4VxGYWUJf4+uA10CgODhYBFYmjb9xBwsIC7hKHnl5lgSj3 kHh15yUzSImIgJHEja2aIGFegSCJw4u6wUo4BQIlXpztBTuUEei476fWMEFMF5e49WQ+E8TR AhJL9pxnhrBFJV4+/scKUS8qcad9PSNEvZ7EjalT2CBsbYllC18zQ+wSlDg58wnYLiEBXYmm nV9ZJzCKz0KyYhaS9llI2mchaV/AyLKKUTw5Jbk4N73cwEgvOT83tzg5vyAVxNrECIo3FpaX OxjPbtA+xCjAwajEwyvd0hQoxJpYVlyZe4hRkoNJSZT38TGgEF9SfkplRmJxRnxRaU5q8SFG CQ5mJRHeX/uAcrwpiZVVqUX5MCkNDg6B00/un2KUYsnLz0tVkuDdchyoTLAoNT21Ii0zB5hs YEqZODhBRvEAjdIFqeEtLkjMLc5Mh8ifYlTlWLH55WtGIbBBUuK850GKBECKMkrz4Oa8YhQH Ol6Y9x9IlgeYLuEmvAIazgQ0fGdVPcjwkkSElFQDI4d288agRzlLj2VnbuZm+ut2PP/4lPA1 BoU3ZdSrpCvfSL9b3efra6ixNX/BbDOTVS8fsx56sjbhgojMxnNnvU1cjkkWrW85lp3VX/K9 I2wCn6jAWZVL3+Uanja8V1g08WDD2plvzqxg3L0xP03zi5xEr1Pi1x7u879/bH12wEU1epLn yqnffymxFGckGmoxFxUnAgCCLBM/VAMAAA== Cc: "'ecrit@ietf.org'" Subject: Re: [Ecrit] Additional Data: XML Schema and Instance Documents X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 20:13:37 -0000 Thanks Martin this was entirely my point. ----- Original Message ----- From: Martin Thomson [mailto:martin.thomson@gmail.com] Sent: Friday, May 03, 2013 01:25 AM=0A= To: Brian Rosen Cc: Winterbottom, James; ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: XML Schema and Instance Documents On 2 May 2013 06:11, Brian Rosen wrote: > Of course, with XCard the normative Relax NG schema is in 6351, but in th= is case, we have a normative XSD in the body of the document, and we need a= normative XSD for the XCard somewhere. Not true. A normative schema might be necessary, but for this the RelaxNG in 6351 is sufficient. The XSD is a validation and implementation convenience. Include the XSD to inform readers that this (not the RelaxNG) was used to construct and validate the examples. This XSD can't be normative unless you want to update 6351. Don't do that. From internet-drafts@ietf.org Sun May 5 04:16:47 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519A721F8F0E; Sun, 5 May 2013 04:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfdN5BXvnWAG; Sun, 5 May 2013 04:16:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A997821F860B; Sun, 5 May 2013 04:16:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p5 Message-ID: <20130505111646.23978.4269.idtracker@ietfa.amsl.com> Date: Sun, 05 May 2013 04:16:46 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-08.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 11:16:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Randall Gellens Filename : draft-ietf-ecrit-additional-data-08.txt Pages : 81 Date : 2013-05-05 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any application service provider in the path of the call, or access network provider through which the call originated may have information about the call or the caller which the PSAP may be able to use. This document describes data structures to convey such data to the PSAP. In addition, data may also be included by reference, via a Uniform Resource Identifier (URI) pointing to data found at an external resource. Consequently, this document follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in body of the SIP message) and also by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Sun May 5 04:30:08 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778CA21F9323 for ; Sun, 5 May 2013 04:30:08 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epe-n6nG+tFz for ; Sun, 5 May 2013 04:30:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1766E21F9322 for ; Sun, 5 May 2013 04:30:00 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.32]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MMZH6-1UdvkP1yDG-008FyO for ; Sun, 05 May 2013 13:29:59 +0200 Received: (qmail invoked by alias); 05 May 2013 11:29:59 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp032) with SMTP; 05 May 2013 13:29:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Kd4dwQrdK9/eMe5uK4AF5fwLIw3Jm/M7ReaHXUf lWcxAE/HMXJn0Y Message-ID: <518642B5.7090700@gmx.net> Date: Sun, 05 May 2013 14:29:57 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "ecrit@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [Ecrit] Additional Data: Version -08 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 11:30:08 -0000 Hi all, I just posted an interim update (as version -08) for the additional data draft. It captures some of the discussions we had on the mailing list recently but it is not a complete update yet since there are a number of other issues that need to be addressed. Here is the updated version: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data From the diff you can see that I * updated the introduction, * added terminology (related to the discussion about service provider), * updated the XML schemas, * included extension points to the schemas, * added more examples (which have been validated against the schemas), * added the vCard/xCard XML schema, * fixed various bugs, and * updated references Ciao Hannes From hannes.tschofenig@gmx.net Sun May 5 11:08:47 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5941C21F95E9 for ; Sun, 5 May 2013 11:08:47 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcQpeRjYz8At for ; Sun, 5 May 2013 11:08:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id B73CA21F8FB8 for ; Sun, 5 May 2013 11:08:40 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MBptp-1UgS0W2Jex-00AmpP for ; Sun, 05 May 2013 20:08:39 +0200 Received: (qmail invoked by alias); 05 May 2013 18:08:39 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp020) with SMTP; 05 May 2013 20:08:39 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/bZ4wEcgfb27mpoLjS949Lzrk2/4a24cbfM7pptl Megi1xrMltBNjc Message-ID: <5186A025.10606@gmx.net> Date: Sun, 05 May 2013 21:08:37 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Gunnar Hellstrom References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> <51816479.409@omnitor.se> In-Reply-To: <51816479.409@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 18:08:47 -0000 Hi Gunnar, thanks for the feedback. Comments below. On 05/01/2013 09:52 PM, Gunnar Hellstrom wrote: > Hannes, > > Looking at the contents of the list of different service providers, I > wonder if there should be more types defined. > It depends of course on what usage this information is expected to have. > > It seems that the various language translation and expert advice > services that can be involved in emergency calls could be of interest to > include here. > > Current list > ------------------------------------------------------------ > > > 14.1.2 > . > Additional Call Data Service Provider Type Registry > > > > +------------------------------+------------------------------------+ > | Name | Description | > +------------------------------+------------------------------------+ > |Access Infrastructure Provider| Access network service provider | > |Service Provider | Calling or Origination telecom SP | > |Service Provider Subcontractor| A contractor to another kind of SP | > |Telematics Provider | A sensor based SP, especially | > | | vehicle based | > |Relay Provider | A interpretation SP, for example, | > | | video relay for sign language | > | | interpretors | > |Other | Any other type of service provider | > +------------------------------+------------------------------------+ > > ------------------------------------- > Proposal with more types > > +------------------------------+------------------------------------+ > | Name | Description | > +------------------------------+------------------------------------+ > |Access Infrastructure Provider| Access network service provider | > |Application Service Provider | Calling or Origination telecom SP | > |Service Provider Subcontractor| A contractor to another kind of SP | > |Telematics Provider | A sensor based SP, especially | > | | vehicle based | > |Language translation Provider | A spoken language translation SP | > |Expert advice provider | An SP giving expert advice | > |Emergency Modality translation| An emergency call specific | > | | modality translation service | > | | e.g. for sign language | > |Relay Provider | A interpretation SP, for example, | > | | video relay for sign language | > | | interpreting | > |Other | Any other type of service provider | > +------------------------------+------------------------------------+ I personally think that the clarifications you added and the new types are good. We might need to change the Access Infrastructure Provider" to "Access Network Provider", as we did in the terminology section. I am also not sure why there is the "Service Provider Subcontractor" term. > > ----------------------------------- > I inserted the "Emergency Modality translation", because there is a > tendency in USA to not use the term "relay service" for cases when the > service is arranged specifically for > handling modality conversion in emergency call and when the PSAP can > participate in all media communication but need this extra service to > mediate the communication. Why wouldn't you call it "Emergency Modality Translator" instead? > > The expert advice provider is usually added in a bridge operation after > the original incoming call. But I can imagine that the additional-data > is of interest also for such situations Why wouldn't you use the term "Relay Provider"? > > For deciding on this, I think it would be good to have an idea of the > use of this information. Section 5.4 provides a little bit of information about how this data is used: How Used by Call Taker: To decide who to contact when further information is needed This is essentially meta-data about the entity that provides information. > > Will it be used for a review if a call was properly handled? If so, > maybe even more detail is needs, such as what kind of relay service was > invoked, so that it is possible to check if it was of a suitable kind. When you say "what kind of relay" what would you pass along? > > Or are such details provided in some other parameter? You have to check in the rest of the document. Since I don't know what other information you have in mind I do not really know whether it is already available. > > I think this should be checked with EENA and NENA to verify if more > needs in this area have been developed lately. Definitely. This work was initially developed in NENA and there were two groups working on this stuff. I am definitely planning to produce a tutorial for the emergency services authorities in Europe to provide some feedback. Letting them to review this draft is maybe not too useful since the information is too low-level. Ciao Hannes > > /Gunnar > > > > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From gunnar.hellstrom@omnitor.se Sun May 5 22:09:32 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE3F21F8CB4 for ; Sun, 5 May 2013 22:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3SU5HipqNpY for ; Sun, 5 May 2013 22:09:27 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 515A221F8B3A for ; Sun, 5 May 2013 22:09:25 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP; Mon, 6 May 2013 07:09:16 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id 4473E3A11C; Mon, 6 May 2013 07:09:16 +0200 (CEST) Message-ID: <51873AFC.5030707@omnitor.se> Date: Mon, 06 May 2013 07:09:16 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Hannes Tschofenig References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> <51816479.409@omnitor.se> <5186A025.10606@gmx.net> In-Reply-To: <5186A025.10606@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 05:09:32 -0000 On 2013-05-05 20:08, Hannes Tschofenig wrote: > Hi Gunnar, > > thanks for the feedback. > > Comments below. > > On 05/01/2013 09:52 PM, Gunnar Hellstrom wrote: >> Hannes, >> >> Looking at the contents of the list of different service providers, I >> wonder if there should be more types defined. >> It depends of course on what usage this information is expected to have. >> >> It seems that the various language translation and expert advice >> services that can be involved in emergency calls could be of interest to >> include here. >> >> Current list >> ------------------------------------------------------------ >> >> >> 14.1.2 >> . >> Additional Call Data Service Provider Type Registry >> >> >> >> +------------------------------+------------------------------------+ >> | Name | >> Description | >> +------------------------------+------------------------------------+ >> |Access Infrastructure Provider| Access network service >> provider | >> |Service Provider | Calling or Origination telecom >> SP | >> |Service Provider Subcontractor| A contractor to another kind of >> SP | >> |Telematics Provider | A sensor based SP, >> especially | >> | | vehicle >> based | >> |Relay Provider | A interpretation SP, for >> example, | >> | | video relay for sign >> language | >> | | >> interpretors | >> |Other | Any other type of service >> provider | >> +------------------------------+------------------------------------+ >> >> ------------------------------------- >> Proposal with more types >> >> +------------------------------+------------------------------------+ >> | Name | >> Description | >> +------------------------------+------------------------------------+ >> |Access Infrastructure Provider| Access network service >> provider | >> |Application Service Provider | Calling or Origination telecom >> SP | >> |Service Provider Subcontractor| A contractor to another kind of >> SP | >> |Telematics Provider | A sensor based SP, >> especially | >> | | vehicle >> based | >> |Language translation Provider | A spoken language translation >> SP | >> |Expert advice provider | An SP giving expert >> advice | >> |Emergency Modality translation| An emergency call >> specific | >> | | modality translation >> service | >> | | e.g. for sign >> language | >> |Relay Provider | A interpretation SP, for >> example, | >> | | video relay for sign >> language | >> | | >> interpreting | >> |Other | Any other type of service >> provider | >> +------------------------------+------------------------------------+ > > I personally think that the clarifications you added and the new types > are good. We might need to change the Access Infrastructure Provider" > to "Access Network Provider", as we did in the terminology section. Right > > I am also not sure why there is the "Service Provider Subcontractor" term. The draft seem to have some very specific thoughts embedded about that. I hope the original source can explain. > > >> >> ----------------------------------- >> I inserted the "Emergency Modality translation", because there is a >> tendency in USA to not use the term "relay service" for cases when the >> service is arranged specifically for >> handling modality conversion in emergency call and when the PSAP can >> participate in all media communication but need this extra service to >> mediate the communication. > > Why wouldn't you call it "Emergency Modality Translator" instead? Yes, maybe. The EAAC group of FCC has produced a report on this kind of services, Media Line Communication Services ( MCLS ) http://www.fcc.gov/document/eaac-mcls-report This is still advice from EAAC to FCC, and has not resulted in firm establishment of that term. > >> >> The expert advice provider is usually added in a bridge operation after >> the original incoming call. But I can imagine that the additional-data >> is of interest also for such situations > > Why wouldn't you use the term "Relay Provider"? In the discussion in the EAAC USA, it was clear that "relay service" was strictly seen as tied to a service that: 1. Isolates the user from the destination, by relaying the information between the two parties in the call. 2. Is brought into the call as a complement to the call application service provision ( the telecom call provider). 3. Is funded under specific regulation for funding such relaying related to phone calls. If translation, modality conversion of interpretation is brought into a call by another provider, or under other regulation not falling under the regulation for funding relay services, it should not be called a relay service. In corresponding discussions in Europe, we have not been that strict and are calling this type of service "relay service" whoever brought them into the call and even if they act as a complement in a call when the user and the emergency service also have direct media contact in all media provided in the call. So we have a mix of term usage here. > >> >> For deciding on this, I think it would be good to have an idea of the >> use of this information. > > Section 5.4 provides a little bit of information about how this data > is used: > > How Used by Call Taker: To decide who to contact when further > information is needed > > This is essentially meta-data about the entity that provides information. > >> >> Will it be used for a review if a call was properly handled? If so, >> maybe even more detail is needs, such as what kind of relay service was >> invoked, so that it is possible to check if it was of a suitable kind. > > When you say "what kind of relay" what would you pass along? > If there is value of detailing it, it should be in the types described by ETSI ES 202 975 Harmonized Relay Services http://www.etsi.org/deliver/etsi_es/202900_202999/202975/01.02.01_60/es_202975v010201p.pdf That is after the main modality they convert sign relay text relay speech relay lip-reading relay ( exists but rare ) and a special variant of text relay, called captioned telephony relay there should also be the sign-and-text relay using sign language one way and text the other. >> >> Or are such details provided in some other parameter? > > You have to check in the rest of the document. Since I don't know what > other information you have in mind I do not really know whether it is > already available. It was not. And the described intended use indicate that it could be of value to specify this detail, so that it is evident for the call taker what kind of support already is available in the call, when they judge uf any more supporting services are needed. > >> >> I think this should be checked with EENA and NENA to verify if more >> needs in this area have been developed lately. > > Definitely. This work was initially developed in NENA and there were > two groups working on this stuff. > > I am definitely planning to produce a tutorial for the emergency > services authorities in Europe to provide some feedback. Letting them > to review this draft is maybe not too useful since the information is > too low-level. > > Ciao > Hannes I suggest that you add also the service provider type: Emergency Service Provider. To be added by an Emergency Service if they decide to stay on the call, but invoke another emergency service also on the call. This may be of language support reasons in the way that EENA has set up a procedure for support of calls made in the "wrong" country in another language than the local language at the site of the emergency. It may also be of kind of expertize needed. Or, are there separate fields for that somewhere else? /Gunnar > >> >> /Gunnar >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > From gunnar.hellstrom@omnitor.se Sun May 5 22:09:36 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C318E21F8CF5 for ; Sun, 5 May 2013 22:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9YxOcrgNm+l for ; Sun, 5 May 2013 22:09:31 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 9A0C721F8B49 for ; Sun, 5 May 2013 22:09:30 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Mon, 6 May 2013 07:09:23 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id CEFA43A11C; Mon, 6 May 2013 07:09:22 +0200 (CEST) Message-ID: <51873B02.1060104@omnitor.se> Date: Mon, 06 May 2013 07:09:22 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Hannes Tschofenig References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> <51816479.409@omnitor.se> <5186A025.10606@gmx.net> In-Reply-To: <5186A025.10606@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 05:09:36 -0000 On 2013-05-05 20:08, Hannes Tschofenig wrote: > Hi Gunnar, > > thanks for the feedback. > > Comments below. > > On 05/01/2013 09:52 PM, Gunnar Hellstrom wrote: >> Hannes, >> >> Looking at the contents of the list of different service providers, I >> wonder if there should be more types defined. >> It depends of course on what usage this information is expected to have. >> >> It seems that the various language translation and expert advice >> services that can be involved in emergency calls could be of interest to >> include here. >> >> Current list >> ------------------------------------------------------------ >> >> >> 14.1.2 >> . >> Additional Call Data Service Provider Type Registry >> >> >> >> +------------------------------+------------------------------------+ >> | Name | >> Description | >> +------------------------------+------------------------------------+ >> |Access Infrastructure Provider| Access network service >> provider | >> |Service Provider | Calling or Origination telecom >> SP | >> |Service Provider Subcontractor| A contractor to another kind of >> SP | >> |Telematics Provider | A sensor based SP, >> especially | >> | | vehicle >> based | >> |Relay Provider | A interpretation SP, for >> example, | >> | | video relay for sign >> language | >> | | >> interpretors | >> |Other | Any other type of service >> provider | >> +------------------------------+------------------------------------+ >> >> ------------------------------------- >> Proposal with more types >> >> +------------------------------+------------------------------------+ >> | Name | >> Description | >> +------------------------------+------------------------------------+ >> |Access Infrastructure Provider| Access network service >> provider | >> |Application Service Provider | Calling or Origination telecom >> SP | >> |Service Provider Subcontractor| A contractor to another kind of >> SP | >> |Telematics Provider | A sensor based SP, >> especially | >> | | vehicle >> based | >> |Language translation Provider | A spoken language translation >> SP | >> |Expert advice provider | An SP giving expert >> advice | >> |Emergency Modality translation| An emergency call >> specific | >> | | modality translation >> service | >> | | e.g. for sign >> language | >> |Relay Provider | A interpretation SP, for >> example, | >> | | video relay for sign >> language | >> | | >> interpreting | >> |Other | Any other type of service >> provider | >> +------------------------------+------------------------------------+ > > I personally think that the clarifications you added and the new types > are good. We might need to change the Access Infrastructure Provider" > to "Access Network Provider", as we did in the terminology section. Right > > I am also not sure why there is the "Service Provider Subcontractor" term. The draft seem to have some very specific thoughts embedded about that. I hope the original source can explain. > > >> >> ----------------------------------- >> I inserted the "Emergency Modality translation", because there is a >> tendency in USA to not use the term "relay service" for cases when the >> service is arranged specifically for >> handling modality conversion in emergency call and when the PSAP can >> participate in all media communication but need this extra service to >> mediate the communication. > > Why wouldn't you call it "Emergency Modality Translator" instead? Yes, maybe. The EAAC group of FCC has produced a report on this kind of services, Media Line Communication Services ( MCLS ) http://www.fcc.gov/document/eaac-mcls-report This is still advice from EAAC to FCC, and has not resulted in firm establishment of that term. > >> >> The expert advice provider is usually added in a bridge operation after >> the original incoming call. But I can imagine that the additional-data >> is of interest also for such situations > > Why wouldn't you use the term "Relay Provider"? In the discussion in the EAAC USA, it was clear that "relay service" was strictly seen as tied to a service that: 1. Isolates the user from the destination, by relaying the information between the two parties in the call. 2. Is brought into the call as a complement to the call application service provision ( the telecom call provider). 3. Is funded under specific regulation for funding such relaying related to phone calls. If translation, modality conversion of interpretation is brought into a call by another provider, or under other regulation not falling under the regulation for funding relay services, it should not be called a relay service. In corresponding discussions in Europe, we have not been that strict and are calling this type of service "relay service" whoever brought them into the call and even if they act as a complement in a call when the user and the emergency service also have direct media contact in all media provided in the call. So we have a mix of term usage here. > >> >> For deciding on this, I think it would be good to have an idea of the >> use of this information. > > Section 5.4 provides a little bit of information about how this data > is used: > > How Used by Call Taker: To decide who to contact when further > information is needed > > This is essentially meta-data about the entity that provides information. > >> >> Will it be used for a review if a call was properly handled? If so, >> maybe even more detail is needs, such as what kind of relay service was >> invoked, so that it is possible to check if it was of a suitable kind. > > When you say "what kind of relay" what would you pass along? > If there is value of detailing it, it should be in the types described by ETSI ES 202 975 Harmonized Relay Services http://www.etsi.org/deliver/etsi_es/202900_202999/202975/01.02.01_60/es_202975v010201p.pdf That is after the main modality they convert sign relay text relay speech relay lip-reading relay ( exists but rare ) and a special variant of text relay, called captioned telephony relay there should also be the sign-and-text relay using sign language one way and text the other. >> >> Or are such details provided in some other parameter? > > You have to check in the rest of the document. Since I don't know what > other information you have in mind I do not really know whether it is > already available. It was not. And the described intended use indicate that it could be of value to specify this detail, so that it is evident for the call taker what kind of support already is available in the call, when they judge uf any more supporting services are needed. > >> >> I think this should be checked with EENA and NENA to verify if more >> needs in this area have been developed lately. > > Definitely. This work was initially developed in NENA and there were > two groups working on this stuff. > > I am definitely planning to produce a tutorial for the emergency > services authorities in Europe to provide some feedback. Letting them > to review this draft is maybe not too useful since the information is > too low-level. > > Ciao > Hannes I suggest that you add also the service provider type: Emergency Service Provider. To be added by an Emergency Service if they decide to stay on the call, but invoke another emergency service also on the call. This may be of language support reasons in the way that EENA has set up a procedure for support of calls made in the "wrong" country in another language than the local language at the site of the emergency. It may also be of kind of expertize needed. Or, are there separate fields for that somewhere else? /Gunnar > >> >> /Gunnar >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > From joke.bonte@ibz.fgov.be Mon May 6 00:26:58 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5293B21F84A9 for ; Mon, 6 May 2013 00:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vw8l+aORvLQF for ; Mon, 6 May 2013 00:26:54 -0700 (PDT) Received: from intsgsr03.ibz.fgov.be (intsgsr03.ibz.fgov.be [193.191.220.222]) by ietfa.amsl.com (Postfix) with ESMTP id A0F1C21F84D1 for ; Mon, 6 May 2013 00:26:51 -0700 (PDT) Received: from INTSGSR68B.mibz.fgov.be ([172.20.0.210]) by intsgsr03.ibz.fgov.be with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 May 2013 09:26:49 +0200 Received: from INTGLEXC03.mibz.fgov.be ([fe80::dc3c:16dd:70e8:c62]) by INTSGSR68B.mibz.fgov.be ([::1]) with mapi; Mon, 6 May 2013 09:26:49 +0200 From: Bonte Joke To: "ecrit@ietf.org" Date: Mon, 6 May 2013 09:26:46 +0200 Thread-Topic: Ecrit Digest, Vol 100, Issue 5 Thread-Index: Ac5Jwtdyp4bN2dkeTS+sfyNte4rgLQAaDl5A Message-ID: References: In-Reply-To: Accept-Language: nl-NL, fr-BE Content-Language: nl-BE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, fr-BE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 May 2013 07:26:49.0323 (UTC) FILETIME=[1268CBB0:01CE4A2B] Subject: Re: [Ecrit] Ecrit Digest, Vol 100, Issue 5 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 07:26:58 -0000 Bonte Joke Attach=E9 Project 112 T 02 500 22 57 G 0479 900897 F 02 500 23 61 joke.bonte@ibz.fgov.be FOD Binnenlandse Zaken | SPF Int=E9rieur Algemene Directie Civiele Veiligheid =95 Direction g=E9n=E9rale de la S=E9c= urit=E9 Civile Project Team 112 Leuvense weg 3 =95 Rue de louvain 3 1000 Brussel =95 Bruxelles ________________________________________ Van: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] namens ecrit-request@i= etf.org [ecrit-request@ietf.org] Verzonden: zondag 5 mei 2013 21:00 Aan: ecrit@ietf.org Onderwerp: Ecrit Digest, Vol 100, Issue 5 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/ecrit Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send Ecrit mailing list submissions to ecrit@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/ecrit or, via email, send a message with subject or body 'help' to ecrit-request@ietf.org You can reach the person managing the list at ecrit-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Ecrit digest..." Today's Topics: 1. I-D Action: draft-ietf-ecrit-additional-data-08.txt (internet-drafts@ietf.org) 2. Additional Data: Version -08 (Hannes Tschofenig) 3. Re: draft-ietf-ecrit-additional-data-07 (Hannes Tschofenig) ---------------------------------------------------------------------- Message: 1 Date: Sun, 05 May 2013 04:16:46 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-08.txt Message-ID: <20130505111646.23978.4269.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=3D"utf-8" A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Randall Gellens Filename : draft-ietf-ecrit-additional-data-08.txt Pages : 81 Date : 2013-05-05 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any application service provider in the path of the call, or access network provider through which the call originated may have information about the call or the caller which the PSAP may be able to use. This document describes data structures to convey such data to the PSAP. In addition, data may also be included by reference, via a Uniform Resource Identifier (URI) pointing to data found at an external resource. Consequently, this document follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in body of the SIP message) and also by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ------------------------------ Message: 2 Date: Sun, 05 May 2013 14:29:57 +0300 From: Hannes Tschofenig To: "ecrit@ietf.org" Subject: [Ecrit] Additional Data: Version -08 Message-ID: <518642B5.7090700@gmx.net> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Hi all, I just posted an interim update (as version -08) for the additional data draft. It captures some of the discussions we had on the mailing list recently but it is not a complete update yet since there are a number of other issues that need to be addressed. Here is the updated version: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data From the diff you can see that I * updated the introduction, * added terminology (related to the discussion about service provider), * updated the XML schemas, * included extension points to the schemas, * added more examples (which have been validated against the schemas), * added the vCard/xCard XML schema, * fixed various bugs, and * updated references Ciao Hannes ------------------------------ Message: 3 Date: Sun, 05 May 2013 21:08:37 +0300 From: Hannes Tschofenig To: Gunnar Hellstrom Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 Message-ID: <5186A025.10606@gmx.net> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Hi Gunnar, thanks for the feedback. Comments below. On 05/01/2013 09:52 PM, Gunnar Hellstrom wrote: > Hannes, > > Looking at the contents of the list of different service providers, I > wonder if there should be more types defined. > It depends of course on what usage this information is expected to have. > > It seems that the various language translation and expert advice > services that can be involved in emergency calls could be of interest to > include here. > > Current list > ------------------------------------------------------------ > > > 14.1.2 > . > Additional Call Data Service Provider Type Registry > > > > +------------------------------+------------------------------------+ > | Name | Description | > +------------------------------+------------------------------------+ > |Access Infrastructure Provider| Access network service provider | > |Service Provider | Calling or Origination telecom SP | > |Service Provider Subcontractor| A contractor to another kind of SP | > |Telematics Provider | A sensor based SP, especially | > | | vehicle based | > |Relay Provider | A interpretation SP, for example, | > | | video relay for sign language | > | | interpretors | > |Other | Any other type of service provider | > +------------------------------+------------------------------------+ > > ------------------------------------- > Proposal with more types > > +------------------------------+------------------------------------+ > | Name | Description | > +------------------------------+------------------------------------+ > |Access Infrastructure Provider| Access network service provider | > |Application Service Provider | Calling or Origination telecom SP | > |Service Provider Subcontractor| A contractor to another kind of SP | > |Telematics Provider | A sensor based SP, especially | > | | vehicle based | > |Language translation Provider | A spoken language translation SP | > |Expert advice provider | An SP giving expert advice | > |Emergency Modality translation| An emergency call specific | > | | modality translation service | > | | e.g. for sign language | > |Relay Provider | A interpretation SP, for example, | > | | video relay for sign language | > | | interpreting = | > |Other | Any other type of service provider | > +------------------------------+------------------------------------+ I personally think that the clarifications you added and the new types are good. We might need to change the Access Infrastructure Provider" to "Access Network Provider", as we did in the terminology section. I am also not sure why there is the "Service Provider Subcontractor" term. > > ----------------------------------- > I inserted the "Emergency Modality translation", because there is a > tendency in USA to not use the term "relay service" for cases when the > service is arranged specifically for > handling modality conversion in emergency call and when the PSAP can > participate in all media communication but need this extra service to > mediate the communication. Why wouldn't you call it "Emergency Modality Translator" instead? > > The expert advice provider is usually added in a bridge operation after > the original incoming call. But I can imagine that the additional-data > is of interest also for such situations Why wouldn't you use the term "Relay Provider"? > > For deciding on this, I think it would be good to have an idea of the > use of this information. Section 5.4 provides a little bit of information about how this data is used: How Used by Call Taker: To decide who to contact when further information is needed This is essentially meta-data about the entity that provides information. > > Will it be used for a review if a call was properly handled? If so, > maybe even more detail is needs, such as what kind of relay service was > invoked, so that it is possible to check if it was of a suitable kind. When you say "what kind of relay" what would you pass along? > > Or are such details provided in some other parameter? You have to check in the rest of the document. Since I don't know what other information you have in mind I do not really know whether it is already available. > > I think this should be checked with EENA and NENA to verify if more > needs in this area have been developed lately. Definitely. This work was initially developed in NENA and there were two groups working on this stuff. I am definitely planning to produce a tutorial for the emergency services authorities in Europe to provide some feedback. Letting them to review this draft is maybe not too useful since the information is too low-level. Ciao Hannes > > /Gunnar > > > > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > ------------------------------ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit End of Ecrit Digest, Vol 100, Issue 5 ************************************* From pkyzivat@alum.mit.edu Thu May 9 20:07:29 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFC021F8F4D for ; Thu, 9 May 2013 20:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.041 X-Spam-Level: X-Spam-Status: No, score=-0.041 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCOM1ZcVGfDB for ; Thu, 9 May 2013 20:07:23 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 1303221F8FA1 for ; Thu, 9 May 2013 20:07:22 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id ZskS1l0011GhbT85337NuT; Fri, 10 May 2013 03:07:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id a37N1l00S3ZTu2S3T37N9w; Fri, 10 May 2013 03:07:22 +0000 Message-ID: <518C6469.9090307@alum.mit.edu> Date: Thu, 09 May 2013 23:07:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ecrit@ietf.org References: <518642B5.7090700@gmx.net> In-Reply-To: <518642B5.7090700@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368155242; bh=7LZELDa6gnUjuc/tgjrQy95McCigT+1lz04oQ0E5cpg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JV73luXWE42mqLZ4SoGCHbq3CO2OfI529YiBTBIflK70tjcyiE5QVm/tbfzH3Gawr kWen5rEdUUL1iXOeX0jeO9RMbElGfNhfPFMS1My8hduhNL4/jICBqmuTLP80gE+Kqo NM3PLk0IHx5AT+4KuBOehwzKOBDv0cFiio+ClTHWVWKnz71wI4W7D0XcqQrugjQeNa DNIsqJVDRngPVMdkDjKf9bW3+Sr/H+fwesl9nkRdMOfLAJvSgHz2uLam2AlrEvUNA0 LICiA0HvAHGT5RM345c313bw7Fa14c1BTTW/HFtQ23nGD4/cU9XxQJYBDB5r8Tp59g Em/DAdbJ/AtkQ== Subject: Re: [Ecrit] Additional Data: Version -08 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 03:07:29 -0000 I haven't looked at this for several versions, so this comment is not specific to this version... I see no mention of use of Content-Disposition in this draft. It really ought to talk about that and show it in examples. Take a look at RFC5621 for issues to consider. A couple of main points: - In cases where the data is in the message and referenced from Call-Info, the Content-Disposition should be 'by-reference'. - Think carefully about how you want to set the handling parameter. Thanks, Paul On 5/5/13 7:29 AM, Hannes Tschofenig wrote: > Hi all, > > I just posted an interim update (as version -08) for the additional data > draft. It captures some of the discussions we had on the mailing list > recently but it is not a complete update yet since there are a number of > other issues that need to be addressed. > > Here is the updated version: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data > > From the diff you can see that I > * updated the introduction, > * added terminology (related to the discussion about service provider), > * updated the XML schemas, > * included extension points to the schemas, > * added more examples (which have been validated against the schemas), > * added the vCard/xCard XML schema, > * fixed various bugs, and > * updated references > > Ciao > Hannes > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From br@brianrosen.net Fri May 10 06:35:30 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED08F21F8D0B for ; Fri, 10 May 2013 06:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8xPGVZuWP9s for ; Fri, 10 May 2013 06:35:26 -0700 (PDT) Received: from mm2.idig.net (raphotoclub.ca [70.33.247.99]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE7F21F8B9C for ; Fri, 10 May 2013 06:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=l/QSlAXPlT6B1Opf20UXzASV6pMfDprTpoyY15svNmg=; b=FhqCdJQ2k3rsUzSJL+Tj/VoqIe2cL0IZao0vJSNZmIADyV/jhxX6HtToqfniyjnHxoy9XHJ7W0jmSvoaTc0X1gGcEN0nyEkdboVyLaMeh3V1xcfpTmirgiw9BnluEbeUFaHlLn7GL/Nhry4ndJe9VNvNayRwXS4HKIa7DfVYFQ8=; Received: from neustargw.va.neustar.com ([209.173.53.233]:32318 helo=[10.33.192.37]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UanTo-0006Py-Jl; Fri, 10 May 2013 09:35:24 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <518C6469.9090307@alum.mit.edu> Date: Fri, 10 May 2013 09:35:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <518642B5.7090700@gmx.net> <518C6469.9090307@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: Version -08 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 13:35:31 -0000 Yeah, we definitely want 'by-reference' for Content-Disposition Usually, I would expect to see the handling parameter for the = multipart/mixed be 'optional', but that's because I'm only thinking that = we might see SDP,] location and and additional-data parts and nothing = else. But who knows what might happen in the future. But what about the additional-data part itself? 'render' is probably = okay. Is there something better? Brian On May 9, 2013, at 11:07 PM, Paul Kyzivat wrote: > I haven't looked at this for several versions, so this comment is not = specific to this version... >=20 > I see no mention of use of Content-Disposition in this draft. > It really ought to talk about that and show it in examples. > Take a look at RFC5621 for issues to consider. A couple of main = points: >=20 > - In cases where the data is in the message and referenced from = Call-Info, the Content-Disposition should be 'by-reference'. >=20 > - Think carefully about how you want to set the handling parameter. >=20 > Thanks, > Paul >=20 > On 5/5/13 7:29 AM, Hannes Tschofenig wrote: >> Hi all, >>=20 >> I just posted an interim update (as version -08) for the additional = data >> draft. It captures some of the discussions we had on the mailing list >> recently but it is not a complete update yet since there are a number = of >> other issues that need to be addressed. >>=20 >> Here is the updated version: >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data >>=20 >> =46rom the diff you can see that I >> * updated the introduction, >> * added terminology (related to the discussion about service = provider), >> * updated the XML schemas, >> * included extension points to the schemas, >> * added more examples (which have been validated against the = schemas), >> * added the vCard/xCard XML schema, >> * fixed various bugs, and >> * updated references >>=20 >> Ciao >> Hannes >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Fri May 10 13:11:04 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9551B21F8709 for ; Fri, 10 May 2013 13:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.075 X-Spam-Level: X-Spam-Status: No, score=-0.075 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xB4VCuxRA4Po for ; Fri, 10 May 2013 13:11:00 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id BD55521F8721 for ; Fri, 10 May 2013 13:10:59 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id aCuS1l00C0xGWP853LAzsY; Fri, 10 May 2013 20:10:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id aLAy1l01F3ZTu2S3YLAyX0; Fri, 10 May 2013 20:10:59 +0000 Message-ID: <518D5452.6010202@alum.mit.edu> Date: Fri, 10 May 2013 16:10:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Brian Rosen References: <518642B5.7090700@gmx.net> <518C6469.9090307@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368216659; bh=t6RNxpyQUw6CaferSoWudL2YKuQ9YGJZKnNHmTOoAHg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fVXNysy5Ol78/zoEFO0UZo2Y43p9NfI7C92VMueRLTkETp67p1g3+o282hQuHgbfj Fkn1f35wdcHKjzkHj4j3s/OoPv+ra3oKKCNSpMAw/3WL5eIPbkEKd6kJ3GksflnbZ4 cQOe4dhnhHNZ5kGatwB/+46DIXBJI43MSzOWmkt/MUQjqadRYAlLw3sbgsaliWCA2L cY+hiySX/GZz1YCilJkVhwDuViJPZHZivRYDeadm5u5HvhT+jrfDixv7BYva298F1v ghyVAZ9JaXHz5ga26+xogicLnRf+k/Ro8zT221GrEIJRswFFK31tHXrKwlmy1w5rkv hFhUXhcQNoHvw== Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: Version -08 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 20:11:04 -0000 On 5/10/13 9:35 AM, Brian Rosen wrote: > Yeah, we definitely want 'by-reference' for Content-Disposition > > Usually, I would expect to see the handling parameter for the multipart/mixed be 'optional', but that's because I'm only thinking that we might see SDP,] location and and additional-data parts and nothing else. But who knows what might happen in the future. If what you have is a multipart/mixed containing SDP and additional-data, then it is essential that the SDP be processed. To ensure that the multipart/mixed must be 'required'. Then the SDP can be 'required' and the additional-data 'optional'. Even RFC5621 neglected to specify what the Content-Disposition value should be for multipart bodies. By default it is 'render' which doesn't make a lot of sense. But I think we consider it grandfathered. Its also the default (for everything except SDP), and 'required' is also default, so you can omit Content-Disposition in those cases. But if you want the entire multipart to be optional then you will need to specify Content-Disposition:render;handling=optional > But what about the additional-data part itself? 'render' is probably okay. Is there something better? That is the one that should be 'by-reference'. That means that what to do with it is determined by the reference. In your case, that is the Call-info:...purpose=emergencyCallData... So I think the example in Section 10 should be: INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 Max-Forwards: 70 To: Bob From: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Call-Info: ;purpose=icon, ;purpose=info, ;purpose=emergencyCallData.ProviderInfo Geolocation: Geolocation-Routing: no Accept: application/sdp, application/pidf+xml, application/emergencyCallProviderinfo+xml CSeq: 31862 INVITE Contact: Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... --boundary1 Content-Type: application/sdp ... can omit Content-Disposition because defaults are ok ...SDP goes here --boundary1 Content-Type: application/pidf+xml Content-ID: Content-Disposition: by-reference;handling=optional \0x2026PIDF-LO goes here --boundary1-- Content-Type: application/emergencyCall.ProviderInfo+xml Content-ID: <1234567890@atlanta.example.com> Content-Disposition: by-reference;handling=optional ...Additional Data goes here --boundary1-- > Brian > > On May 9, 2013, at 11:07 PM, Paul Kyzivat wrote: > >> I haven't looked at this for several versions, so this comment is not specific to this version... >> >> I see no mention of use of Content-Disposition in this draft. >> It really ought to talk about that and show it in examples. >> Take a look at RFC5621 for issues to consider. A couple of main points: >> >> - In cases where the data is in the message and referenced from Call-Info, the Content-Disposition should be 'by-reference'. >> >> - Think carefully about how you want to set the handling parameter. >> >> Thanks, >> Paul >> >> On 5/5/13 7:29 AM, Hannes Tschofenig wrote: >>> Hi all, >>> >>> I just posted an interim update (as version -08) for the additional data >>> draft. It captures some of the discussions we had on the mailing list >>> recently but it is not a complete update yet since there are a number of >>> other issues that need to be addressed. >>> >>> Here is the updated version: >>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data >>> >>> From the diff you can see that I >>> * updated the introduction, >>> * added terminology (related to the discussion about service provider), >>> * updated the XML schemas, >>> * included extension points to the schemas, >>> * added more examples (which have been validated against the schemas), >>> * added the vCard/xCard XML schema, >>> * fixed various bugs, and >>> * updated references >>> >>> Ciao >>> Hannes >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From hannes.tschofenig@gmx.net Sun May 12 10:19:36 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0415D21F87B1 for ; Sun, 12 May 2013 10:19:36 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIlIbITpEDFr for ; Sun, 12 May 2013 10:19:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id EA8B821F87B7 for ; Sun, 12 May 2013 10:19:30 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M1Tap-1UHI1g3BiD-00tVFV for ; Sun, 12 May 2013 19:19:29 +0200 Received: (qmail invoked by alias); 12 May 2013 17:19:29 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp034) with SMTP; 12 May 2013 19:19:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/qTN19NNbqkKKtbc5PTIX3MugpJyXZMBCcor666u 8wqhfM68M/wJF6 Message-ID: <518FCF1B.8040503@gmx.net> Date: Sun, 12 May 2013 20:19:23 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Paul Kyzivat References: <518642B5.7090700@gmx.net> <518C6469.9090307@alum.mit.edu> <518D5452.6010202@alum.mit.edu> In-Reply-To: <518D5452.6010202@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: Version -08 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 17:19:36 -0000 Hi Paul, Hi Brian, I am OK to add the Content-Disposition line to the example but I am wondering how much value it adds. I have just been looking at RFC 6442 ("SIP Location Conveyance") and we don't use Content-Disposition there either. From a high-level point of view I don't think that the additional data document is much different from adding location to the body of the SIP message and to have a reference in the header. Ciao Hannes On 05/10/2013 11:10 PM, Paul Kyzivat wrote: > On 5/10/13 9:35 AM, Brian Rosen wrote: >> Yeah, we definitely want 'by-reference' for Content-Disposition >> >> Usually, I would expect to see the handling parameter for the >> multipart/mixed be 'optional', but that's because I'm only thinking >> that we might see SDP,] location and and additional-data parts and >> nothing else. But who knows what might happen in the future. > > If what you have is a multipart/mixed containing SDP and > additional-data, then it is essential that the SDP be processed. To > ensure that the multipart/mixed must be 'required'. Then the SDP can be > 'required' and the additional-data 'optional'. > > Even RFC5621 neglected to specify what the Content-Disposition value > should be for multipart bodies. By default it is 'render' which doesn't > make a lot of sense. But I think we consider it grandfathered. Its also > the default (for everything except SDP), and 'required' is also default, > so you can omit Content-Disposition in those cases. But if you want the > entire multipart to be optional then you will need to specify > Content-Disposition:render;handling=optional > >> But what about the additional-data part itself? 'render' is probably >> okay. Is there something better? > > That is the one that should be 'by-reference'. That means that what to > do with it is determined by the reference. In your case, that is the > Call-info:...purpose=emergencyCallData... > > So I think the example in Section 10 should be: > > INVITE sips:bob@biloxi.example.com SIP/2.0 > Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 > Max-Forwards: 70 > To: Bob > From: Alice ;tag=9fxced76sl > Call-ID: 3848276298220188511@atlanta.example.com > Call-Info: > ;purpose=icon, > ;purpose=info, > > ;purpose=emergencyCallData.ProviderInfo > Geolocation: > Geolocation-Routing: no > Accept: application/sdp, application/pidf+xml, > application/emergencyCallProviderinfo+xml > CSeq: 31862 INVITE > Contact: > Content-Type: multipart/mixed; boundary=boundary1 > > Content-Length: ... > > --boundary1 > > Content-Type: application/sdp > > ... can omit Content-Disposition because defaults are ok > ...SDP goes here > > --boundary1 > > Content-Type: application/pidf+xml > Content-ID: > Content-Disposition: by-reference;handling=optional > > \0x2026PIDF-LO goes here > > --boundary1-- > > Content-Type: application/emergencyCall.ProviderInfo+xml > Content-ID: <1234567890@atlanta.example.com> > Content-Disposition: by-reference;handling=optional > > ...Additional Data goes here > > --boundary1-- > > > >> Brian >> >> On May 9, 2013, at 11:07 PM, Paul Kyzivat wrote: >> >>> I haven't looked at this for several versions, so this comment is not >>> specific to this version... >>> >>> I see no mention of use of Content-Disposition in this draft. >>> It really ought to talk about that and show it in examples. >>> Take a look at RFC5621 for issues to consider. A couple of main points: >>> >>> - In cases where the data is in the message and referenced from >>> Call-Info, the Content-Disposition should be 'by-reference'. >>> >>> - Think carefully about how you want to set the handling parameter. >>> >>> Thanks, >>> Paul >>> >>> On 5/5/13 7:29 AM, Hannes Tschofenig wrote: >>>> Hi all, >>>> >>>> I just posted an interim update (as version -08) for the additional >>>> data >>>> draft. It captures some of the discussions we had on the mailing list >>>> recently but it is not a complete update yet since there are a >>>> number of >>>> other issues that need to be addressed. >>>> >>>> Here is the updated version: >>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data >>>> >>>> From the diff you can see that I >>>> * updated the introduction, >>>> * added terminology (related to the discussion about service provider), >>>> * updated the XML schemas, >>>> * included extension points to the schemas, >>>> * added more examples (which have been validated against the schemas), >>>> * added the vCard/xCard XML schema, >>>> * fixed various bugs, and >>>> * updated references >>>> >>>> Ciao >>>> Hannes >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Sun May 12 17:14:51 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333EB21F8AD1 for ; Sun, 12 May 2013 17:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBgm9riWG0-d for ; Sun, 12 May 2013 17:14:46 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id ED8BF21F8AA6 for ; Sun, 12 May 2013 17:14:45 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta15.westchester.pa.mail.comcast.net with comcast id bBEb1l0031ap0As5FCEkD1; Mon, 13 May 2013 00:14:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id bCEj1l01Y3ZTu2S3iCEk4w; Mon, 13 May 2013 00:14:44 +0000 Message-ID: <51903073.8020807@alum.mit.edu> Date: Sun, 12 May 2013 20:14:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Hannes Tschofenig References: <518642B5.7090700@gmx.net> <518C6469.9090307@alum.mit.edu> <518D5452.6010202@alum.mit.edu> <518FCF1B.8040503@gmx.net> In-Reply-To: <518FCF1B.8040503@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368404084; bh=WSzyEgoC4y6mMBHvfjJMaAVtIJiOB3z+E2IxvyvVUy8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Giuk9PyZZxNFkM04HqqNudzCVefHPF/FYz1+L3OEXXqLdY4UkM7p3CbbyLiJzPvPS ahzILC/KEDR0sBav6ECqGQMTnPE8QfDCZyqnBg0t0epabRA3dEI460mYjlWr36Iujx plxIsvVDP33GC9K7GBCSsPRKpTiSzd6aekGxRQNIv41zwjPAYaQRpfz4y4C+XjXpb/ ahR9qa/dnwAu32dfcCbZdFOEQkbS23E8BVv36L+uS/6kH8lMjZ8aezzVHbwK42qv8r PvpJtOLb9akqPtPKRBE0bch3pLDUPJs6ePQJfdptsRTd2KehUiuswl+KQXfUQT8Toh FeDlG8wWgoLMQ== Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: Version -08 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 00:14:51 -0000 On 5/12/13 1:19 PM, Hannes Tschofenig wrote: > Hi Paul, Hi Brian, > > I am OK to add the Content-Disposition line to the example but I am > wondering how much value it adds. I have just been looking at RFC 6442 > ("SIP Location Conveyance") and we don't use Content-Disposition there > either. From a high-level point of view I don't think that the > additional data document is much different from adding location to the > body of the SIP message and to have a reference in the header. It should have been used there too. I'm sorry I didn't catch that. The problem is that without it the rules for how to process multipart bodies are ambiguous and ad hoc. In the past there was very little use of that, and we have been getting by with ad hoc. But as more complex usages come up (and they are) it gets harder and harder to do the right thing that way. Thanks, Paul > Ciao > Hannes > > On 05/10/2013 11:10 PM, Paul Kyzivat wrote: >> On 5/10/13 9:35 AM, Brian Rosen wrote: >>> Yeah, we definitely want 'by-reference' for Content-Disposition >>> >>> Usually, I would expect to see the handling parameter for the >>> multipart/mixed be 'optional', but that's because I'm only thinking >>> that we might see SDP,] location and and additional-data parts and >>> nothing else. But who knows what might happen in the future. >> >> If what you have is a multipart/mixed containing SDP and >> additional-data, then it is essential that the SDP be processed. To >> ensure that the multipart/mixed must be 'required'. Then the SDP can be >> 'required' and the additional-data 'optional'. >> >> Even RFC5621 neglected to specify what the Content-Disposition value >> should be for multipart bodies. By default it is 'render' which doesn't >> make a lot of sense. But I think we consider it grandfathered. Its also >> the default (for everything except SDP), and 'required' is also default, >> so you can omit Content-Disposition in those cases. But if you want the >> entire multipart to be optional then you will need to specify >> Content-Disposition:render;handling=optional >> >>> But what about the additional-data part itself? 'render' is probably >>> okay. Is there something better? >> >> That is the one that should be 'by-reference'. That means that what to >> do with it is determined by the reference. In your case, that is the >> Call-info:...purpose=emergencyCallData... >> >> So I think the example in Section 10 should be: >> >> INVITE sips:bob@biloxi.example.com SIP/2.0 >> Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 >> Max-Forwards: 70 >> To: Bob >> From: Alice ;tag=9fxced76sl >> Call-ID: 3848276298220188511@atlanta.example.com >> Call-Info: >> ;purpose=icon, >> ;purpose=info, >> >> ;purpose=emergencyCallData.ProviderInfo >> Geolocation: >> Geolocation-Routing: no >> Accept: application/sdp, application/pidf+xml, >> application/emergencyCallProviderinfo+xml >> CSeq: 31862 INVITE >> Contact: >> Content-Type: multipart/mixed; boundary=boundary1 >> >> Content-Length: ... >> >> --boundary1 >> >> Content-Type: application/sdp >> >> ... can omit Content-Disposition because defaults are ok >> ...SDP goes here >> >> --boundary1 >> >> Content-Type: application/pidf+xml >> Content-ID: >> Content-Disposition: by-reference;handling=optional >> >> \0x2026PIDF-LO goes here >> >> --boundary1-- >> >> Content-Type: application/emergencyCall.ProviderInfo+xml >> Content-ID: <1234567890@atlanta.example.com> >> Content-Disposition: by-reference;handling=optional >> >> ...Additional Data goes here >> >> --boundary1-- >> >> >> >>> Brian >>> >>> On May 9, 2013, at 11:07 PM, Paul Kyzivat wrote: >>> >>>> I haven't looked at this for several versions, so this comment is not >>>> specific to this version... >>>> >>>> I see no mention of use of Content-Disposition in this draft. >>>> It really ought to talk about that and show it in examples. >>>> Take a look at RFC5621 for issues to consider. A couple of main points: >>>> >>>> - In cases where the data is in the message and referenced from >>>> Call-Info, the Content-Disposition should be 'by-reference'. >>>> >>>> - Think carefully about how you want to set the handling parameter. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 5/5/13 7:29 AM, Hannes Tschofenig wrote: >>>>> Hi all, >>>>> >>>>> I just posted an interim update (as version -08) for the additional >>>>> data >>>>> draft. It captures some of the discussions we had on the mailing list >>>>> recently but it is not a complete update yet since there are a >>>>> number of >>>>> other issues that need to be addressed. >>>>> >>>>> Here is the updated version: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data >>>>> >>>>> From the diff you can see that I >>>>> * updated the introduction, >>>>> * added terminology (related to the discussion about service >>>>> provider), >>>>> * updated the XML schemas, >>>>> * included extension points to the schemas, >>>>> * added more examples (which have been validated against the schemas), >>>>> * added the vCard/xCard XML schema, >>>>> * fixed various bugs, and >>>>> * updated references >>>>> >>>>> Ciao >>>>> Hannes >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From hannes.tschofenig@gmx.net Mon May 13 01:19:03 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96DB21F8FDB for ; Mon, 13 May 2013 01:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.212 X-Spam-Level: X-Spam-Status: No, score=-100.212 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaWSKxZgYp1E for ; Mon, 13 May 2013 01:18:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3990C21F8FDF for ; Mon, 13 May 2013 01:18:58 -0700 (PDT) Received: from 3capp-gmx-bs52.server.lan ([172.19.170.105]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MWvJi-1UyxWD1f3U-00W0Um; Mon, 13 May 2013 10:18:53 +0200 Received: from [194.251.119.197] by 3capp-gmx-bs52.server.lan with HTTP; Mon May 13 10:18:53 CEST 2013 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: "Paul Kyzivat" Content-Type: text/html; charset=UTF-8 Date: Mon, 13 May 2013 10:18:53 +0200 (CEST) Importance: normal Sensitivity: Normal In-Reply-To: <51903073.8020807@alum.mit.edu> References: <518642B5.7090700@gmx.net> <518C6469.9090307@alum.mit.edu> <518D5452.6010202@alum.mit.edu> <518FCF1B.8040503@gmx.net>, <51903073.8020807@alum.mit.edu> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:50B4+f/BULgl8MpmlQW9VVZoSgjeH2KDQ55iw65eU3W i76pqqFEwuwcN6YsXgHTaIDk2edDUMD4c+Dpozfbil+WZi8X59 Bjkm7UmXSNfwkiuBSp5evnm2mhBKKaRiod3Hk65LbgXqitWWTC 3vTiSSEVrUepGl/QZVtMZbOX24SIYylSIM2bd733eOeWE6/+uP 6DbLmm39MdeLwUEsWRF4Ii1EdAWrh1NlBmD8t4lYdWMVRDOSjw sI3lwXs+K4/w+gsxrsd6q5y7S/rCOZVK6POm8iB9EsXfS6b0pD ApT22w= Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: Version -08 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 08:19:04 -0000
It is obviously not a huge addition to add this line
" 
Content-Disposition: by-reference;handling=optional
"
to the payloads. 
 
So, if there is some value in doing that I am fine with it. 
 
 
Gesendet: Montag, 13. Mai 2013 um 02:14 Uhr
Von: "Paul Kyzivat" <pkyzivat@alum.mit.edu>
An: "Hannes Tschofenig" <hannes.tschofenig@gmx.net>
Cc: "Brian Rosen" <br@brianrosen.net>, ecrit@ietf.org
Betreff: Re: [Ecrit] Additional Data: Version -08


On 5/12/13 1:19 PM, Hannes Tschofenig wrote:
> Hi Paul, Hi Brian,
>
> I am OK to add the Content-Disposition line to the example but I am
> wondering how much value it adds. I have just been looking at RFC 6442
> ("SIP Location Conveyance") and we don't use Content-Disposition there
> either. From a high-level point of view I don't think that the
> additional data document is much different from adding location to the
> body of the SIP message and to have a reference in the header.

It should have been used there too. I'm sorry I didn't catch that.

The problem is that without it the rules for how to process multipart
bodies are ambiguous and ad hoc. In the past there was very little use
of that, and we have been getting by with ad hoc. But as more complex
usages come up (and they are) it gets harder and harder to do the right
thing that way.

Thanks,
Paul

> Ciao
> Hannes
>
> On 05/10/2013 11:10 PM, Paul Kyzivat wrote:
>> On 5/10/13 9:35 AM, Brian Rosen wrote:
>>> Yeah, we definitely want 'by-reference' for Content-Disposition
>>>
>>> Usually, I would expect to see the handling parameter for the
>>> multipart/mixed be 'optional', but that's because I'm only thinking
>>> that we might see SDP,] location and and additional-data parts and
>>> nothing else. But who knows what might happen in the future.
>>
>> If what you have is a multipart/mixed containing SDP and
>> additional-data, then it is essential that the SDP be processed. To
>> ensure that the multipart/mixed must be 'required'. Then the SDP can be
>> 'required' and the additional-data 'optional'.
>>
>> Even RFC5621 neglected to specify what the Content-Disposition value
>> should be for multipart bodies. By default it is 'render' which doesn't
>> make a lot of sense. But I think we consider it grandfathered. Its also
>> the default (for everything except SDP), and 'required' is also default,
>> so you can omit Content-Disposition in those cases. But if you want the
>> entire multipart to be optional then you will need to specify
>> Content-Disposition:render;handling=optional
>>
>>> But what about the additional-data part itself? 'render' is probably
>>> okay. Is there something better?
>>
>> That is the one that should be 'by-reference'. That means that what to
>> do with it is determined by the reference. In your case, that is the
>> Call-info:...purpose=emergencyCallData...
>>
>> So I think the example in Section 10 should be:
>>
>> INVITE sips:bob@biloxi.example.com SIP/2.0
>> Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
>> Max-Forwards: 70
>> To: Bob <sips:bob@biloxi.example.com>
>> From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
>> Call-ID: 3848276298220188511@atlanta.example.com
>> Call-Info: <http://wwww.example.com/alice/photo.jpg>
>> ;purpose=icon,
>> <http://www.example.com/alice/> ;purpose=info,
>> <cid:1234567890@atlanta.example.com>
>> ;purpose=emergencyCallData.ProviderInfo
>> Geolocation: <cid:target123@atlanta.example.com>
>> Geolocation-Routing: no
>> Accept: application/sdp, application/pidf+xml,
>> application/emergencyCallProviderinfo+xml
>> CSeq: 31862 INVITE
>> Contact: <sips:alice@atlanta.example.com>
>> Content-Type: multipart/mixed; boundary=boundary1
>>
>> Content-Length: ...
>>
>> --boundary1
>>
>> Content-Type: application/sdp
>>
>> ... can omit Content-Disposition because defaults are ok
>> ...SDP goes here
>>
>> --boundary1
>>
>> Content-Type: application/pidf+xml
>> Content-ID: <target123@atlanta.example.com>
>> Content-Disposition: by-reference;handling=optional
>>
>> \0x2026PIDF-LO goes here
>>
>> --boundary1--
>>
>> Content-Type: application/emergencyCall.ProviderInfo+xml
>> Content-ID: <1234567890@atlanta.example.com>
>> Content-Disposition: by-reference;handling=optional
>>
>> ...Additional Data goes here
>>
>> --boundary1--
>>
>>
>>
>>> Brian
>>>
>>> On May 9, 2013, at 11:07 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>>>
>>>> I haven't looked at this for several versions, so this comment is not
>>>> specific to this version...
>>>>
>>>> I see no mention of use of Content-Disposition in this draft.
>>>> It really ought to talk about that and show it in examples.
>>>> Take a look at RFC5621 for issues to consider. A couple of main points:
>>>>
>>>> - In cases where the data is in the message and referenced from
>>>> Call-Info, the Content-Disposition should be 'by-reference'.
>>>>
>>>> - Think carefully about how you want to set the handling parameter.
>>>>
>>>> Thanks,
>>>> Paul
>>>>
>>>> On 5/5/13 7:29 AM, Hannes Tschofenig wrote:
>>>>> Hi all,
>>>>>
>>>>> I just posted an interim update (as version -08) for the additional
>>>>> data
>>>>> draft. It captures some of the discussions we had on the mailing list
>>>>> recently but it is not a complete update yet since there are a
>>>>> number of
>>>>> other issues that need to be addressed.
>>>>>
>>>>> Here is the updated version:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data
>>>>>
>>>>> From the diff you can see that I
>>>>> * updated the introduction,
>>>>> * added terminology (related to the discussion about service
>>>>> provider),
>>>>> * updated the XML schemas,
>>>>> * included extension points to the schemas,
>>>>> * added more examples (which have been validated against the schemas),
>>>>> * added the vCard/xCard XML schema,
>>>>> * fixed various bugs, and
>>>>> * updated references
>>>>>
>>>>> Ciao
>>>>> Hannes
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> Ecrit@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> Ecrit@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>
>>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>
>
 
From pkyzivat@alum.mit.edu Mon May 13 08:23:40 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA56B21F92EC for ; Mon, 13 May 2013 08:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yp1hVXL+d-VO for ; Mon, 13 May 2013 08:23:36 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id E4AF121F9227 for ; Mon, 13 May 2013 08:23:35 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta14.westchester.pa.mail.comcast.net with comcast id bPfL1l0030EZKEL5ETPauj; Mon, 13 May 2013 15:23:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id bTPa1l00c3ZTu2S3MTPavH; Mon, 13 May 2013 15:23:34 +0000 Message-ID: <51910575.7030700@alum.mit.edu> Date: Mon, 13 May 2013 11:23:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Hannes Tschofenig References: <518642B5.7090700@gmx.net> <518C6469.9090307@alum.mit.edu> <518D5452.6010202@alum.mit.edu> <518FCF1B.8040503@gmx.net>, <51903073.8020807@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368458614; bh=7DDrcsnzm7Ym1GU/x5zBUG8UnW92PKm2xnvnGxYsUkY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Y9p6Wf5gDaGTRb+N4r/Lw/aYKiTriu09i4mDT7nk9+fRqrJRNBoBPzBBkluJMGIPU nMhKoJH1R4HbUlTxQGtQzChyJnpfcph/E49/+WL5qzecvFqHSDfFDDyBkQO7VrZ0Eg AEYWXukisrQO/Ypa8GPosHeln6oizv072beP7mjOGLPsK0lxH/JqHUu6vue6TeQ9vj 4kq/PqhT6EtwGLy0l+gF3ZkIt4DjDvS4qDAB0te3f1lo+UWZ+3HTb+TiX5MyDwcs1z 1+v7phk9prk7HwRIp8Ra2hsCi85EebRpVHy5w3r5hHk2BbPP5apdnqguSqRfbDx5gt RnRWNMeyOlhTw== Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: Version -08 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 15:23:40 -0000 On 5/13/13 4:18 AM, Hannes Tschofenig wrote: > It is obviously not a huge addition to add this line > " > Content-Disposition: by-reference;handling=optional > " > to the payloads. Note that the choice of optional/required may depend on context. The WG may want to discuss that. But, since it is being referenced from a header field, and processing of the header field is itself in general optional, maybe optional is the only meaningful choice. If you want it to be required, then you may need to use a sip option. Thanks, Paul > So, if there is some value in doing that I am fine with it. > *Gesendet:* Montag, 13. Mai 2013 um 02:14 Uhr > *Von:* "Paul Kyzivat" > *An:* "Hannes Tschofenig" > *Cc:* "Brian Rosen" , ecrit@ietf.org > *Betreff:* Re: [Ecrit] Additional Data: Version -08 > > > On 5/12/13 1:19 PM, Hannes Tschofenig wrote: > > Hi Paul, Hi Brian, > > > > I am OK to add the Content-Disposition line to the example but I am > > wondering how much value it adds. I have just been looking at RFC 6442 > > ("SIP Location Conveyance") and we don't use Content-Disposition there > > either. From a high-level point of view I don't think that the > > additional data document is much different from adding location to the > > body of the SIP message and to have a reference in the header. > > It should have been used there too. I'm sorry I didn't catch that. > > The problem is that without it the rules for how to process multipart > bodies are ambiguous and ad hoc. In the past there was very little use > of that, and we have been getting by with ad hoc. But as more complex > usages come up (and they are) it gets harder and harder to do the right > thing that way. > > Thanks, > Paul > > > Ciao > > Hannes > > > > On 05/10/2013 11:10 PM, Paul Kyzivat wrote: > >> On 5/10/13 9:35 AM, Brian Rosen wrote: > >>> Yeah, we definitely want 'by-reference' for Content-Disposition > >>> > >>> Usually, I would expect to see the handling parameter for the > >>> multipart/mixed be 'optional', but that's because I'm only thinking > >>> that we might see SDP,] location and and additional-data parts and > >>> nothing else. But who knows what might happen in the future. > >> > >> If what you have is a multipart/mixed containing SDP and > >> additional-data, then it is essential that the SDP be processed. To > >> ensure that the multipart/mixed must be 'required'. Then the SDP can be > >> 'required' and the additional-data 'optional'. > >> > >> Even RFC5621 neglected to specify what the Content-Disposition value > >> should be for multipart bodies. By default it is 'render' which doesn't > >> make a lot of sense. But I think we consider it grandfathered. Its also > >> the default (for everything except SDP), and 'required' is also default, > >> so you can omit Content-Disposition in those cases. But if you want the > >> entire multipart to be optional then you will need to specify > >> Content-Disposition:render;handling=optional > >> > >>> But what about the additional-data part itself? 'render' is probably > >>> okay. Is there something better? > >> > >> That is the one that should be 'by-reference'. That means that what to > >> do with it is determined by the reference. In your case, that is the > >> Call-info:...purpose=emergencyCallData... > >> > >> So I think the example in Section 10 should be: > >> > >> INVITE sips:bob@biloxi.example.com SIP/2.0 > >> Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 > >> Max-Forwards: 70 > >> To: Bob > >> From: Alice ;tag=9fxced76sl > >> Call-ID: 3848276298220188511@atlanta.example.com > >> Call-Info: > >> ;purpose=icon, > >> ;purpose=info, > >> > >> ;purpose=emergencyCallData.ProviderInfo > >> Geolocation: > >> Geolocation-Routing: no > >> Accept: application/sdp, application/pidf+xml, > >> application/emergencyCallProviderinfo+xml > >> CSeq: 31862 INVITE > >> Contact: > >> Content-Type: multipart/mixed; boundary=boundary1 > >> > >> Content-Length: ... > >> > >> --boundary1 > >> > >> Content-Type: application/sdp > >> > >> ... can omit Content-Disposition because defaults are ok > >> ...SDP goes here > >> > >> --boundary1 > >> > >> Content-Type: application/pidf+xml > >> Content-ID: > >> Content-Disposition: by-reference;handling=optional > >> > >> \0x2026PIDF-LO goes here > >> > >> --boundary1-- > >> > >> Content-Type: application/emergencyCall.ProviderInfo+xml > >> Content-ID: <1234567890@atlanta.example.com> > >> Content-Disposition: by-reference;handling=optional > >> > >> ...Additional Data goes here > >> > >> --boundary1-- > >> > >> > >> > >>> Brian > >>> > >>> On May 9, 2013, at 11:07 PM, Paul Kyzivat > wrote: > >>> > >>>> I haven't looked at this for several versions, so this comment is not > >>>> specific to this version... > >>>> > >>>> I see no mention of use of Content-Disposition in this draft. > >>>> It really ought to talk about that and show it in examples. > >>>> Take a look at RFC5621 for issues to consider. A couple of main > points: > >>>> > >>>> - In cases where the data is in the message and referenced from > >>>> Call-Info, the Content-Disposition should be 'by-reference'. > >>>> > >>>> - Think carefully about how you want to set the handling parameter. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 5/5/13 7:29 AM, Hannes Tschofenig wrote: > >>>>> Hi all, > >>>>> > >>>>> I just posted an interim update (as version -08) for the additional > >>>>> data > >>>>> draft. It captures some of the discussions we had on the mailing list > >>>>> recently but it is not a complete update yet since there are a > >>>>> number of > >>>>> other issues that need to be addressed. > >>>>> > >>>>> Here is the updated version: > >>>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data > >>>>> > >>>>> From the diff you can see that I > >>>>> * updated the introduction, > >>>>> * added terminology (related to the discussion about service > >>>>> provider), > >>>>> * updated the XML schemas, > >>>>> * included extension points to the schemas, > >>>>> * added more examples (which have been validated against the > schemas), > >>>>> * added the vCard/xCard XML schema, > >>>>> * fixed various bugs, and > >>>>> * updated references > >>>>> > >>>>> Ciao > >>>>> Hannes > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>> > >>> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > From hannes.tschofenig@gmx.net Tue May 14 11:33:40 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C549821F8F69 for ; Tue, 14 May 2013 11:33:39 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bn5Vytevu5q for ; Tue, 14 May 2013 11:33:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6759B21F8F53 for ; Tue, 14 May 2013 11:33:34 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MH2QW-1UgDmA445C-00DrdI for ; Tue, 14 May 2013 20:33:33 +0200 Received: (qmail invoked by alias); 14 May 2013 18:33:32 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp031) with SMTP; 14 May 2013 20:33:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+2E5JViy62H6bkD8nwI1JgFvfL+m59OoYb96LWoU e4VMlIMFCj6EJd Message-ID: <51928377.10409@gmx.net> Date: Tue, 14 May 2013 21:33:27 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "ecrit@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [Ecrit] Status of Additional Data Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 18:33:40 -0000 Hi all, yesterday I gave a presentation to the NENA additional data working group about the status of the additional data draft. The slides can be found here: https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-data/AdditionalData-Status-13May2013v2.ppt?raw=true (I have updated them a bit after the meeting based on the feedback.) The slides list and discuss open issues. I will post proposals for how to resolve them to the list. Ciao Hannes From James.Winterbottom@commscope.com Tue May 14 18:04:08 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2E121F8E49 for ; Tue, 14 May 2013 18:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqosH6nP7UZY for ; Tue, 14 May 2013 18:04:04 -0700 (PDT) Received: from cdcsmgw02.commscope.com (cdcsmgw02.commscope.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id B6BC921F8D70 for ; Tue, 14 May 2013 18:04:04 -0700 (PDT) X-AuditID: 0a0404e9-b7f576d00000116c-3a-5192df0311b5 Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id B4.AC.04460.30FD2915; Tue, 14 May 2013 20:04:03 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 14 May 2013 20:04:03 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 15 May 2013 09:04:00 +0800 From: "Winterbottom, James" To: Hannes Tschofenig , "ecrit@ietf.org" Date: Wed, 15 May 2013 09:03:57 +0800 Thread-Topic: [Ecrit] Status of Additional Data Draft Thread-Index: Ac5Q0ZIz8ACLZK8FQ1WE+CsCswiSEwANVzrw Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121409BA260@SISPE7MB1.commscope.com> References: <51928377.10409@gmx.net> In-Reply-To: <51928377.10409@gmx.net> 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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBKsWRmVeSWpSXmKPExsXCFSYjqst8f1KgwYQ9ShaNi56yWizdeY/V gclj8ab9bB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYer+bpeAwX8Ws98tYGxh/cXcxcnJICJhI 7Fy+iBnCFpO4cG89WxcjF4eQwC5Gidb509khnA2MEmdeTIJy1jNK/Nl8DayFTcBO4vD6G2C2 iECYxJ01M1hAbBYBVYkZ+14wgtjCQCsevullhagxlXg2ZxUbhG0ksbj9Jlg9r0CQxLxZd8Dq hQRUJF79uwI0k4ODE2jO60t8IGFGoOu+n1rDBGIzC4hL3HoynwniagGJJXvOQ30gKvHy8T9W iHpRiTvt6xkh6nUkFuz+xAZha0ssW/iaGWKtoMTJmU9YINbqSjTt/Mo6gVF8FpIVs5C0z0LS PgtJ+wJGllWM4skpycW56eUGRnrJ+bm5xcn5Bakg1iZGUHSxsLzcwXh2g/YhRgEORiUe3oLA SYFCrIllxZW5hxglOZiURHnP3AUK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuE1vAaU401JrKxK LcqHSWlwcAicfnL/FKMUS15+XqqSBG8kyAjBotT01Iq0zBxgaoEpZeLgBBnFAzQqGaSGt7gg Mbc4Mx0if4pRlWPF5pevGYXABkmJ86aBFAmAFGWU5sHNecUoDnS8MG8GSJYHmBzhJrwCGs4E NFyzBGx4SSJCSqqBUXtuuE+H3NIQccv5litinI6KlJ/W7ZuY7ScYLDG1ubz09xPppEqT8q8n T2bdev3/wl7NDk79DDbGRc1rq+Kz7gi/8tS7s2+yyO+dPmcrJrYd5eSMy9witCxa+Zd455GG G5qv17kVuYmfCFRrcA90/zd1Jrvd0rw7u+8ZHrusKB/47X7Pl7Q2JZbijERDLeai4kQAUpBE s0sDAAA= Subject: Re: [Ecrit] Status of Additional Data Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 01:04:08 -0000 Hi Hannes, Thanks for providing the overview slides, I think that these are good. As you know, I reviewed the previous version of this document with a eye to= implementation so my comments were focused on that in mind. Keeping to tha= t theme and based on recent experience with RFC5139 (civic location) and th= e subsequent update required with RFC6848 (local civic) I think that point = 5 on slide 13 needs more substance to it. I think that it is crucial that t= he document actually describe "how" specific elements are intended to be ex= tended so that we don't have someone come along and try and fundamentally c= hange the schemas or debate at length on why things need to be changed. This particular specification is going to need to be implemented by a lot o= f different entities and so updates can't require wholesale or non-backward= s compatible changes. This means that we need to be explicit about how we s= ee changes and additions occurring.=20 Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Wednesday, 15 May 2013 4:33 AM To: ecrit@ietf.org Subject: [Ecrit] Status of Additional Data Draft Hi all, yesterday I gave a presentation to the NENA additional data working group a= bout the status of the additional data draft. The slides can be found here: https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-d= ata/AdditionalData-Status-13May2013v2.ppt?raw=3Dtrue (I have updated them a bit after the meeting based on the feedback.) The slides list and discuss open issues. I will post proposals for how to r= esolve them to the list. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@commscope.com Tue May 14 20:07:29 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E75521F8A74 for ; Tue, 14 May 2013 20:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmS04oYAVTou for ; Tue, 14 May 2013 20:07:24 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id A09F721F885A for ; Tue, 14 May 2013 20:07:23 -0700 (PDT) X-AuditID: 0a0404e8-b7fdb6d000001d37-e7-5192fbea8f81 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id FF.87.07479.AEBF2915; Tue, 14 May 2013 22:07:22 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 14 May 2013 22:07:22 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 15 May 2013 11:06:26 +0800 From: "Winterbottom, James" To: "ecrit@ietf.org" Date: Wed, 15 May 2013 11:06:24 +0800 Thread-Topic: Additional Data "Service Delivered by Provider" extended proposal Thread-Index: Ac5RGS8KQBY/nUUERvW0Lm5viosJMw== Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121409BA294@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC81880121409BA294SISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsXCFSaSpvvq96RAg5XrtSwaFz1ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsvLmewFT6IqZl7/ydbA+MKvi5GTQ0LARGLhzbssELaYxIV7 69m6GLk4hAR2M0oc3PaZHcLZwCjxaf0SFghnHaPEmgMTwFrYBOwkDq+/wQxiiwioSmw4s5IR xGYBsj9en8kOYgsLeEn0v1kLVRMoceDfPlYIW09i2+3/QPUcHLwCQRKzv3mDhBmBrvh+ag0T iM0sIC5x68l8JojrBCSW7DnPDGGLSrx8/I8Vol5U4k77ekaI+nyJrvs3wWp4BQQlTs58Anam kICuRNPOr6wTGEVmIRk7C0nLLCQtEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjeHJK cnFuermBoV5yfm5ucXJ+QSqItYkRFEksLC92MJ7eoH2IUYCDUYmHV8J/UqAQa2JZcWXuIUZJ DiYlUV7HX0AhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIryG14ByvCmJlVWpRfkwKQ0ODoHTT+6f YpRiycvPS1WS4N0LMkKwKDU9tSItMweYRmBKmTg4QUbxAI3aBFLDW1yQmFucmQ6RP8WozTFr 65PXjBwrNr98zSgENk5KnPcmSKkASGlGaR7ctFeM4kAvCPOWgmR5gEkRbs4roBVMQCs0S8BW lCQipKQaGKevWn7iP/OMdIfvq5/Yid6/euHKmeONrHe/n9UtEtF4o7l0zrPDR0Qi86+prQ+L a+NZ4pi58Zudz7UJYlKV73h1zBgP5Cza/vnsdEV7Sa5rpffV67hXPdUwZt13Pjn8ZGJBjuby 9PQuoZPC1+W227N2ix40uvq9+siM8JANkowyj1eoXlS34lFiKc5INNRiLipOBACXyon/RwMA AA== Subject: [Ecrit] Additional Data "Service Delivered by Provider" extended proposal X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 03:07:29 -0000 --_000_5A55A45AE77F5941B18E5457ECAC81880121409BA294SISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I made some comments back in March on section 6.2 "Service Delivered by Pro= vider to End user" of the additional data document. My concern was that the= section conflated access type, connectivity flow and intended application = in such a way that you couldn't define a wireless data-only service with a = caller using an OTT voice provider. I provided a rough suggestion that Hann= es has subsequently asked me to expand on a bit. I am sure the following is= not perfect, but it does show perhaps more clearly where I see this sectio= n needing to go and I do welcome any suggestions. I propose that the element have four elements: can be further broken down into or For I was thinking: Satellite, CDMA2000, CDMA1xRTT, GSM, G= PRS, EDGE, UMTS, HSDPA, WiFi, WiMAX, LTE. We may be able to reduce or expan= d this set based on comments and thoughts. For I was thinking a and a or encoding. For I was thinking: Twisted-Pair, Coax, Fibre. I am not sure if HFC = needs its own in this set or if there are others to consider. For I was thinking: POTS, ADSL, ADSL2, ADSL2+, DOCSIS-1, DOCSI= S-2, DOCSIS-3. I am sure there are others here. My rationale for providing = this level of detail is that indicates something of the service speed, but = there may be more reasons. I could be convinced quite easily to drop it too= . I was thinking: Circuit-Switched, Packet-Switched. I am no= t sure if there are others. I was thinking: Voice, Data, Fax. There may be others. More t= han one of these values might be allowed. I was thinking that this would pick up most of what used = to be in the original element: Pay/Coin One-Way-Outbound Inmate-Service Soft-Dial Quick-Service Warm-Disconnect Suspended MLTS Sensor-Unattended Sensor-Attended Telephone (physical or software) Video-Phone (physical or software) Relay-Service An example of this approach would then be: HSDPA PacketSwitched Data In this example the provider is providing an HSDPA data service so there is= no . Cheers James --_000_5A55A45AE77F5941B18E5457ECAC81880121409BA294SISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I made= some comments back in March on section 6.2 “Service Delivered by Pro= vider to End user” of the additional data document. My concern was th= at the section conflated access type, connectivity flow and intended applic= ation in such a way that you couldn’t define a wireless data-only ser= vice with a caller using an OTT voice provider. I provided a rough suggesti= on that Hannes has subsequently asked me to expand on a bit. I am sure the = following is not perfect, but it does show perhaps more clearly where I see= this section needing to go and I do welcome any suggestions.

 

I propose t= hat the <SvcDelByProvider> element have four elements:

=

<PhysicalAccessType>

<ConnectionType>

<Servi= ceType>

<ApplicationServiceType>= ;

 

<PhysicalAccessType> can be further broken down into <Wireless= Access> or <WiredAccess>

For &l= t;WirelessAccess> I was thinking: Satellite, CDMA2000, CDMA1xRTT, GSM, G= PRS, EDGE, UMTS, HSDPA, WiFi, WiMAX, LTE. We may be able to reduce or expan= d this set based on comments and thoughts.

For <WiredAccess> I was thinking a <type> and a <modulati= on> or encoding.

For <type> I w= as thinking: Twisted-Pair, Coax, Fibre. I am not sure if HFC needs its own = in this set or if there are others to consider.

For <modulation> I was thinking: POTS, ADSL, ADSL2, ADSL2+, D= OCSIS-1, DOCSIS-2, DOCSIS-3. I am sure there are others here. My rationale = for providing this level of detail is that indicates something of the servi= ce speed, but there may be more reasons. I could be convinced quite easily = to drop it too.

 

<ConnectionType> I was thinking: Circuit-Switched, = Packet-Switched. I am not sure if there are others.

 

<ServiceType> = I was thinking: Voice, Data, Fax. There may be others. More than one of the= se values might be allowed.

 <= /o:p>

<ApplicationType> I was thinking that t= his would pick up most of what used to be in the original <SvcDelByProvi= der> element:

    = ;           Pay/Coin=

       &n= bsp;       One-Way-Outbound

         &nb= sp;     Inmate-Service

            =    Soft-Dial

   = ;            Quick-S= ervice

     &nb= sp;         Warm-Disconnect

        = ;       Suspended

           &= nbsp;   MLTS

   = ;            Sensor-= Unattended

     = ;          Sensor-Attended

       &= nbsp;       Telephone (physical or software)<= o:p>

      &nbs= p;        Video-Phone (physical or softw= are)

      = ;         Relay-Service<= /p>

 

An exampl= e of this approach would then be:

&= nbsp;

<SvcDelByProvider>

=

         =       <PhysicalAccess>

          &= nbsp;           &nbs= p;       <WirelessAccess>HSDPA</Wire= lessAccess>

    &= nbsp;          </PhysicalAc= cess>

     &= nbsp;         <ConnectionType>= ;PacketSwitched</ConnectionType>

&= nbsp;           &nbs= p;  <ServiceType>Data</ServiceType>

          &n= bsp;    <ApplicationType/>

</SvcDelByProvider>

&= nbsp;

In this example the provider is providi= ng an HSDPA data service so there is no <ApplicationType>.=

 

&nb= sp;

Cheers

James

 

 

    =           

 

 =

= --_000_5A55A45AE77F5941B18E5457ECAC81880121409BA294SISPE7MB1co_-- From hannes.tschofenig@gmx.net Wed May 15 00:41:55 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E95F21F8F11 for ; Wed, 15 May 2013 00:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.831 X-Spam-Level: X-Spam-Status: No, score=-100.831 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rr3KH-EF8IRd for ; Wed, 15 May 2013 00:41:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2664721F89FF for ; Wed, 15 May 2013 00:41:49 -0700 (PDT) Received: from 3capp-gmx-bs11.server.lan ([172.19.170.62]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M6yV9-1UHX8y03aH-00whwp for ; Wed, 15 May 2013 09:41:49 +0200 Received: from [194.251.119.196] by 3capp-gmx-bs11.server.lan with HTTP; Wed May 15 09:41:49 CEST 2013 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: ecrit@ietf.org Content-Type: text/html; charset=UTF-8 Date: Wed, 15 May 2013 09:41:48 +0200 (CEST) Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:OrvvWba7a9dYHSF45jSr14CPDoX9PYTfU6mRVhicK95 VT3sZdQMLPH5yIzRq/LRsnlMHhZoXmNC4ptPTD8X7PmpvQKTxN WVnJn39kcjAx0OgnVP7YncxYXrSXAX5BncrNd3wGsIcmPYUlWd M0mrJbXPwUp+4Pz0uYisSToz4FSzSSahnbu+vXBgWgDFhnzyZo ED1CyYAO6s9ugEWs5c9DtLLhCU+uAjMdEB+Q85NqYD68S3XC5D 3/OZZZYnGI1FzBrLRMgFaPLJXsFW44IcZMD7jZd23sLbZ+6srj F/LsP0= Subject: Re: [Ecrit] Comments on additional-data-05 SvcDelByProvider X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 07:41:55 -0000
Guy pointed out that we had skipped comments that he had provided to the list late last year.
I double-checked with the current draft and he is indeed correct that we had forgotten those.
 
A few remarks inline:
 
> -------- Original Message --------
> Subject: [Ecrit] Comments on additional-data-05 SvcDelByProvider
> Date: Mon, 19 Nov 2012 08:28:28 -0500
>
> Hi ECRIT,
>
> Please find the following comments for your consideration.
>
> In section 5.2, it states that the registry will reflect a list of
> initial valid entries, including "Remote (off premise extension)"
> however, there is no corresponding value in section 13.1.4. I suggest
> adding the value name "OPX" and the corresponding description "off
> premise extension" in the table.
 
This is correct. The table in the IANA consideration section and the table in (now) Section 6.2 is not in sync.
I guess it would be better to only have one table to avoid these types of problems.
 
>
> There is a statement at the end of section 5.2 that says "There can be
> more than one value returned. For example, a VoIP inmate telephone
> service is a reasonable combination" however, I'm not sure the XML
> schema in section 5.4 allows this. One option would be to modify the
> schema for SvcDelByProvider to maxOccurs=nbounded". Another option
> would
> be to make SvcDelByProvider a list type.
 
That's correct. I need to update the XML schema.
 
>
> There are several deployments of hosted voice services today, both in
> the PSTN (Centrex being one of them) and IP. In Section 13.1.4, there
> is
> no value to capture hosted services. An option would be to create a
> value "HostedMLTS". Another option, perhaps more flexible, would be to
> add a value "Hosted" that, combined with "MLTS" would cover these
> cases.
> Of course, there are combinations that we wouldn't want to see such as
> "Hosted" and "Prison". Perhaps some text in that regard would be
> required.
 
Ok.
 
Ciao
Hannes
 
>
> Regards,
>
> Guy
> _______________________________________________
> Ecrit mailing list
>
 
From ietf-ipr@ietf.org Tue May 21 12:39:22 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E26F11E8110; Tue, 21 May 2013 12:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLVJmr58M8l8; Tue, 21 May 2013 12:39:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1594E11E80FD; Tue, 21 May 2013 12:39:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: br@brianrosen.net,jmpolk@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130521193921.8418.57617.idtracker@ietfa.amsl.com> Date: Tue, 21 May 2013 12:39:21 -0700 Cc: marc.linsner@cisco.com, ecrit@ietf.org, ipr-announce@ietf.org Subject: [Ecrit] IPR Disclosure: Qualcomm Incorporated's Statement about IPR related to RFC 6881 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 19:39:22 -0000 Dear Brian Rosen, James Polk: An IPR disclosure that pertains to your RFC entitled "Best Current Practic= e for Communications Services in Support of Emergency Calling" (RFC6881) was subm= itted to the IETF Secretariat on 2013-04-05 and has been posted on the "IETF Page= of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2048/). The title of the IPR disclosure is "Qualcomm Incorporated's Statement about IPR related to RFC 6881.""); The IETF Secretariat From hannes.tschofenig@gmx.net Mon May 27 23:44:51 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F02421F8F4A for ; Mon, 27 May 2013 23:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.541 X-Spam-Level: X-Spam-Status: No, score=-98.541 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irTyOtuX5UYF for ; Mon, 27 May 2013 23:44:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3844721F8F62 for ; Mon, 27 May 2013 23:44:46 -0700 (PDT) Received: from 3capp-gmx-bs56.server.lan ([172.19.170.140]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Mfl1O-1V22HZ18Y0-00N9v8 for ; Tue, 28 May 2013 08:44:45 +0200 Received: from [194.251.119.196] by 3capp-gmx-bs56.server.lan with HTTP; Tue May 28 08:44:45 CEST 2013 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: ecrit@ietf.org Content-Type: text/html; charset=UTF-8 Date: Tue, 28 May 2013 08:44:45 +0200 (CEST) Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:yiGsh8jOnsHGGL/Gw7CAsuNdBMa8iMLrvLaWfeW6b7X dHwEfp/LhA+9GcX6WNbVAwE5IYlP6UiTj6XF+D0v1XPPCieOHj c4Vz93xPmXSpEULnRcLrjRK+9H8r5qcv2HC7XgBSSV3nty5q62 Yaw7XYVDqIdHULc2qewiFnnX6js1BEpoxZG3O5yHXtkYTHylsZ wE38NnPbkgrZ4b0uUNw2XB4tzXM3aq+IWRLaTDKfVhrMdXe/Vc 3cMJxh8ktoFu8GB9/BiSWISaurVhPUsAU0Cyc0Ci7RNJ+r8B13 foE1fA= Subject: [Ecrit] Data Provider Contact URI X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 06:44:51 -0000
Hi all, 
 
I just had a chat with James about the data provider contact URI and he asked me why the URI must be a SIP URI. Although the text talks about how to encode a telephone number in the SIP URI I wasn't able to explain James why we couldn't simply put a tel URI in there. 
 
Here is the text from the current draft: 

5.5. Data Provider Contact URI

 
Data Element: Data Provider Contact URI
 
Use: Required XML Element: <ContactURI>
 
Description: For a service provider the contact SHOULD be a contact URI. This MUST be a SIP URI. If a telephone number is the contact address it should be provided in the form of sip:telephonenumber@serviceprovider:user=phone. If the call is from a device, this would reflect the contact information of the owner of the device. When provided by a service provider, this would be a URI to a 24/7 support organization tasked to provide PSAP support for this emergency call.
 
--------
 
Any objection to allow other URIs to be included in the ​<ContactURI> element? The XML schema only allows one occurence and I wonder why we shouldn't allow multiple occurences here. 
Ciao
Hannes
 
From christer.holmberg@ericsson.com Tue May 28 00:25:21 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740D521F90E0 for ; Tue, 28 May 2013 00:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.801 X-Spam-Level: X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLhMU33m2z6s for ; Tue, 28 May 2013 00:25:15 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5203621F8FF8 for ; Tue, 28 May 2013 00:25:14 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-73-51a45bd8ebb0 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 20.AD.28930.8DB54A15; Tue, 28 May 2013 09:25:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Tue, 28 May 2013 09:25:12 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-holmberg-ecrit-country-emg-urn: Modifications to suggested new text for section 4.2 of RFC 5031 Thread-Index: Ac5HN8eJkr18YLEeSgK6JXaqZssQ9gUPIDww Date: Tue, 28 May 2013 07:25:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37A77B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3699D3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3699D3@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C37A77BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre7N6CWBBtd/slk0LnrKanGlbyWT A5PH11sHmTyWLPnJFMAUxWWTkpqTWZZapG+XwJWxaO9axoK72hWt/64wNjCeVOti5OSQEDCR eLLkDSuELSZx4d56NhBbSOAwo8SVLZVdjFxA9hJGiRU3TwAlODjYBCwkuv9pg9SICKhKbDiz khHEZhZwlbi/aQsTiC0sUCNx7c9SJoiaWolvG9ewQthGEnsPbQabzwLUe2ZVKwuIzSvgK3Fn 9nJmiL2+Em2HboLVcwr4Sex/vIQdxGYEuu37qTVMELvEJW49mc8EcbOAxJI955khbFGJl4// sYKcKSGgKLG8Xw6iPF/i2exjUKsEJU7OfMIygVF0FpJJs5CUzUJSBhHXkViw+xMbhK0tsWzh a2YY+8yBx0zI4gsY2VcxsucmZuaklxtuYgTG08Etv3V3MJ46J3KIUZqDRUmcV493caCQQHpi SWp2ampBalF8UWlOavEhRiYOTqkGxpk7767csZM7P+9S3myt3KMtR2YGh7JmmMybs77fjHFr ssv185c4PdrXODzu+rbKuTctf/Oj4P6MZ5vUvgtJ+L2Muuac7NXA8cA9Xtny/+c3/lEXItPk tl/Y9/NE5tqQ5bVZW2QWm5r8q4soKlmS+m7ng/Bri4yrfrE4nhY39T53LMN9d1TGISWW4oxE Qy3mouJEANVLdZN1AgAA Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn: Modifications to suggested new text for section 4.2 of RFC 5031 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 07:25:22 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C37A77BESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reminder. Again, I would like people who have comments and modification suggestions t= o the new text (or, the draft in general) to bring it forward. My intention= is to request for WGLC of the draft soon. Thanks! Regards, Christer From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of C= hrister Holmberg Sent: 2. toukokuuta 2013 16:21 To: ecrit@ietf.org Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn: Modifications to sug= gested new text for section 4.2 of RFC 5031 Hi, In Orlando, at least Henning indicated that he would like to modify, and ex= pand, the suggested new text for section 4.2 of RFC 5031. I would appreciate if those who want modifications provide some text - or a= t least some explanation of what modifications they would like to see :) Thanks! Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C37A77BESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reminder.

 

Again, I would like pe= ople who have comments and modification suggestions to the new text (or, th= e draft in general) to bring it forward. My intention is to request for WGL= C of the draft soon.

 

Thanks!

 

Regards,

 

Christer

 

From: ecrit-bo= unces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 2. toukokuuta 2013 16:21
To: ecrit@ietf.org
Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn: Modifications= to suggested new text for section 4.2 of RFC 5031

 

Hi,

 

In Orlando, at least Henning indicated that he would= like to modify, and expand, the suggested new text for section 4.2 of RFC = 5031.

 

I would appreciate if those who want modifications p= rovide some text – or at least some explanation of what modifications= they would like to see :)

 

Thanks!

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1C37A77BESESSMB209erics_-- From christer.holmberg@ericsson.com Tue May 28 00:27:16 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F59021F91CB for ; Tue, 28 May 2013 00:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.825 X-Spam-Level: X-Spam-Status: No, score=-5.825 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZie26fAN-OL for ; Tue, 28 May 2013 00:27:07 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 696CB21F931B for ; Tue, 28 May 2013 00:27:06 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-e5-51a45c47125d Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8C.24.31782.74C54A15; Tue, 28 May 2013 09:27:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Tue, 28 May 2013 09:27:02 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-holmberg-ecrit-country-emg-urn: Modifications to suggested new text for section 4.2 of RFC 5031 Thread-Index: Ac5HN8eJkr18YLEeSgK6JXaqZssQ9gUPIDwwAAAYinA= Date: Tue, 28 May 2013 07:27:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37A7A8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C3699D3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C37A77B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37A77B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C37A7A8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvra57zJJAg44TqhaNi56yWlzpW8nk wOTx9dZBJo8lS34yBTBFcdmkpOZklqUW6dslcGV8vv6UreCCXcX+e5NYGhhPm3cxcnJICJhI tG9bxA5hi0lcuLeerYuRi0NI4DCjxJsNRxkhnCWMEmsWz2XqYuTgYBOwkOj+pw3SICKgKrHh zEpGEJtZwFXi/qYtTCC2sECNxLU/S5kgamolvm1cwwphW0ms7H/GDjKGBah38idDkDCvgK/E i5aTTBCrJjJKTL68C6yXU8BP4tipRrDjGIGO+35qDRPELnGJW0/mM0EcLSCxZM95ZghbVOLl 43+sIPMlBBQllvfLQZTnS3zev50JYpegxMmZT1gmMIrOQjJpFpKyWUjKIOI6Egt2f2KDsLUl li18zQxjnznwmAlZfAEj+ypG9tzEzJz0cqNNjMCIOrjlt+oOxjvnRA4xSnOwKInz6vEuDhQS SE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAmL9QLyqfy6GTbeJWxoiHYdyBSr11p95VmeZef+df Hxd790YMm3pzyDGDxx/6C++oq73O2eyg6Xne7P/dyrv72qf8THlkySv8drHA3PhZayonftad fc56y+w8S8/VTiWxvQ0BfuVz5MReX6jU7HnX0bf9WEgqE9PTTPt/2Z//1xTcvrGB9a+sEktx RqKhFnNRcSIApqJ6QXYCAAA= Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn: Modifications to suggested new text for section 4.2 of RFC 5031 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 07:27:16 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C37A7A8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And, I'm of course talking about the WG adopted version of the draft, draft= -ietf-ecrit-country-emg-urn-00.txt. Regards, Christer From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of C= hrister Holmberg Sent: 28. toukokuuta 2013 10:25 To: ecrit@ietf.org Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn: Modifications to= suggested new text for section 4.2 of RFC 5031 Reminder. Again, I would like people who have comments and modification suggestions t= o the new text (or, the draft in general) to bring it forward. My intention= is to request for WGLC of the draft soon. Thanks! Regards, Christer From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Christer Holmberg Sent: 2. toukokuuta 2013 16:21 To: ecrit@ietf.org Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn: Modifications to sug= gested new text for section 4.2 of RFC 5031 Hi, In Orlando, at least Henning indicated that he would like to modify, and ex= pand, the suggested new text for section 4.2 of RFC 5031. I would appreciate if those who want modifications provide some text - or a= t least some explanation of what modifications they would like to see :) Thanks! Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C37A7A8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And, I’m of cour= se talking about the WG adopted version of the draft, draft-ietf-ecrit-coun= try-emg-urn-00.txt.

 

Regards,

 

Christer

 

From: ecrit-bo= unces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 28. toukokuuta 2013 10:25
To: ecrit@ietf.org
Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn: Modificat= ions to suggested new text for section 4.2 of RFC 5031

 

Reminder.

 

Again, I would like pe= ople who have comments and modification suggestions to the new text (or, th= e draft in general) to bring it forward. My intention is to request for WGL= C of the draft soon.

 

Thanks!

 

Regards,

 

Christer

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 2. toukokuuta 2013 16:21
To: ecrit@ietf.org
Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn: Modifications= to suggested new text for section 4.2 of RFC 5031

 

Hi,

 

In Orlando, at least Henning indicated that he would= like to modify, and expand, the suggested new text for section 4.2 of RFC = 5031.

 

I would appreciate if those who want modifications p= rovide some text – or at least some explanation of what modifications= they would like to see :)

 

Thanks!

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1C37A7A8ESESSMB209erics_-- From hannes.tschofenig@gmx.net Tue May 28 01:04:57 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4085C21F9298 for ; Tue, 28 May 2013 01:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.634 X-Spam-Level: X-Spam-Status: No, score=-98.634 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2KpgQj4SsER for ; Tue, 28 May 2013 01:04:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id A345121F8FED for ; Tue, 28 May 2013 01:04:52 -0700 (PDT) Received: from 3capp-gmx-bs56.server.lan ([172.19.170.140]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lg2uj-1U6nU02DN5-00pfFr for ; Tue, 28 May 2013 10:04:51 +0200 Received: from [194.251.119.196] by 3capp-gmx-bs56.server.lan with HTTP; Tue May 28 10:04:51 CEST 2013 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: ecrit@ietf.org Content-Type: text/html; charset=UTF-8 Date: Tue, 28 May 2013 10:04:51 +0200 (CEST) Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:2dcgO40dOqecNQ/oFvJniYqCt5mHUbkcaEgvG2m4ZPR 16n87vxSGqBSPrvNxmtBOyWYvTdlMMGwuzVlOuuYM7etJXp/+p rRmkoRpR/Z+hDN91O83czIUKmbWThRi92BLOxL1blaZQ8YLlGq qznU4jNVLRqEdlsbDMpgz06MLmcOkYFGcrpX1a0xLm+0PNf273 6zorp4vzLhA48nvn6mX1zr/CtridZGrbltG32bbKMFzV7olcz0 j1cuqLDK2sz7ljv+rL5NQZMvem6L2VX84V2T75XztFARTha+X+ n8hny8= Subject: [Ecrit] Additional Data: Transport Related Question X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 08:04:57 -0000
Hi all, 
 
in offlist discussions Randy raised an interesting question regarding -08 (http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-08) I would like to bring to your attention. 
Randy wrote: 
 
In Section 4 first numbered hanging indent there is text:
 
"
        To be conveyed in a SIP body additional data about a call is
        defined as a series of MIME objects, each with an XML data
        structure contained inside.
"
 
and soon after there is this text:
 
"
       When additional data is
        provided by reference (in SIP signaling or Provided-By), each
        HTTPS URL references one block; the data is retrieved with an
        HTTP GET operation, which returns one of the blocks as an XML
        object.
"
 
I thought that even when HTTPS is used, the XML data is still 
identified as a MIME type?  That is, the HTTP response indicates that 
data of MIME type 'application/emergencyCall.ProviderInfo+xml' or 
whatever is being sent?
 
If I'm incorrect and the data is not identified as a MIME type, then 
the first text should be reworded for clarity as:
 
"
       To be conveyed in a SIP body, the additional data is
        defined as a series of MIME objects, one for each of the
        XML data structures.
"
 
Otherwise (if the data is identified using MIME types) then we should 
change the first text to:
 
"
        For transport in SIP or HTTP, the additional data is
        defined as a series of MIME objects, one for each of the
        data structures.
" 
 
I think it was slightly misleading to talk about the MIME type 
"containing" the XML data structure, since there is no additional 
encapsulation (aside from any 8-bit character considerations); 
rather, the MIME type is used to identify the data.  This is separate 
from the use of MIME body parts inside the SIP body to delineate the 
various parts.
 
My understanding so far was that MIME encapsulation is used for data that is carried in SIP and in HTTP. 
 
Here is an example. Imagine that a PSAP obtains an HTTPS URI pointing to Owner/Subscriber Information data.
 
This would lead to the following request:  
 
GET /path/file.html HTTP/1.1
Host: www.example.com
Accept: text/*, text/html, application/emergencyCall.SubInfo+xml
 
Here is an example response: 
 
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Cache-control: private
Content-Type: application/emergencyCall.SubInfo+xml;charset=utf-8
Content-Length: tbd
 
<?xml version="1.0" encoding="UTF-8"?>
<ad:emergencyCall.SubInfo 
     xmlns:ad="urn:ietf:params:xml:ns:emergencyCall.SubInfo"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <xc:SubscriberData xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">
        <vcards xmlns="urn:ietf:params:xml:ns:vcard-4.0">
            <vcard>
                <fn><text>Simon Perreault</text></fn>
                <n>
                    <surname>Perreault</surname>
                    <given>Simon</given>
                    <additional/>
                    <prefix/>
                    <suffix>ing. jr</suffix>
                    <suffix>M.Sc.</suffix>
                </n>
                <bday><date>--0203</date></bday>
                <anniversary>
                    <date-time>20090808T1430-0500</date-time>
                </anniversary>
                <gender><sex>M</sex></gender>
                <lang>
                    <parameters><pref><integer>1</integer></pref>
                    </parameters>
                    <language-tag>fr</language-tag>
                </lang>
                <lang>
                    <parameters><pref><integer>2</integer></pref>
                    </parameters>
                    <language-tag>en</language-tag>
                </lang>
                <org>
                    <parameters><type><text>work</text></type>
                    </parameters>
                    <text>Viagenie</text>
                </org>
                <adr>
                    <parameters>
                        <type><text>work</text></type>
                        <label><text>Simon Perreault
                            2875 boul. Laurier, suite D2-630
                            Quebec, QC, Canada
                            G1V 2M2</text></label>
                    </parameters>
                    <pobox/>
                    <ext/>
                    <street>2875 boul. Laurier, suite D2-630</street>
                    <locality>Quebec</locality>
                    <region>QC</region>
                    <code>G1V 2M2</code>
                    <country>Canada</country>
                </adr>
                <tel>
                    <parameters>
                        <type>
                            <text>work</text>
                            <text>voice</text>
                        </type>
                    </parameters>
                    <uri>tel:+1-418-656-9254;ext=102</uri>
                </tel>
                <tel>
                    <parameters>
                        <type>
                            <text>work</text>
                            <text>text</text>
                            <text>voice</text>
                            <text>cell</text>
                            <text>video</text>
                        </type>
                    </parameters>
                    <uri>tel:+1-418-262-6501</uri>
                </tel>
                <email>
                    <parameters><type><text>work</text></type>
                    </parameters>
                    <text>simon.perreault@viagenie.ca</text>
                </email>
                <geo>
                    <parameters><type><text>work</text></type>
                    </parameters>
                    <uri>geo:46.766336,-71.28955</uri>
                </geo>
                <key>
                    <parameters><type><text>work</text></type>
                    </parameters>
                    <uri>
                    http://www.viagenie.ca/simon.perreault/simon.asc
                    </uri>
                </key>
                <tz><text>America/Montreal</text></tz>
                <url>
                    <parameters><type><text>home</text></type>
                    </parameters>
                    <uri>http://nomis80.org</uri>
                </url>
            </vcard>
        </vcards>
    </xc:SubscriberData>
</ad:emergencyCall.SubInfo>
 
Ciao
Hannes
 
From hannes.tschofenig@gmx.net Tue May 28 01:15:28 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEB121F92A5 for ; Tue, 28 May 2013 01:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.587 X-Spam-Level: X-Spam-Status: No, score=-98.587 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfWCFm41WbZV for ; Tue, 28 May 2013 01:15:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC9E21F8F69 for ; Tue, 28 May 2013 01:15:21 -0700 (PDT) Received: from 3capp-gmx-bs56.server.lan ([172.19.170.140]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LjP2f-1UA6hd1oeV-00dYzS for ; Tue, 28 May 2013 10:15:18 +0200 Received: from [194.251.119.196] by 3capp-gmx-bs56.server.lan with HTTP; Tue May 28 10:15:18 CEST 2013 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: ecrit@ietf.org Content-Type: text/html; charset=UTF-8 Date: Tue, 28 May 2013 10:15:18 +0200 (CEST) Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:7OXGZi6n64eYXz8UBgQnOANewHT93zsgyLTnDisiEsJ /sdUJ10VUqiFf9OpNxnx23cf8BqpXbIZOh4ZIZA/Ehy/vBWIdO knPXt9d7kXyUluNpY6nIKsaSCYACKwSOzunP6uz2Xo1cdVm0Ir B7/9BuCLE5F/PpEqeN4kV4sRjXgcxA7NkYYCfq86wXVjg2YzFY dcwdo1ScDiGyIT3Om3Co6erHT7xfi+OM0nvfY8QP4IsAR5JKWn 5+FFu8EGNP2ZVE4glJKJDZMgRoZ4gxOGQ2jmFI0orXRSrU7Vp3 AAQoRQ= Subject: [Ecrit] Additional Data -09 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 08:15:28 -0000
Hi all, 
 
I submitted an intermediate draft update of the additional data document with the following changes:
 * Updated abstract
 * Shortened introduction 
 * Updated terminology section
 * Moved all XML schemas into one section 
 * Updated IANA consideration text by avoiding duplicate text (which got out of sync)
 * Created a better separation between transport related aspects and the data structures. The data structures are now in Section 3 and the transport related information is in Section 4. 
 * The data structure section now contains the tables with the initial set of values previously found in the IANA consideration section. 
 * Updated <provided-by> schema, as discussed on the list. 
 * Updated acknowledgment section 
 
Ciao
Hannes
From internet-drafts@ietf.org Tue May 28 01:16:26 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69E721F8FDB; Tue, 28 May 2013 01:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaAKtQoub6u6; Tue, 28 May 2013 01:16:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1D821F870F; Tue, 28 May 2013 01:16:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130528081621.6664.47372.idtracker@ietfa.amsl.com> Date: Tue, 28 May 2013 01:16:21 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-09.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 08:16:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Randall Gellens Filename : draft-ietf-ecrit-additional-data-09.txt Pages : 81 Date : 2013-05-28 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any application service provider in the path of the call, or access network provider through which the call originated may have information about the call or the caller which the PSAP may be able to use. This document describes data structures and a mechanism to convey such data to the PSAP. The mechanism uses a Uniform Resource Identifier (URI), which may point to either an external resource or an object in the body of the SIP message. The mechanism thus allows the data to be passed by reference (when the URI points to an external resource) or by value (when it points into the body of the message). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in body of the SIP message) and also by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From br@brianrosen.net Tue May 28 05:44:54 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F3421F9702 for ; Tue, 28 May 2013 05:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.022 X-Spam-Level: X-Spam-Status: No, score=-98.022 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1iO408O9ceC for ; Tue, 28 May 2013 05:44:49 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id A1A8721F9701 for ; Tue, 28 May 2013 05:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=pYNRZN4YZR8yMwJIn158+R6MktUwUbkv/IQT4DZPZOk=; b=CP+IQU+/gX42GEulCIG01BBxbgSdsaqzP/X/G9p2NtvD7gkzXQTHYOGemxTkklg8mxj+S18GXCr38g2DybbU+Q8/yBR7VDv9njKzwqqrdDSjdU7wbJ0cpAcW7KEfy2p6szJ4oDQoggXM3RUztBbOHZs9DCDtcM3MJWAL5KeU7Us=; Received: from neustargw.va.neustar.com ([209.173.53.233]:52451 helo=[10.33.193.4]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UhJGi-00028K-Dp; Tue, 28 May 2013 08:44:48 -0400 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_EB2125C6-B8F5-4890-B2B0-5E5405EF0719" From: Brian Rosen X-Priority: 3 In-Reply-To: Date: Tue, 28 May 2013 08:44:46 -0400 Message-Id: References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: ecrit@ietf.org Subject: Re: [Ecrit] Data Provider Contact URI X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 12:44:54 -0000 --Apple-Mail=_EB2125C6-B8F5-4890-B2B0-5E5405EF0719 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Because it might not be a telephone number, it very well could be a SIP = URI. Brian On May 28, 2013, at 2:44 AM, Hannes Tschofenig = wrote: > Hi all,=20 > =20 > I just had a chat with James about the data provider contact URI and = he asked me why the URI must be a SIP URI. Although the text talks about = how to encode a telephone number in the SIP URI I wasn't able to explain = James why we couldn't simply put a tel URI in there.=20 > =20 > Here is the text from the current draft:=20 > = http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-08#section-5.5= > =20 > -------- > =20 > 5.5. Data Provider Contact URI > =20 > Data Element: Data Provider Contact URI > =20 > Use: Required XML Element: > =20 > Description: For a service provider the contact SHOULD be a contact = URI. This MUST be a SIP URI. If a telephone number is the contact = address it should be provided in the form of = sip:telephonenumber@serviceprovider:user=3Dphone. If the call is from a = device, this would reflect the contact information of the owner of the = device. When provided by a service provider, this would be a URI to a = 24/7 support organization tasked to provide PSAP support for this = emergency call. > =20 > -------- > =20 > Any objection to allow other URIs to be included in the = =E2=80=8B element? The XML schema only allows one occurence = and I wonder why we shouldn't allow multiple occurences here.=20 > Ciao > Hannes > =20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_EB2125C6-B8F5-4890-B2B0-5E5405EF0719 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hannes.Tschofenig@gmx.net>= ; wrote:
Hi all, 
 
I just had a chat with James about the data provider contact URI = and he asked me why the URI must be a SIP URI. Although the text talks = about how to encode a telephone number in the SIP URI I wasn't able = to explain James why we couldn't simply put a tel URI in = there. 
 
Here is the text from the current draft: 

sip:telephonenum= ber@serviceprovider:user=3Dphone. If the call is from a device, this = would reflect the contact information of the owner of the device. When = provided by a service provider, this would be a URI to a 24/7 support = organization tasked to provide PSAP support for this emergency = call.

 
--------
 
Any objection to = allow other URIs to be included in the =E2=80=8B<ContactURI= > element? The XML schema only allows one occurence and I wonder why = we shouldn't allow multiple occurences here. 
Ciao
Hannes
 
_______________________________________________
Ecrit mailing = list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit

= --Apple-Mail=_EB2125C6-B8F5-4890-B2B0-5E5405EF0719-- From br@brianrosen.net Tue May 28 05:47:31 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C8C21F970F for ; Tue, 28 May 2013 05:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.299 X-Spam-Level: X-Spam-Status: No, score=-98.299 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0v9N6JJHyIl for ; Tue, 28 May 2013 05:47:28 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id A657A21F9703 for ; Tue, 28 May 2013 05:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=6ks5rpWAAE4ZsZq3bq2jU523A2Zontlwhvz44Rawa08=; b=hFKeY12PCw5LB/8/ocdVwHdUQrrbF1CZM2Ssz1l5nGxPJPqBYrv+1tZSJniKDSIGOxhMHi/msVpmzbK5fzD5x1nSiNIdAFahY3EhHtD22wFWHklJijroj2FSO1Dx13wuRp7h1HT80OE693ALHz956lZyqFfaj+sL/HSfc9+XQdY=; Received: from neustargw.va.neustar.com ([209.173.53.233]:57696 helo=[10.33.193.4]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UhJJH-0002KJ-0A; Tue, 28 May 2013 08:47:27 -0400 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_628EB056-6659-4373-A206-06DC74CCB0CA" From: Brian Rosen X-Priority: 3 In-Reply-To: Date: Tue, 28 May 2013 08:47:25 -0400 Message-Id: <44D83272-0941-4E26-B8F2-EC5E3377AE65@brianrosen.net> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: Transport Related Question X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 12:47:32 -0000 --Apple-Mail=_628EB056-6659-4373-A206-06DC74CCB0CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We need the MIME types to separate them in the body and reference them = with the CID. Wrapping the XML object with MIME provides no benefit = when you get them by reference. =20 Brian On May 28, 2013, at 4:04 AM, Hannes Tschofenig = wrote: > Hi all,=20 > =20 > in offlist discussions Randy raised an interesting question regarding = -08 (http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-08) I = would like to bring to your attention.=20 > Randy wrote:=20 > =20 > In Section 4 first numbered hanging indent there is text: > =20 > " > To be conveyed in a SIP body additional data about a call is > defined as a series of MIME objects, each with an XML data > structure contained inside. > " > =20 > and soon after there is this text: > =20 > " > When additional data is > provided by reference (in SIP signaling or Provided-By), each > HTTPS URL references one block; the data is retrieved with an > HTTP GET operation, which returns one of the blocks as an XML > object. > " > =20 > I thought that even when HTTPS is used, the XML data is still=20 > identified as a MIME type? That is, the HTTP response indicates that=20= > data of MIME type 'application/emergencyCall.ProviderInfo+xml' or=20 > whatever is being sent? > =20 > If I'm incorrect and the data is not identified as a MIME type, then=20= > the first text should be reworded for clarity as: > =20 > " > To be conveyed in a SIP body, the additional data is > defined as a series of MIME objects, one for each of the > XML data structures. > " > =20 > Otherwise (if the data is identified using MIME types) then we should=20= > change the first text to: > =20 > " > For transport in SIP or HTTP, the additional data is > defined as a series of MIME objects, one for each of the > data structures. > "=20 > =20 > I think it was slightly misleading to talk about the MIME type=20 > "containing" the XML data structure, since there is no additional=20 > encapsulation (aside from any 8-bit character considerations);=20 > rather, the MIME type is used to identify the data. This is separate=20= > from the use of MIME body parts inside the SIP body to delineate the=20= > various parts. > =20 > My understanding so far was that MIME encapsulation is used for data = that is carried in SIP and in HTTP.=20 > =20 > Here is an example. Imagine that a PSAP obtains an HTTPS URI pointing = to Owner/Subscriber Information data. > =20 > This would lead to the following request: =20 > =20 > GET /path/file.html HTTP/1.1 > Host: www.example.com > Accept: text/*, text/html, application/emergencyCall.SubInfo+xml > =20 > Here is an example response:=20 > =20 > HTTP/1.1 200 OK > Date: Mon, 27 Jul 2009 12:28:53 GMT > Server: Apache > Cache-control: private > Content-Type: application/emergencyCall.SubInfo+xml;charset=3Dutf-8 > Content-Length: tbd > =20 > > xmlns:ad=3D"urn:ietf:params:xml:ns:emergencyCall.SubInfo" > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"> > > > > Simon Perreault > > Perreault > Simon > > > ing. jr > M.Sc. > > --0203 > > 20090808T1430-0500 > > M > > 1 > > fr > > > 2 > > en > > > work > > Viagenie > > > > work > > > > > 2875 boul. Laurier, suite D2-630 > Quebec > QC > G1V 2M2 > Canada > > > > > work > voice > > > tel:+1-418-656-9254;ext=3D102 > > > > > work > text > voice > cell > video > > > tel:+1-418-262-6501 > > > work > > simon.perreault@viagenie.ca > > > work > > geo:46.766336,-71.28955 > > > work > > > http://www.viagenie.ca/simon.perreault/simon.asc > > > America/Montreal > > home > > http://nomis80.org > > > > > > =20 > Ciao > Hannes > =20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_628EB056-6659-4373-A206-06DC74CCB0CA Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii We need the MIME types to separate them in the body and reference them with the CID.  Wrapping the XML object with MIME provides no benefit when you get them by reference.  

Brian

On May 28, 2013, at 4:04 AM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:

Hi all, 
 
in offlist discussions Randy raised an interesting question regarding -08 (http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-08) I would like to bring to your attention. 
Randy wrote: 
 
In Section 4 first numbered hanging indent there is text:
 
"
        To be conveyed in a SIP body additional data about a call is
        defined as a series of MIME objects, each with an XML data
        structure contained inside.
"
 
and soon after there is this text:
 
"
       When additional data is
        provided by reference (in SIP signaling or Provided-By), each
        HTTPS URL references one block; the data is retrieved with an
        HTTP GET operation, which returns one of the blocks as an XML
        object.
"
 
I thought that even when HTTPS is used, the XML data is still 
identified as a MIME type?  That is, the HTTP response indicates that 
data of MIME type 'application/emergencyCall.ProviderInfo+xml' or 
whatever is being sent?
 
If I'm incorrect and the data is not identified as a MIME type, then 
the first text should be reworded for clarity as:
 
"
       To be conveyed in a SIP body, the additional data is
        defined as a series of MIME objects, one for each of the
        XML data structures.
"
 
Otherwise (if the data is identified using MIME types) then we should 
change the first text to:
 
"
        For transport in SIP or HTTP, the additional data is
        defined as a series of MIME objects, one for each of the
        data structures.
" 
 
I think it was slightly misleading to talk about the MIME type 
"containing" the XML data structure, since there is no additional 
encapsulation (aside from any 8-bit character considerations); 
rather, the MIME type is used to identify the data.  This is separate 
from the use of MIME body parts inside the SIP body to delineate the 
various parts.
 
My understanding so far was that MIME encapsulation is used for data that is carried in SIP and in HTTP. 
 
Here is an example. Imagine that a PSAP obtains an HTTPS URI pointing to Owner/Subscriber Information data.
 
This would lead to the following request:  
 
GET /path/file.html HTTP/1.1
Host: www.example.com
Accept: text/*, text/html, application/emergencyCall.SubInfo+xml
 
Here is an example response: 
 
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Cache-control: private
Content-Type: application/emergencyCall.SubInfo+xml;charset=utf-8
Content-Length: tbd
 
<?xml version="1.0" encoding="UTF-8"?>
<ad:emergencyCall.SubInfo 
     xmlns:ad="urn:ietf:params:xml:ns:emergencyCall.SubInfo"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <xc:SubscriberData xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">
        <vcards xmlns="urn:ietf:params:xml:ns:vcard-4.0">
            <vcard>
                <fn><text>Simon Perreault</text></fn>
                <n>
                    <surname>Perreault</surname>
                    <given>Simon</given>
                    <additional/>
                    <prefix/>
                    <suffix>ing. jr</suffix>
                    <suffix>M.Sc.</suffix>
                </n>
                <bday><date>--0203</date></bday>
                <anniversary>
                    <date-time>20090808T1430-0500</date-time>
                </anniversary>
                <gender><sex>M</sex></gender>
                <lang>
                    <parameters><pref><integer>1</integer></pref>
                    </parameters>
                    <language-tag>fr</language-tag>
                </lang>
                <lang>
                    <parameters><pref><integer>2</integer></pref>
                    </parameters>
                    <language-tag>en</language-tag>
                </lang>
                <org>
                    <parameters><type><text>work</text></type>
                    </parameters>
                    <text>Viagenie</text>
                </org>
                <adr>
                    <parameters>
                        <type><text>work</text></type>
                        <label><text>Simon Perreault
                            2875 boul. Laurier, suite D2-630
                            Quebec, QC, Canada
                            G1V 2M2</text></label>
                    </parameters>
                    <pobox/>
                    <ext/>
                    <street>2875 boul. Laurier, suite D2-630</street>
                    <locality>Quebec</locality>
                    <region>QC</region>
                    <code>G1V 2M2</code>
                    <country>Canada</country>
                </adr>
                <tel>
                    <parameters>
                        <type>
                            <text>work</text>
                            <text>voice</text>
                        </type>
                    </parameters>
                    <uri>tel:+1-418-656-9254;ext=102</uri>
                </tel>
                <tel>
                    <parameters>
                        <type>
                            <text>work</text>
                            <text>text</text>
                            <text>voice</text>
                            <text>cell</text>
                            <text>video</text>
                        </type>
                    </parameters>
                    <uri>tel:+1-418-262-6501</uri>
                </tel>
                <email>
                    <parameters><type><text>work</text></type>
                    </parameters>
                    <text>simon.perreault@viagenie.ca</text>
                </email>
                <geo>
                    <parameters><type><text>work</text></type>
                    </parameters>
                    <uri>geo:46.766336,-71.28955</uri>
                </geo>
                <key>
                    <parameters><type><text>work</text></type>
                    </parameters>
                    <uri>
                    http://www.viagenie.ca/simon.perreault/simon.asc
                    </uri>
                </key>
                <tz><text>America/Montreal</text></tz>
                <url>
                    <parameters><type><text>home</text></type>
                    </parameters>
                    <uri>http://nomis80.org</uri>
                </url>
            </vcard>
        </vcards>
    </xc:SubscriberData>
</ad:emergencyCall.SubInfo>
 
Ciao
Hannes
 
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--Apple-Mail=_628EB056-6659-4373-A206-06DC74CCB0CA-- From hannes.tschofenig@gmx.net Tue May 28 06:04:25 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929B321F9724 for ; Tue, 28 May 2013 06:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.872 X-Spam-Level: X-Spam-Status: No, score=-99.872 tagged_above=-999 required=5 tests=[AWL=1.269, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsN-F1vxIOX7 for ; Tue, 28 May 2013 06:04:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id A7B7A21F9720 for ; Tue, 28 May 2013 06:04:20 -0700 (PDT) Received: from 3capp-gmx-bs42.server.lan ([172.19.170.94]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MMqSP-1UneIP28fX-008eYC; Tue, 28 May 2013 15:04:18 +0200 Received: from [194.251.119.196] by 3capp-gmx-bs42.server.lan with HTTP; Tue May 28 15:04:18 CEST 2013 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: "Brian Rosen" Content-Type: text/html; charset=UTF-8 Date: Tue, 28 May 2013 15:04:18 +0200 (CEST) Importance: normal Sensitivity: Normal In-Reply-To: References: , X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:LVz8/PkUmixYSvt5LPgfTkwqv1x9jUtsQxVll8F3w1g o8bR46CmX3ETzKkxNvPCJVDRNA+5Ts2ym9swVTsDa17D70EZSo G2JuXLGcqtIOJ+U9kIlBCFuDVvpP9rBGnbxJexk0VAFUQB35KL W/FfOHh8Xjxe/+4fW1RSm1RzYhFRjGjZD39JD9YiWK1U0yYnVw m3fr9ofgPg1y/+q+ed8NRFtGT5Yo/mHm1E4T7MKqr5STCC7+6x Krw2n6n8bJTIPTjQiGnxT8Ovbo5pOU/MlgWNMNZUC4U1u0QXXr 6SzLD0= Cc: ecrit@ietf.org Subject: Re: [Ecrit] Data Provider Contact URI X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 13:04:25 -0000
Correct. For this reason I would like to allow a SIP URI, a tel URI, or other URIs.
 
Gesendet: Dienstag, 28. Mai 2013 um 14:44 Uhr
Von: "Brian Rosen" <br@brianrosen.net>
An: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
Cc: ecrit@ietf.org
Betreff: Re: [Ecrit] Data Provider Contact URI
Because it might not be a telephone number, it very well could be a SIP URI.
 
Brian
 
On May 28, 2013, at 2:44 AM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:
 
Hi all, 
 
I just had a chat with James about the data provider contact URI and he asked me why the URI must be a SIP URI. Although the text talks about how to encode a telephone number in the SIP URI I wasn't able to explain James why we couldn't simply put a tel URI in there. 
 
Here is the text from the current draft: 

5.5. Data Provider Contact URI

 
Data Element: Data Provider Contact URI
 
Use: Required XML Element: <ContactURI>
 
Description: For a service provider the contact SHOULD be a contact URI. This MUST be a SIP URI. If a telephone number is the contact address it should be provided in the form of sip:telephonenumber@serviceprovider:user=phone. If the call is from a device, this would reflect the contact information of the owner of the device. When provided by a service provider, this would be a URI to a 24/7 support organization tasked to provide PSAP support for this emergency call.
 
--------
 
Any objection to allow other URIs to be included in the ​<ContactURI> element? The XML schema only allows one occurence and I wonder why we shouldn't allow multiple occurences here. 
Ciao
Hannes
 
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
From James.Winterbottom@commscope.com Tue May 28 15:35:12 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8849C21F8A6B for ; Tue, 28 May 2013 15:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpBYas4gmmQK for ; Tue, 28 May 2013 15:35:08 -0700 (PDT) Received: from cdcsmgw02.commscope.com (smtp1.andrew.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id A03C521F8A68 for ; Tue, 28 May 2013 15:35:07 -0700 (PDT) X-AuditID: 0a0404e9-b7fa16d000005100-e9-51a5311271e5 Received: from CDCE10HC2.commscope.com ( [10.86.28.22]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id BE.D5.20736.21135A15; Tue, 28 May 2013 17:34:59 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 28 May 2013 17:34:58 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 29 May 2013 06:34:55 +0800 From: "Winterbottom, James" To: Hannes Tschofenig , Brian Rosen Date: Wed, 29 May 2013 06:34:54 +0800 Thread-Topic: [Ecrit] Data Provider Contact URI Thread-Index: Ac5bo+UnAQl7iPJNSBS/ioVvKN0imgAT1FaQ Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121409BAD2C@SISPE7MB1.commscope.com> 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: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC81880121409BAD2CSISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUgTYRzHeXa33W3s6pzOPY0KWhhquKlECYUIQQiFZUX0Qui1XW7gNtmp OQtxQVYaktCizYaSTq2MDRFSC7MJlopv//jWmOi0cqP+6MUVVHa3S9t/3+f5fn7f3/e4B0dk H4RK3GAqpS0mqlglkqCSM9sT0+Iz3PnpkRo8a2XhvijL9mhFmOXuDQhzkNyFtd9YbkvXK1Fu a+tPwQnkvOSQji42lNMWTXahRD8z/hWUDNhBxWtXjaAaDDSAWoDjkNwHI2uJtUDMykQ4GfCI aoEEl5F9ANaN+v8dvAC+e+ZE+YMHwEZ3r4AbEZHZcNAzi3A6gTwNu791Ru8RMgmO24Iop1FW d/s6ozqeVMOwdwjwvAa+DbdjvM6EjaHxqCbIk3D61xDGLwsAuO6+LeCqismzcGqG5hjAVo2M bOxSwPnlJgH/CSRsfTmB8FoOV4N/hDwvh/6bHsDzZvje7wX8rjg47FiOdpORafB673fhXaBw xsQ6Y0acMSNOthFCpkBPn4ZHdsF7dYsYr5PhjYcuLPa+GWBPgEKr0zLGoivpmWqt2WhktOYS mlNdgPu7KLraA8a8e32AxIFKSnREWvNlQqqcsRp9YBsuUMmJ6RR3vmzLJbPOqqcYfYGlrJhm fADiiCqBoONYj9BR1kraYt6wknGcHF1eGAFK1GQ20SpISNNZLM5CF9EVlw3F7OPaQAW4mIuS slGAYwimhDIyhiLeHwFJ+NSg/TOQRYOUCkLGQSQH6ctMmzkhoGDLxxME50rZ17uZEGLDBWy4 Amnhwkup/5ayGoipY+iAK4yFHLfsWDvd1l0vPHpRO9H5dPbq4YzGT8GQ3aFZD56SLA67KvzG B7ad5xzyPIAeOb6VCBeoU/e3zRTGLdEdL+aSB2yRHeo9PUvonQuVX5guV72qenelpX/6wI+m xwnN02+0Y5PWhqq5PPH8tUCfYfJ5oP/gx6ocFcroqYxUxMJQfwH4dQPLegMAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Data Provider Contact URI X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 22:35:12 -0000 --_000_5A55A45AE77F5941B18E5457ECAC81880121409BAD2CSISPE7MB1co_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEhhbm5lcy4NCg0KSSB0aGluayB0aGF0IHRoZSBrZXkgaGVyZSBpcyB0aGF0IHRoZSBV UkkgaXMgZXhwZWN0ZWQgdG8gY29udGFpbiB0aGUgaW1tZWRpYXRlIG1lYW5zIG9mIGNvbnRhY3Rp bmcgdGhlIHByb3ZpZGVyIHNvIGl0IHNob3VsZG7igJl0IGJlIG9wZW5lZCB0byBhbGwgVVJJIHR5 cGVzLiBGb3IgZXhhbXBsZSBlbWFpbCB3b3VsZCBub3QgYmUgYXBwcm9wcmlhdGUgaGVyZS4gSSB3 b3VsZCBiZSBva2F5IHdpdGggcmVzdHJpY3RpbmcgaXQgdG8gU0lQIGFuZCB0ZWwgZm9yIG5vdywg dGhvdWdoIEkgY2FuIHNlZSB0aGF0IHdpdGggd2ViUlRDIGVtZXJnaW5nIHdlIG1hZGUgdG8gcmV2 aXNpdCB0aGUgbGlzdC4NCg0KQ2hlZXJzDQpKYW1lcw0KDQpGcm9tOiBlY3JpdC1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhhbm5l cyBUc2Nob2ZlbmlnDQpTZW50OiBUdWVzZGF5LCAyOCBNYXkgMjAxMyAxMTowNCBQTQ0KVG86IEJy aWFuIFJvc2VuDQpDYzogZWNyaXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRWNyaXRdIERhdGEg UHJvdmlkZXIgQ29udGFjdCBVUkkNCg0KQ29ycmVjdC4gRm9yIHRoaXMgcmVhc29uIEkgd291bGQg bGlrZSB0byBhbGxvdyBhIFNJUCBVUkksIGEgdGVsIFVSSSwgb3Igb3RoZXIgVVJJcy4NCg0KR2Vz ZW5kZXQ6IERpZW5zdGFnLCAyOC4gTWFpIDIwMTMgdW0gMTQ6NDQgVWhyDQpWb246ICJCcmlhbiBS b3NlbiIgPGJyQGJyaWFucm9zZW4ubmV0PG1haWx0bzpickBicmlhbnJvc2VuLm5ldD4+DQpBbjog Ikhhbm5lcyBUc2Nob2ZlbmlnIiA8SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86SGFu bmVzLlRzY2hvZmVuaWdAZ214Lm5ldD4+DQpDYzogZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0 QGlldGYub3JnPg0KQmV0cmVmZjogUmU6IFtFY3JpdF0gRGF0YSBQcm92aWRlciBDb250YWN0IFVS SQ0KQmVjYXVzZSBpdCBtaWdodCBub3QgYmUgYSB0ZWxlcGhvbmUgbnVtYmVyLCBpdCB2ZXJ5IHdl bGwgY291bGQgYmUgYSBTSVAgVVJJLg0KDQpCcmlhbg0KDQpPbiBNYXkgMjgsIDIwMTMsIGF0IDI6 NDQgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0PiB3cm90 ZToNCg0KSGkgYWxsLA0KDQpJIGp1c3QgaGFkIGEgY2hhdCB3aXRoIEphbWVzIGFib3V0IHRoZSBk YXRhIHByb3ZpZGVyIGNvbnRhY3QgVVJJIGFuZCBoZSBhc2tlZCBtZSB3aHkgdGhlIFVSSSBtdXN0 IGJlIGEgU0lQIFVSSS4gQWx0aG91Z2ggdGhlIHRleHQgdGFsa3MgYWJvdXQgaG93IHRvIGVuY29k ZSBhIHRlbGVwaG9uZSBudW1iZXIgaW4gdGhlIFNJUCBVUkkgSSB3YXNuJ3QgYWJsZSB0byBleHBs YWluIEphbWVzIHdoeSB3ZSBjb3VsZG4ndCBzaW1wbHkgcHV0IGEgdGVsIFVSSSBpbiB0aGVyZS4N Cg0KSGVyZSBpcyB0aGUgdGV4dCBmcm9tIHRoZSBjdXJyZW50IGRyYWZ0Og0KaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1lY3JpdC1hZGRpdGlvbmFsLWRhdGEtMDgjc2VjdGlv bi01LjUNCg0KLS0tLS0tLS0NCg0KNS41PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtZWNyaXQtYWRkaXRpb25hbC1kYXRhLTA4I3NlY3Rpb24tNS41Pi4gRGF0YSBQcm92aWRl ciBDb250YWN0IFVSSQ0KDQpEYXRhIEVsZW1lbnQ6IERhdGEgUHJvdmlkZXIgQ29udGFjdCBVUkkN Cg0KVXNlOiBSZXF1aXJlZCBYTUwgRWxlbWVudDogPENvbnRhY3RVUkk+DQoNCkRlc2NyaXB0aW9u OiBGb3IgYSBzZXJ2aWNlIHByb3ZpZGVyIHRoZSBjb250YWN0IFNIT1VMRCBiZSBhIGNvbnRhY3Qg VVJJLiBUaGlzIE1VU1QgYmUgYSBTSVAgVVJJLiBJZiBhIHRlbGVwaG9uZSBudW1iZXIgaXMgdGhl IGNvbnRhY3QgYWRkcmVzcyBpdCBzaG91bGQgYmUgcHJvdmlkZWQgaW4gdGhlIGZvcm0gb2Ygc2lw OnRlbGVwaG9uZW51bWJlckBzZXJ2aWNlcHJvdmlkZXI6dXNlcj1waG9uZS4gSWYgdGhlIGNhbGwg aXMgZnJvbSBhIGRldmljZSwgdGhpcyB3b3VsZCByZWZsZWN0IHRoZSBjb250YWN0IGluZm9ybWF0 aW9uIG9mIHRoZSBvd25lciBvZiB0aGUgZGV2aWNlLiBXaGVuIHByb3ZpZGVkIGJ5IGEgc2Vydmlj ZSBwcm92aWRlciwgdGhpcyB3b3VsZCBiZSBhIFVSSSB0byBhIDI0Lzcgc3VwcG9ydCBvcmdhbml6 YXRpb24gdGFza2VkIHRvIHByb3ZpZGUgUFNBUCBzdXBwb3J0IGZvciB0aGlzIGVtZXJnZW5jeSBj YWxsLg0KDQotLS0tLS0tLQ0KDQpBbnkgb2JqZWN0aW9uIHRvIGFsbG93IG90aGVyIFVSSXMgdG8g YmUgaW5jbHVkZWQgaW4gdGhlIOKAizxDb250YWN0VVJJPiBlbGVtZW50PyBUaGUgWE1MIHNjaGVt YSBvbmx5IGFsbG93cyBvbmUgb2NjdXJlbmNlIGFuZCBJIHdvbmRlciB3aHkgd2Ugc2hvdWxkbid0 IGFsbG93IG11bHRpcGxlIG9jY3VyZW5jZXMgaGVyZS4NCkNpYW8NCkhhbm5lcw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBs aXN0DQpFY3JpdEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9lY3JpdA0K --_000_5A55A45AE77F5941B18E5457ECAC81880121409BAD2CSISPE7MB1co_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQpoMw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUt bGluazoiSGVhZGluZyAzIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMy41cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkhlYWRp bmczQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyAzIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDMiOw0KCWZvbnQtZmFtaWx5OiJD YW1icmlhIiwic2VyaWYiOw0KCWNvbG9yOiM0RjgxQkQ7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpz cGFuLmgzDQoJe21zby1zdHlsZS1uYW1lOmgzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48 Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2Vj dGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhhbmtzIEhh bm5lcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgdGhpbmsgdGhhdCB0aGUga2V5IGhlcmUgaXMgdGhh dCB0aGUgVVJJIGlzIGV4cGVjdGVkIHRvIGNvbnRhaW4gdGhlIGltbWVkaWF0ZSBtZWFucyBvZiBj b250YWN0aW5nIHRoZSBwcm92aWRlciBzbyBpdCBzaG91bGRu4oCZdCBiZSBvcGVuZWQgdG8gYWxs IFVSSSB0eXBlcy4gRm9yIGV4YW1wbGUgZW1haWwgd291bGQgbm90IGJlIGFwcHJvcHJpYXRlIGhl cmUuIEkgd291bGQgYmUgb2theSB3aXRoIHJlc3RyaWN0aW5nIGl0IHRvIFNJUCBhbmQgdGVsIGZv ciBub3csIHRob3VnaCBJIGNhbiBzZWUgdGhhdCB3aXRoIHdlYlJUQyBlbWVyZ2luZyB3ZSBtYWRl IHRvIHJldmlzaXQgdGhlIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5DaGVlcnM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFt ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRm Lm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5IYW5uZXMgVHNjaG9mZW5pZzxicj48Yj5TZW50Ojwv Yj4gVHVlc2RheSwgMjggTWF5IDIwMTMgMTE6MDQgUE08YnI+PGI+VG86PC9iPiBCcmlhbiBSb3Nl bjxicj48Yj5DYzo8L2I+IGVjcml0QGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW0Vj cml0XSBEYXRhIFByb3ZpZGVyIENvbnRhY3QgVVJJPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1p bHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+Q29ycmVjdC4gRm9yIHRoaXMgcmVhc29uIEkgd291 bGQgbGlrZSB0byBhbGxvdyBhIFNJUCBVUkksIGEgdGVsIFVSSSwgb3Igb3RoZXIgVVJJcy4gPG86 cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+Jm5ic3A7 IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQzNEOUU1IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6Ni4wcHQ7bWFyZ2luLXRvcDo2LjBwdDttYXJnaW4tcmlnaHQ6My4wcHQ7bWFyZ2luLWJvdHRv bTozLjBwdDt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOy13 ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2UnIG5hbWU9cXVvdGU+PGRpdiBzdHls ZT0nbWFyZ2luLWJvdHRvbTo2LjBwdCc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+R2Vz ZW5kZXQ6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5 OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPiZuYnNwO0RpZW5zdGFnLCAyOC4gTWFpIDIwMTMgdW0g MTQ6NDQgVWhyPGJyPjxiPlZvbjo8L2I+Jm5ic3A7JnF1b3Q7QnJpYW4gUm9zZW4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpickBicmlhbnJvc2VuLm5ldCI+YnJAYnJpYW5yb3Nlbi5uZXQ8L2E+ Jmd0Ozxicj48Yj5Bbjo8L2I+Jm5ic3A7JnF1b3Q7SGFubmVzIFRzY2hvZmVuaWcmcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0Ij5IYW5uZXMuVHNjaG9m ZW5pZ0BnbXgubmV0PC9hPiZndDs8YnI+PGI+Q2M6PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpl Y3JpdEBpZXRmLm9yZyI+ZWNyaXRAaWV0Zi5vcmc8L2E+PGJyPjxiPkJldHJlZmY6PC9iPiZuYnNw O1JlOiBbRWNyaXRdIERhdGEgUHJvdmlkZXIgQ29udGFjdCBVUkk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdiBuYW1lPXF1b3RlZC1jb250ZW50PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5z LXNlcmlmIic+QmVjYXVzZSBpdCBtaWdodCBub3QgYmUgYSB0ZWxlcGhvbmUgbnVtYmVyLCBpdCB2 ZXJ5IHdlbGwgY291bGQgYmUgYSBTSVAgVVJJLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWls eToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdDtm b250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz5CcmlhbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjcuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPiZuYnNwOyA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPk9uIE1h eSAyOCwgMjAxMywgYXQgMjo0NCBBTSwgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Ikhh bm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQiIHRhcmdldD0iX3BhcmVudCI+SGFubmVzLlRzY2hvZmVu aWdAZ214Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseToi VmVyZGFuYSIsInNhbnMtc2VyaWYiJz4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0 O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPkhpIGFsbCwmbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2Vy aWYiJz5JIGp1c3QgaGFkIGEgY2hhdCB3aXRoIEphbWVzIGFib3V0IHRoZSBkYXRhIHByb3ZpZGVy IGNvbnRhY3QgVVJJIGFuZCBoZSBhc2tlZCBtZSB3aHkgdGhlIFVSSSBtdXN0IGJlIGEgU0lQIFVS SS4gQWx0aG91Z2ggdGhlIHRleHQgdGFsa3MgYWJvdXQgaG93IHRvIGVuY29kZSBhIHRlbGVwaG9u ZSZuYnNwO251bWJlciBpbiB0aGUgU0lQIFVSSSBJIHdhc24ndCBhYmxlIHRvIGV4cGxhaW4gSmFt ZXMgd2h5IHdlIGNvdWxkbid0IHNpbXBseSBwdXQgYSB0ZWwgVVJJIGluIHRoZXJlLiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiIn PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fu cy1zZXJpZiInPkhlcmUgaXMgdGhlIHRleHQgZnJvbSB0aGUgY3VycmVudCBkcmFmdDombmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbGluZS1oZWlnaHQ6MTEuNXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0O2Zv bnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPjxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZWNyaXQtYWRkaXRpb25hbC1kYXRhLTA4I3NlY3Rpb24t NS41IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1lY3JpdC1hZGRpdGlvbmFsLWRhdGEtMDgjc2VjdGlvbi01LjU8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6Ny4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+LS0t LS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMt c2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2 PjxoMyBzdHlsZT0nbXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQnPjxhIG5hbWU9c2VjdGlvbi01LjU+ PC9hPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZWNyaXQt YWRkaXRpb25hbC1kYXRhLTA4I3NlY3Rpb24tNS41IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO3Rl eHQtZGVjb3JhdGlvbjpub25lJz41LjU8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPWgzPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+ LiBEYXRhIFByb3ZpZGVyIENvbnRhY3QgVVJJPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPjxvOnA+PC9v OnA+PC9zcGFuPjwvaDM+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz5E YXRhIEVsZW1lbnQ6IERhdGEgUHJvdmlkZXIgQ29udGFjdCBVUkk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3 LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz5Vc2U6IFJl cXVpcmVkIFhNTCBFbGVtZW50OiAmbHQ7Q29udGFjdFVSSSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3 LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz5EZXNjcmlw dGlvbjogRm9yIGEgc2VydmljZSBwcm92aWRlciB0aGUgY29udGFjdCBTSE9VTEQgYmUgYSBjb250 YWN0IFVSSS4gVGhpcyBNVVNUIGJlIGEgU0lQIFVSSS4gSWYgYSB0ZWxlcGhvbmUgbnVtYmVyIGlz IHRoZSBjb250YWN0IGFkZHJlc3MgaXQgc2hvdWxkIGJlIHByb3ZpZGVkIGluIHRoZSBmb3JtIG9m IDxhIGhyZWY9InNpcDp0ZWxlcGhvbmVudW1iZXJAc2VydmljZXByb3ZpZGVyOnVzZXI9cGhvbmUi PnNpcDp0ZWxlcGhvbmVudW1iZXJAc2VydmljZXByb3ZpZGVyOnVzZXI9cGhvbmU8L2E+LiBJZiB0 aGUgY2FsbCBpcyBmcm9tIGEgZGV2aWNlLCB0aGlzIHdvdWxkIHJlZmxlY3QgdGhlIGNvbnRhY3Qg aW5mb3JtYXRpb24gb2YgdGhlIG93bmVyIG9mIHRoZSBkZXZpY2UuIFdoZW4gcHJvdmlkZWQgYnkg YSBzZXJ2aWNlIHByb3ZpZGVyLCB0aGlzIHdvdWxkIGJlIGEgVVJJIHRvIGEgMjQvNyBzdXBwb3J0 IG9yZ2FuaXphdGlvbiB0YXNrZWQgdG8gcHJvdmlkZSBQU0FQIHN1cHBvcnQgZm9yIHRoaXMgZW1l cmdlbmN5IGNhbGwuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEi LCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6 IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+LS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1o ZWlnaHQ6MTEuNXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiJW ZXJkYW5hIiwic2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6MTEuNXB0Jz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiIn PkFueSBvYmplY3Rpb24gdG8gYWxsb3cgb3RoZXIgVVJJcyB0byBiZSBpbmNsdWRlZCBpbiB0aGUm bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+4oCLPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQ7 Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+Jmx0O0NvbnRhY3RVUkkmZ3Q7IGVs ZW1lbnQ/IFRoZSBYTUwgc2NoZW1hIG9ubHkgYWxsb3dzIG9uZSBvY2N1cmVuY2UgYW5kIEkgd29u ZGVyIHdoeSB3ZSBzaG91bGRuJ3QgYWxsb3cgbXVsdGlwbGUgb2NjdXJlbmNlcyBoZXJlLiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fu cy1zZXJpZiInPkNpYW88YnI+SGFubmVzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1p bHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjcuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPkVjcml0IG1haWxpbmcgbGlzdDxi cj48YSBocmVmPSJFY3JpdEBpZXRmLm9yZyIgdGFyZ2V0PSJfcGFyZW50Ij5FY3JpdEBpZXRmLm9y ZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9l Y3JpdCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9k aXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_5A55A45AE77F5941B18E5457ECAC81880121409BAD2CSISPE7MB1co_-- From James.Winterbottom@commscope.com Tue May 28 15:43:05 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8B411E80A5 for ; Tue, 28 May 2013 15:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZFIuQ6oO3b2 for ; Tue, 28 May 2013 15:43:01 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF7211E80A2 for ; Tue, 28 May 2013 15:42:53 -0700 (PDT) X-AuditID: 0a0404e8-b7fdb6d000001d37-d4-51a532ecf67c Received: from CDCE10HC2.commscope.com ( [10.86.28.22]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id CD.E5.07479.CE235A15; Tue, 28 May 2013 17:42:52 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 28 May 2013 17:42:51 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 29 May 2013 06:42:49 +0800 From: "Winterbottom, James" To: Brian Rosen , Hannes Tschofenig Date: Wed, 29 May 2013 06:42:47 +0800 Thread-Topic: [Ecrit] Additional Data: Transport Related Question Thread-Index: Ac5boYjRHBGMHXo+TVKQpQH7fl0SdQAUhS+g Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121409BAD2D@SISPE7MB1.commscope.com> References: <44D83272-0941-4E26-B8F2-EC5E3377AE65@brianrosen.net> In-Reply-To: <44D83272-0941-4E26-B8F2-EC5E3377AE65@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC81880121409BAD2DSISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRzGfc/Z5Ti2cTYvex1BOJMuajq7sCLELMJvqYRIBTm3kxvsIjtq 009akbAClVBQAm+zUZoTo5iZLRQjXaQS2cVw2by1athsXlKrc3bU9u3H+zz/53n/vC+Gin1s KaY1FBMmg1In4/BYvNxd0UnfU9uzUx7UHVXMuus5isrWWbaivXeKnY5mupc3uZltPU5OptW6 hmSh53kn1IROW0qYktPyeRpb/96iL7WI2evqQivAs3lgAeEYxA/DG55NlOFoODZl51gADxPj TwB81OJg04IY7wZwclnPCHYAbbf8wWkOngYH7e+D05H4Obg4XYPQjOLx8HWlh0Uzi+LOpp9c miPwdGhbWuIy/pNwbm15i1PhL2drMFOA58APlr8IU1YN4ETT72BoOJ4BhxwNwVBAXXVlpHOr TAI/zjQhzAo4tD4d3VonCn71/GEz/ij4qcoOGL8RDtm7EKZMBIcbZljMlknwam+AXQMkjSGx jSEjjSEjzHkibO7zcxhOgHdbvqHb/Oq5Bwk9bwbc+0CiUqtIfeGVFPlBlVGvJ1XGIoKmHkA/ L4u14ACu7oQBgGNAxhdkBazZYraylCzTD4AYDJFFCSb2t2eLhQVGdZlGSWoumUp0BDkAIIbK IgWEiNIEamVZOWEybkv7MAx3zbhHgJRlMBoIGRR0ySmbyEQUEubLWh31u7atCBZOR/GpKBvt EZBFSj2pLWT0EZCAPRy97QPY+GCdD4iDcVKJoJe24rRVU2LYSfMCCbVCBFPGpz7xTo6XqkCo CgnaRlcUK/9L0gpwhx/9Nn9shRj7cWhPrs2V6715bGXYY5QnrnquC8/mdZBt/o1YxWL1xQ63 Md7zOON08npeXO2ZumpHXED4krgwVLVQP2mJnF13kkLr52uxYSKby1duHtwQh606p+Zsncdj +szv+vunE+/ljAcWlzpa3hTMd/KnT/kXuLtfHPHKWKRGKT+AmkjlP6RKfCeBAwAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data: Transport Related Question X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 22:43:06 -0000 --_000_5A55A45AE77F5941B18E5457ECAC81880121409BAD2DSISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't entirely agree with this last point. For starters I don't think that you are "wrapping" the XML object with MIME= , you are simply signaling to the receiver that the contents of the body ar= e xml that refer to a specific type of object. This is kind and cost nothin= g since the MIME types already exist. Secondly, it can be used in the header of the actual request to indicate wh= at the receiver is expecting to get back. I will add that both HELD and LoST specify and use MIME types in their HTTP= bindings, so it isn't clear to me why this should be different. Cheers James From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of B= rian Rosen Sent: Tuesday, 28 May 2013 10:47 PM To: Hannes Tschofenig Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: Transport Related Question We need the MIME types to separate them in the body and reference them with= the CID. Wrapping the XML object with MIME provides no benefit when you g= et them by reference. Brian On May 28, 2013, at 4:04 AM, Hannes Tschofenig > wrote: Hi all, in offlist discussions Randy raised an interesting question regarding -08 (= http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-08) I would li= ke to bring to your attention. Randy wrote: In Section 4 first numbered hanging indent there is text: " To be conveyed in a SIP body additional data about a call is defined as a series of MIME objects, each with an XML data structure contained inside. " and soon after there is this text: " When additional data is provided by reference (in SIP signaling or Provided-By), each HTTPS URL references one block; the data is retrieved with an HTTP GET operation, which returns one of the blocks as an XML object. " I thought that even when HTTPS is used, the XML data is still identified as a MIME type? That is, the HTTP response indicates that data of MIME type 'application/emergencyCall.ProviderInfo+xml' or whatever is being sent? If I'm incorrect and the data is not identified as a MIME type, then the first text should be reworded for clarity as: " To be conveyed in a SIP body, the additional data is defined as a series of MIME objects, one for each of the XML data structures. " Otherwise (if the data is identified using MIME types) then we should change the first text to: " For transport in SIP or HTTP, the additional data is defined as a series of MIME objects, one for each of the data structures. " I think it was slightly misleading to talk about the MIME type "containing" the XML data structure, since there is no additional encapsulation (aside from any 8-bit character considerations); rather, the MIME type is used to identify the data. This is separate from the use of MIME body parts inside the SIP body to delineate the various parts. My understanding so far was that MIME encapsulation is used for data that i= s carried in SIP and in HTTP. Here is an example. Imagine that a PSAP obtains an HTTPS URI pointing to Ow= ner/Subscriber Information data. This would lead to the following request: GET /path/file.html HTTP/1.1 Host: www.example.com Accept: text/*, text/html, application/emergencyCall.SubInfo+xml Here is an example response: HTTP/1.1 200 OK Date: Mon, 27 Jul 2009 12:28:53 GMT Server: Apache Cache-control: private Content-Type: application/emergencyCall.SubInfo+xml;charset=3Dutf-8 Content-Length: tbd Simon Perreault Perreault Simon ing. jr M.Sc. --0203 20090808T1430-0500 M 1 fr 2 en work Viagenie work 2875 boul. Laurier, suite D2-630 Quebec QC G1V 2M2 Canada work voice tel:+1-418-656-9254;ext=3D102> work text voice cell video tel:+1-418-262-6501> work simon.perreault@viagenie.ca work geo:46.766336,-71.28955 work http://www.viagenie.ca/simon.perreault/simon.asc America/Montreal home http://nomis80.org Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_5A55A45AE77F5941B18E5457ECAC81880121409BAD2DSISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I donR= 17;t entirely agree with this last point.

For starters I don’t think that you are “wrappi= ng” the XML object with MIME, you are simply signaling to the receive= r that the contents of the body are xml that refer to a specific type of ob= ject. This is kind and cost nothing since the MIME types already exist.

 

<= p class=3DMsoNormal>Secondly, it can be used in the header of the ac= tual request to indicate what the receiver is expecting to get back.

 

I will add that both HELD and LoST specify and use = MIME types in their HTTP bindings, so it isn’t clear to me why this s= hould be different.

 

Cheers

James

 

 

 

 

= From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Tuesday, 28 May 2013 10:47 PM
To: Ha= nnes Tschofenig
Cc: ecrit@ietf.org
Subject: Re: [Ecrit]= Additional Data: Transport Related Question

 

We need t= he MIME types to separate them in the body and reference them with the CID.=  Wrapping the XML object with MIME provides no benefit when you get t= hem by reference.  

 = ;

Brian

 

On M= ay 28, 2013, at 4:04 AM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:



= Hi all, 

 

in offlist discussions Randy raised an = interesting question regarding -08 (http://tools.ietf.org/html/= draft-ietf-ecrit-additional-data-08) I would like to bring to your= attention. 

Randy wrote:=  

 

In Section 4 first numbered hanging indent the= re is text:

 

"

        To be conveyed in a SIP body add= itional data about a call is
        defined as a se= ries of MIME objects, each with an XML data
        = structure contained inside.

&q= uot;

 <= /p>

and soon after there is this text:

 

"

    =    When additional data is
        provide= d by reference (in SIP signaling or Provided-By), each
    &nb= sp;   HTTPS URL references one block; the data is retrieved with an        HTTP GET operation, which returns one of the b= locks as an XML
        object.

"

 

I thought that even= when HTTPS is used, the XML data is still 
identified as a MIME ty= pe?  That is, the HTTP response indicates that 
data of MIME t= ype 'application/emergencyCall.ProviderInfo+xml' or 
whatever is be= ing sent?

 

If I'm incorrect and the data is not ident= ified as a MIME type, then 
the first text should be reworded for c= larity as:

 

"

       To be conveyed in a SIP body, the addi= tional data is
        defined as a series of MIME o= bjects, one for each of the
        XML data structu= res.

"<= /p>

 

Otherwise (if the data is identified using MIME types) then we should&= nbsp;
change the first text to:

 

"<= /span>

        For transport= in SIP or HTTP, the additional data is
        defi= ned as a series of MIME objects, one for each of the
     = ;   data structures.

&quo= t; 

 

I think it was slightly misleading to talk= about the MIME type 
"containing" the XML data structure= , since there is no additional 
encapsulation (aside from any 8-bit= character considerations); 
rather, the MIME type is used to ident= ify the data.  This is separate 
from the use of MIME body par= ts inside the SIP body to delineate the 
various parts.<= /span>

 

My understanding so far was that MIME encapsulation is used for = data that is carried in SIP and in HTTP. 

<= div>

 

Here i= s an example. Imagine that a PSAP obtains an HTTPS URI pointing to Own= er/Subscriber Information data.

 

This would lead to = the following request:  

 

GET /path/fil= e.html HTTP/1.1
Host: www.example.com=

Accept: text/*, text/html,= application/emergencyCall.SubInfo+xml

 

Here is an exam= ple response: 

 = ;

HTTP/1.1 200 OK
Date= : Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Cache-control: private=
Content-Type: application/emergencyCall.SubInfo+xml;charset=3Dutf-8
= Content-Length: tbd

 =

<?xml version=3D"1.0"= encoding=3D"UTF-8"?>
<ad:emergencyCall.SubInfo      xmlns:ad=3D"urn:ietf:params:xml:ns:emergencyCall.= SubInfo"
     xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance= ">
    <xc:SubscriberData xmlns:xc=3D"urn:= ietf:params:xml:ns:vcard-4.0">
        <v= cards xmlns=3D"urn:ietf:params:xml:ns:vcard-4.0">
  &n= bsp;         <vcard>
      &nbs= p;         <fn><text>Simon Perreault</te= xt></fn>
               = ; <n>
                &nbs= p;   <surname>Perreault</surname>
      =               <given>Simon</giv= en>
                  &n= bsp; <additional/>
             = ;       <prefix/>
         = ;           <suffix>ing. jr</suffix>                    <= ;suffix>M.Sc.</suffix>
           = ;     </n>
            &nb= sp;   <bday><date>--0203</date></bday>
&nbs= p;               <anniversary>
=                     <d= ate-time>20090808T1430-0500</date-time>
      &n= bsp;         </anniversary>
    &nbs= p;           <gender><sex>M</sex>= ;</gender>
               = <lang>
                &n= bsp;   <parameters><pref><integer>1</integer>&= lt;/pref>
                &nb= sp;   </parameters>
           =         <language-tag>fr</language-tag>                </lang>
&= nbsp;               <lang>
&nbs= p;                   <param= eters><pref><integer>2</integer></pref>
 = ;                   </param= eters>
                 =   <language-tag>en</language-tag>
     =           </lang>
      &= nbsp;         <org>
       = ;             <parameters><type>&= lt;text>work</text></type>
        &n= bsp;           </parameters>
   = ;                 <text>Viage= nie</text>
               = </org>
                &l= t;adr>
                 =   <parameters>
            &nb= sp;           <type><text>work</tex= t></type>
              &nbs= p;         <label><text>Simon Perreault
=                      = ;       2875 boul. Laurier, suite D2-630
    &n= bsp;                     =   Quebec, QC, Canada
            &nbs= p;               G1V 2M2</text><= ;/label>
                &nbs= p;   </parameters>
            =         <pobox/>
        &= nbsp;           <ext/>
    &nbs= p;               <street>2875 boul= . Laurier, suite D2-630</street>
         = ;           <locality>Quebec</locality>= ;
                    = <region>QC</region>
           = ;         <code>G1V 2M2</code>
  &n= bsp;                 <country>= ;Canada</country>
             =   </adr>
              &n= bsp; <tel>
               =     <parameters>
          &nb= sp;             <type>
   =                     &nbs= p;   <text>work</text>
        &nbs= p;                   <text&= gt;voice</text>
              &= nbsp;         </type>
      &nb= sp;             </parameters>
 =                   <uri>= tel:+1-418-656-9254;ext=3D= 102</uri>
              &nb= sp; </tel>
               = <tel>
                &nb= sp;   <parameters>
            =             <type>
    &nb= sp;                     &= nbsp; <text>work</text>
          &= nbsp;                 <text>t= ext</text>
               =             <text>voice</text>                    &nb= sp;       <text>cell</text>
    &nb= sp;                     &= nbsp; <text>video</text>
          =               </type>
  &n= bsp;                 </parameter= s>
                  &nb= sp; <uri>tel:+1-418-262-6501&l= t;/uri>
                &= lt;/tel>
                <= email>
                 =   <parameters><type><text>work</text></typ= e>
                  &nb= sp; </parameters>
             =       <text>simon.perreault@viagenie.ca</text>
      =           </email>
      &= nbsp;         <geo>
       = ;             <parameters><type>&= lt;text>work</text></type>
        &n= bsp;           </parameters>
   = ;                 <uri>geo:46= .766336,-71.28955</uri>
            =     </geo>
            &nb= sp;   <key>
              =       <parameters><type><text>work</tex= t></type>
              &nbs= p;     </parameters>
          =           <uri>
      &nbs= p;             http://www.viagenie.ca/simon.perreault/simon= .asc
                  =   </uri>
              &nb= sp; </key>
               = <tz><text>America/Montreal</text></tz>
  &= nbsp;             <url>
   = ;                 <parameters>= ;<type><text>home</text></type>
    &n= bsp;               </parameters>                    <= ;uri>http://nomis80.org</uri= >
                </ur= l>
            </vcard>
 =       </vcards>
    </xc:SubscriberDa= ta>
</ad:emergencyCall.SubInfo>

 

Ciao=
Hannes

 

_____________________= __________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

 

= --_000_5A55A45AE77F5941B18E5457ECAC81880121409BAD2DSISPE7MB1co_-- From martin.thomson@gmail.com Tue May 28 16:18:36 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841F121F92E8 for ; Tue, 28 May 2013 16:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACr3tsHm7e8D for ; Tue, 28 May 2013 16:18:35 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9113E21F92FB for ; Tue, 28 May 2013 16:18:34 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id m6so3009915wiv.17 for ; Tue, 28 May 2013 16:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8xY284xD+hL5p1s7XHhIQnSN2j42cOdFEz1PStoRP5w=; b=lYEJ6ItwLdJgzZa7dyFuz6RuEugSiRSNMVh1ad612fig8eBcXcljW9wTpNLQht7C4R 7C4Dl3YMItRacYXBHEQHn7Jbg+bAX2DR7a1xfvWczF4ByunefJl79bf9Rk0TUe2j4puc gbAfE2m+Pp5Zze3+PDD71p0khl10c0ch+2rw3gpOWNbUE9j/gczNuGAZrl8TxfKEyCnk dFETY+TaFiGJa4xAh39LTxm2yi7SVjcWPfeTpqDMKiU3EUVLERMq9nt47NB3LAEmQhVO F+sizN9YSugKafp2zfCy7UqtFds3jGsisGGpvwAGWOkrds9P/8xoIOGU1m96BMc95Bav Uqxg== MIME-Version: 1.0 X-Received: by 10.180.74.10 with SMTP id p10mr27773wiv.39.1369783109115; Tue, 28 May 2013 16:18:29 -0700 (PDT) Received: by 10.194.250.10 with HTTP; Tue, 28 May 2013 16:18:29 -0700 (PDT) In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880121409BAD2C@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880121409BAD2C@SISPE7MB1.commscope.com> Date: Tue, 28 May 2013 16:18:29 -0700 Message-ID: From: Martin Thomson To: "Winterbottom, James" Content-Type: text/plain; charset=UTF-8 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Data Provider Contact URI X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 23:18:36 -0000 On 28 May 2013 15:34, Winterbottom, James wrote: > I would be okay with restricting it to SIP and tel for now, though I can see > that with webRTC emerging we made to revisit the list. Restrictions might be inappropriate in light of WebRTC. I would recommend the use of SHOULD, with an explanation of why the SHOULD subjects were selected. I might be tempted to suggest that "skype:..." is equally appropriate, but I probably have a distorted perspective in this regard. It begs the question: what about proprietary identifiers? Of course, this would only be appropriate if it weren't just one contact URI. Why does this have to be just one? --Martin From James.Winterbottom@commscope.com Tue May 28 17:33:37 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ACB21F8D79 for ; Tue, 28 May 2013 17:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92UNW1xnIXFw for ; Tue, 28 May 2013 17:33:32 -0700 (PDT) Received: from cdcsmgw02.commscope.com (smtp1.andrew.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4418221F8D70 for ; Tue, 28 May 2013 17:33:30 -0700 (PDT) X-AuditID: 0a0404e9-b7fa16d000005100-8d-51a54cd9569f Received: from CDCE10HC2.commscope.com ( [10.86.28.22]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id FC.37.20736.9DC45A15; Tue, 28 May 2013 19:33:29 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 28 May 2013 19:33:28 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 29 May 2013 08:33:26 +0800 From: "Winterbottom, James" To: Martin Thomson Date: Wed, 29 May 2013 08:33:25 +0800 Thread-Topic: [Ecrit] Data Provider Contact URI Thread-Index: Ac5b+av6J7qx48k+RWCp0jRsSHKLMwACieQQ Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121409BAD3A@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880121409BAD2C@SISPE7MB1.commscope.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBKsWRmVeSWpSXmKPExsXCFSYjpnvTZ2mgwfX/yhZP709js2hc9JTV YunOe6wW1878Y3Rg8bj/7S+7x85Zd9k9Fm/az+axZMlPpgCWKC6blNSczLLUIn27BK6M7pOH 2Aoe8Vbsf93J1sC4hbeLkZNDQsBEYsK844wQtpjEhXvr2boYuTiEBHYxSjQ87GaEcDYwSsyZ OZ8JwlnHKDHtzyJWkBY2ATuJw+tvMIPYIgK6EovOPmAHsZkFyiXmLT4DZrMIqEp83tcHVi8s oCfxesMxRoh6fYkTr5ezQ9hGEod3rgazeQWCJFqOb2OBWPaWSeLD1m1gCU6BQImJL8+DDWIE uvX7qTVMEMvEJW49mc8E8YOAxJI955khbFGJl4//QdWLStxpXw+0mAOoXlNi/S59iFZFiSnd D6H2CkqcnPmEBcQWAvqlaedX1gmMErOQbJiF0D0LSfcsJN0LGFlWMYonpyQX56aXGxjpJefn 5hYn5xekglibGEHRycLycgfj2Q3ahxgFOBiVeHhXfF8SKMSaWFZcmXuIUZKDSUmU94P30kAh vqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrypgkA53pTEyqrUonyYlAYHh8DpJ/dPMUqx5OXnpSpJ 8B4HGSFYlJqeWpGWmQNMTTClTBycIKN4gEa9B6nhLS5IzC3OTIfIn2JU5bh4eOo7RiGwQVLi vCdAigRAijJK8+DmvGIUBzpemPcASJYHmFzhJrwCGs4ENFyceTHI8JJEhJRUA+MikaLJt26U XFdbwBp7Yd6KZX8mLBVbKOeWL7P05eGGHXYSGw/fCl5j/3G3yaH+s9J/hG+Ldl69+HaO+JJT /03uxKZd+zYvW36V+I4nmm2XzrfWOs7meLzzcZM51wIJsycJmn/0zu7b6pzwPbxsO6uS2KNv PzXcKvWEf/gzv/pg7biQq2LBzx/tSizFGYmGWsxFxYkA1r5uv2sDAAA= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Data Provider Contact URI X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 00:33:37 -0000 SGkgTWFydGluLA0KDQpJIGFtIG9rYXkgd2l0aCB0aGUgU0hPVUxEIGFuZCB0aGUgd2h5Lg0KVGhl IGtleSBmdW5jdGlvbiBvZiB0aGlzIGNvbnRhY3QgaWRlbnRpZmllciBpcyB0aGF0IHRoZSBwcm92 aWRlciBvZiB0aGUgZGF0YSBjYW4gYmUgY29udGFjdGVkIDI0eDcgYnkgYW55b25lIHRoYXQgbmVl ZHMgdG8uIFNvIEkgdGhpbmsgdGhhdCBwcm9wcmlldGFyeSBpZGVudGlmaWVycyB3b3VsZCBuZWVk IHRvIGJlIGRlIGZhY3RvIHN0YW5kYXJkIChsaWtlIFNreXBlIC4uICo4KSkgaW4gb3JkZXIgZm9y IHRoZW0gdG8gYmUgYXBwcm9wcmlhdGUuDQoNCkNoZWVycw0KSmFtZXMNCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhv bXNvbkBnbWFpbC5jb21dIA0KU2VudDogV2VkbmVzZGF5LCAyOSBNYXkgMjAxMyA5OjE4IEFNDQpU bzogV2ludGVyYm90dG9tLCBKYW1lcw0KQ2M6IEhhbm5lcyBUc2Nob2ZlbmlnOyBCcmlhbiBSb3Nl bjsgZWNyaXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRWNyaXRdIERhdGEgUHJvdmlkZXIgQ29u dGFjdCBVUkkNCg0KT24gMjggTWF5IDIwMTMgMTU6MzQsIFdpbnRlcmJvdHRvbSwgSmFtZXMgPEph bWVzLldpbnRlcmJvdHRvbUBjb21tc2NvcGUuY29tPiB3cm90ZToNCj4gSSB3b3VsZCBiZSBva2F5 IHdpdGggcmVzdHJpY3RpbmcgaXQgdG8gU0lQIGFuZCB0ZWwgZm9yIG5vdywgdGhvdWdoIEkgDQo+ IGNhbiBzZWUgdGhhdCB3aXRoIHdlYlJUQyBlbWVyZ2luZyB3ZSBtYWRlIHRvIHJldmlzaXQgdGhl IGxpc3QuDQoNClJlc3RyaWN0aW9ucyBtaWdodCBiZSBpbmFwcHJvcHJpYXRlIGluIGxpZ2h0IG9m IFdlYlJUQy4gIEkgd291bGQgcmVjb21tZW5kIHRoZSB1c2Ugb2YgU0hPVUxELCB3aXRoIGFuIGV4 cGxhbmF0aW9uIG9mIHdoeSB0aGUgU0hPVUxEIHN1YmplY3RzIHdlcmUgc2VsZWN0ZWQuDQoNCkkg bWlnaHQgYmUgdGVtcHRlZCB0byBzdWdnZXN0IHRoYXQgInNreXBlOi4uLiIgaXMgZXF1YWxseSBh cHByb3ByaWF0ZSwgYnV0IEkgcHJvYmFibHkgaGF2ZSBhIGRpc3RvcnRlZCBwZXJzcGVjdGl2ZSBp biB0aGlzIHJlZ2FyZC4gIEl0IGJlZ3MgdGhlIHF1ZXN0aW9uOiB3aGF0IGFib3V0IHByb3ByaWV0 YXJ5IGlkZW50aWZpZXJzPyAgT2YgY291cnNlLCB0aGlzIHdvdWxkIG9ubHkgYmUgYXBwcm9wcmlh dGUgaWYgaXQgd2VyZW4ndCBqdXN0IG9uZSBjb250YWN0IFVSSS4gIFdoeSBkb2VzIHRoaXMgaGF2 ZSB0byBiZSBqdXN0IG9uZT8NCg0KLS1NYXJ0aW4NCg== From hannes.tschofenig@gmx.net Wed May 29 06:36:45 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B9B21F8F27 for ; Wed, 29 May 2013 06:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE0FvsW2vI+4 for ; Wed, 29 May 2013 06:36:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id BCD2221F8F0C for ; Wed, 29 May 2013 06:36:40 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.16]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LkUuD-1UAYvc3RHP-00cUhw for ; Wed, 29 May 2013 15:36:39 +0200 Received: (qmail invoked by alias); 29 May 2013 13:36:39 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.219.140] by mail.gmx.net (mp016) with SMTP; 29 May 2013 15:36:39 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/rHht7sujr8mioS5fqkyhig2cJWul12DaL2o/pGE pY6Kl/YAQfgsIw Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Hannes Tschofenig In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880121409BAD2D@SISPE7MB1.commscope.com> Date: Wed, 29 May 2013 16:36:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <356DFDC7-4B7B-4C23-9DD0-1211AA31A1C4@gmx.net> References: <44D83272-0941-4E26-B8F2-EC5E3377AE65@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC81880121409BAD2D@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data: Transport Related Question X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:36:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi James,=20 calling it "wrapping" wasn't entirely correct, as the example shows.=20 LoST and HELD indeed use the same approach.=20 I personally prefer to use the same approach LoST and HELD already use. = Since Randy spotted this ambiguity in the current text I wanted to get = feedback from the group.=20 Ciao Hannes On May 29, 2013, at 1:42 AM, Winterbottom, James wrote: > I don=E2=80=99t entirely agree with this last point. > For starters I don=E2=80=99t think that you are =E2=80=9Cwrapping=E2=80=9D= the XML object with MIME, you are simply signaling to the receiver that = the contents of the body are xml that refer to a specific type of = object. This is kind and cost nothing since the MIME types already = exist. > =20 > Secondly, it can be used in the header of the actual request to = indicate what the receiver is expecting to get back. > =20 > I will add that both HELD and LoST specify and use MIME types in their = HTTP bindings, so it isn=E2=80=99t clear to me why this should be = different. > =20 > Cheers > James > =20 > =20 > =20 > =20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Brian Rosen > Sent: Tuesday, 28 May 2013 10:47 PM > To: Hannes Tschofenig > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Additional Data: Transport Related Question > =20 > We need the MIME types to separate them in the body and reference them = with the CID. Wrapping the XML object with MIME provides no benefit = when you get them by reference. =20 > =20 > Brian > =20 > On May 28, 2013, at 4:04 AM, Hannes Tschofenig = wrote: >=20 >=20 > Hi all,=20 > =20 > in offlist discussions Randy raised an interesting question regarding = -08 (http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-08) I = would like to bring to your attention.=20 > Randy wrote:=20 > =20 > In Section 4 first numbered hanging indent there is text: > =20 > " > To be conveyed in a SIP body additional data about a call is > defined as a series of MIME objects, each with an XML data > structure contained inside. > " > =20 > and soon after there is this text: > =20 > " > When additional data is > provided by reference (in SIP signaling or Provided-By), each > HTTPS URL references one block; the data is retrieved with an > HTTP GET operation, which returns one of the blocks as an XML > object. > " > =20 > I thought that even when HTTPS is used, the XML data is still=20 > identified as a MIME type? That is, the HTTP response indicates that=20= > data of MIME type 'application/emergencyCall.ProviderInfo+xml' or=20 > whatever is being sent? > =20 > If I'm incorrect and the data is not identified as a MIME type, then=20= > the first text should be reworded for clarity as: > =20 > " > To be conveyed in a SIP body, the additional data is > defined as a series of MIME objects, one for each of the > XML data structures. > " > =20 > Otherwise (if the data is identified using MIME types) then we should=20= > change the first text to: > =20 > " > For transport in SIP or HTTP, the additional data is > defined as a series of MIME objects, one for each of the > data structures. > "=20 > =20 > I think it was slightly misleading to talk about the MIME type=20 > "containing" the XML data structure, since there is no additional=20 > encapsulation (aside from any 8-bit character considerations);=20 > rather, the MIME type is used to identify the data. This is separate=20= > from the use of MIME body parts inside the SIP body to delineate the=20= > various parts. > =20 > My understanding so far was that MIME encapsulation is used for data = that is carried in SIP and in HTTP.=20 > =20 > Here is an example. Imagine that a PSAP obtains an HTTPS URI pointing = to Owner/Subscriber Information data. > =20 > This would lead to the following request: =20 > =20 > GET /path/file.html HTTP/1.1 > Host: www.example.com > Accept: text/*, text/html, application/emergencyCall.SubInfo+xml > =20 > Here is an example response:=20 > =20 > HTTP/1.1 200 OK > Date: Mon, 27 Jul 2009 12:28:53 GMT > Server: Apache > Cache-control: private > Content-Type: application/emergencyCall.SubInfo+xml;charset=3Dutf-8 > Content-Length: tbd > =20 > > xmlns:ad=3D"urn:ietf:params:xml:ns:emergencyCall.SubInfo" > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"> > > > > Simon Perreault > > Perreault > Simon > > > ing. jr > M.Sc. > > --0203 > > 20090808T1430-0500 > > M > > 1 > > fr > > > 2 > > en > > > work > > Viagenie > > > > work > > > > > 2875 boul. Laurier, suite D2-630 > Quebec > QC > G1V 2M2 > Canada > > > > > work > voice > > > tel:+1-418-656-9254;ext=3D102 > > > > > work > text > voice > cell > video > > > tel:+1-418-262-6501 > > > work > > simon.perreault@viagenie.ca > > > work > > geo:46.766336,-71.28955 > > > work > > > http://www.viagenie.ca/simon.perreault/simon.asc > > > America/Montreal > > home > > http://nomis80.org > > > > > > =20 > Ciao > Hannes > =20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > =20 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJRpgRlAAoJEGhJURNOOiAtOjIH/1X0+CUcwxa8MNQVo1HTbORw 9Z+f8D/pl2O5HRPxShQGV3FQ6O7xLuG6JWpP+ejtxiHUWIcdTG7RXYFdmyK1BPax f9EnQ71M8EqHN5AiAZvnw57vh0gmTCVxjOBpNKjbz1AJncJXN78y0a4ovDGIHPk6 /kEjdVxYTYuoEz6AaFTFSEdXG+yKGwJylHGv2V6MNdXrVEw3BIemdzmcfO1p4Z0T 5R/yy5lC7xCO2kOk1h99Hw9AcPIBv2kmrqu/vpm3Lp4LWcoBv47vUHjf6IKWEN1v z7PvAM3+y/ji3X2j9JhXevj5J1/6tQOE+3rql7M0yuc3mAQwgh61G7Z3XqUi4aQ=3D =3DWT5l -----END PGP SIGNATURE----- From randy@qti.qualcomm.com Thu May 30 17:35:56 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F8821F9698 for ; Thu, 30 May 2013 17:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.007 X-Spam-Level: X-Spam-Status: No, score=-105.007 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iazMgOXk9KmX for ; Thu, 30 May 2013 17:35:52 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 608F321F9385 for ; Thu, 30 May 2013 17:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1369960552; x=1401496552; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=VcCS6Jf8Kd4Qs5XXt/tWWX0U5iWhTNnm7TUehgUX5FA=; b=T14rV7IGXZ//C/fWl2wtoDdffoklADL5K8blOk+VzLToAZ6LjXqNwmuE hIyVf7hdK5W+Cv4NZKPD3XoGMWE9Xi6+yUhECT4lNXlTt/XMhv3kUUy8F TsZ82jiCZd4VKVNgjtghb6EEaOc0b5lgJLYYoy4qniSrTPDYoWKbrsSKF M=; X-IronPort-AV: E=Sophos;i="4.87,774,1363158000"; d="scan'208,217";a="52198843" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 30 May 2013 17:35:51 -0700 X-IronPort-AV: E=Sophos;i="4.87,774,1363158000"; d="scan'208,217";a="456709989" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 30 May 2013 17:35:51 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 30 May 2013 17:35:50 -0700 Message-ID: In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880121409BAD2D@SISPE7MB1.commscope.com> References: <44D83272-0941-4E26-B8F2-EC5E3377AE65@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC81880121409BAD2D@SISPE7MB1.commscope.com> X-Mailer: Eudora for Mac OS X Date: Thu, 30 May 2013 17:28:12 -0700 To: "Winterbottom, James" , Brian Rosen , Hannes Tschofenig From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data: Transport Related Question X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 00:35:56 -0000 Re: [Ecrit] Additional Data: Transport Related Question
Hi everyone,

James' response matches my understanding: there is no wrapping or encapsulation; the MIME type is used to identify the type of data.  In the example Hannes provided, the MIME type "application/emergencyCall.SubInfo+xml" identifies the data.

(When the data is carried in the SIP body, MIME Multipart/Mixed is used to separate the body parts, so in that sense, Multipart/Mixed encapsulates the data, but at least for body parts which are XML or other textual data, the individual MIME types of each body part only identifies the data, there is no extra encapsulation.)




At 6:42 AM +0800 5/29/13, James Winterbottom wrote:

I don't entirely agree with this last point.
For starters I don't think that you are "wrapping" the XML object with MIME, you are simply signaling to the receiver that the contents of the body are xml that refer to a specific type of object. This is kind and cost nothing since the MIME types already exist.
 
Secondly, it can be used in the header of the actual request to indicate what the receiver is expecting to get back.
 
I will add that both HELD and LoST specify and use MIME types in their HTTP bindings, so it isn't clear to me why this should be different.
 
Cheers
James
 
 
 
 
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Tuesday, 28 May 2013 10:47 PM
To: Hannes Tschofenig
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Additional Data: Transport Related Question
 
We need the MIME types to separate them in the body and reference them with the CID.  Wrapping the XML object with MIME provides no benefit when you get them by reference.
 
Brian
 
On May 28, 2013, at 4:04 AM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:


Hi all,
 
in offlist discussions Randy raised an interesting question regarding -08 (http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-08) I would like to bring to your attention.
Randy wrote:
 
In Section 4 first numbered hanging indent there is text:
 
"
        To be conveyed in a SIP body additional data about a call is
        defined as a series of MIME objects, each with an XML data
        structure contained inside.
"
 
and soon after there is this text:
 
"
       When additional data is
        provided by reference (in SIP signaling or Provided-By), each
        HTTPS URL references one block; the data is retrieved with an
        HTTP GET operation, which returns one of the blocks as an XML
        object.
"
 
I thought that even when HTTPS is used, the XML data is still 
identified as a MIME type?  That is, the HTTP response indicates that 
data of MIME type 'application/emergencyCall.ProviderInfo+xml' or 
whatever is being sent?
 
If I'm incorrect and the data is not identified as a MIME type, then 
the first text should be reworded for clarity as:
 
"
       To be conveyed in a SIP body, the additional data is
        defined as a series of MIME objects, one for each of the
        XML data structures.
"
 
Otherwise (if the data is identified using MIME types) then we should 
change the first text to:
 
"
        For transport in SIP or HTTP, the additional data is
        defined as a series of MIME objects, one for each of the
        data structures.
"
 
I think it was slightly misleading to talk about the MIME type 
"containing" the XML data structure, since there is no additional 
encapsulation (aside from any 8-bit character considerations); 
rather, the MIME type is used to identify the data.  This is separate 
from the use of MIME body parts inside the SIP body to delineate the 
various parts.
 
My understanding so far was that MIME encapsulation is used for data that is carried in SIP and in HTTP.
 
Here is an example. Imagine that a PSAP obtains an HTTPS URI pointing to Owner/Subscriber Information data.
 
This would lead to the following request:
 
GET /path/file.html HTTP/1.1
Host: www.example.com
Accept: text/*, text/html, application/emergencyCall.SubInfo+xml
 
Here is an example response:
 
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Cache-control: private
Content-Type: application/emergencyCall.SubInfo+xml;charset=utf-8
Content-Length: tbd
 
<?xml version="1.0" encoding="UTF-8"?>
<ad:emergencyCall.SubInfo 
     xmlns:ad="urn:ietf:params:xml:ns:emergencyCall.SubInfo"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <xc:SubscriberData xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0">
        <vcards xmlns="urn:ietf:params:xml:ns:vcard-4.0">
            <vcard>
                <fn><text>Simon Perreault</text></fn>
                <n>
                    <surname>Perreault</surname>
                    <given>Simon</given>
                    <additional/>
                    <prefix/>
                    <suffix>ing. jr</suffix>
                    <suffix>M.Sc.</suffix>
                </n>
                <bday><date>--0203</date></bday>
                <anniversary>
                    <date-time>20090808T1430-0500</date-time>
                </anniversary>
                <gender><sex>M</sex></gender>
                <lang>
                    <parameters><pref><integer>1</integer></pref>
                    </parameters>
                    <language-tag>fr</language-tag>
                </lang>
                <lang>
                    <parameters><pref><integer>2</integer></pref>
                    </parameters>
                    <language-tag>en</language-tag>
                </lang>
                <org>
                    <parameters><type><text>work</text></type>
                    </parameters>
                    <text>Viagenie</text>
                </org>
                <adr>
                    <parameters>
                        <type><text>work</text></type>
                        <label><text>Simon Perreault
                            2875 boul. Laurier, suite D2-630
                            Quebec, QC, Canada
                            G1V 2M2</text></label>
                    </parameters>
                    <pobox/>
                    <ext/>
                    <street>2875 boul. Laurier, suite D2-630</street>
                    <locality>Quebec</locality>
                    <region>QC</region>
                    <code>G1V 2M2</code>
                    <country>Canada</country>
                </adr>
                <tel>
                    <parameters>
                        <type>
                            <text>work</text>
                            <text>voice</text>
                        </type>
                    </parameters>
                    <uri>tel:+1-418-656-9254;ext=102</uri>
                </tel>
                <tel>
                    <parameters>
                        <type>
                            <text>work</text>
                            <text>text</text>
                            <text>voice</text>
                            <text>cell</text>
                            <text>video</text>
                        </type>
                    </parameters>
                    <uri>tel:+1-418-262-6501</uri>
                </tel>
                <email>
                    <parameters><type><text>work</text></type>
                    </parameters>
                    <text>simon.perreault@viagenie.ca</text>
                </email>
                <geo>
                    <parameters><type><text>work</text></type>
                    </parameters>
                    <uri>geo:46.766336,-71.28955</uri>
                </geo>
                <key>
                    <parameters><type><text>work</text></type>
                    </parameters>
                    <uri>
                    http://www.viagenie.ca/simon.perreault/simon.asc
                    </uri>
                </key>
                <tz><text>America/Montreal</text></tz>
                <url>
                    <parameters><type><text>home</text></type>
                    </parameters>
                    <uri>http://nomis80.org</uri>
                </url>
            </vcard>
        </vcards>
    </xc:SubscriberData>
</ad:emergencyCall.SubInfo>
 
Ciao
Hannes
 
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
 

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


--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
640K ought to be enough for anybody.  --Bill Gates, 1981
From hannes.tschofenig@gmx.net Fri May 31 07:20:11 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26D621F9123 for ; Fri, 31 May 2013 07:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.113 X-Spam-Level: X-Spam-Status: No, score=-102.113 tagged_above=-999 required=5 tests=[AWL=1.867, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80XdNGFUMDRv for ; Fri, 31 May 2013 07:20:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id B5C6B21F9732 for ; Fri, 31 May 2013 07:20:05 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.16]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MNO9n-1Ukt1Z3IvR-006uIr for ; Fri, 31 May 2013 16:20:04 +0200 Received: (qmail invoked by alias); 31 May 2013 14:20:04 -0000 Received: from unknown (EHLO [10.255.135.144]) [194.251.119.201] by mail.gmx.net (mp016) with SMTP; 31 May 2013 16:20:04 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/2HmJ2g2X2+l/tQ2Yej1SBDBLqfY4hUHTK2Orgn3 uTf2WMPmoIiBvp From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 31 May 2013 17:20:02 +0300 Message-Id: <0CAE1157-E7C8-4BB8-AC82-EFD40FEAD735@gmx.net> To: "ECRIT WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [Ecrit] Support Next Generation 112 Emergency Services Interoperability Testing Efforts! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 14:20:11 -0000 Hi all,=20 EENA is currently soliciting support from the wider emergency services = community to convince the European Commission to consider the = establishment of an interoperability testing program. This interop = effort would mainly be used to fund testing events of IP-based emergency = services, including the ECRIT and GEOPRIV specifications. For this = reason it is relevant to this group. I have produced a short writeup with a pointer to an EENA letter, which = provides additional background information. It can be found here: = http://www.tschofenig.priv.at/wp/?p=3D988 If you support such a testing program, could you please respond (see = webpage for details) at latest by next Tuesday, June 4th.=20 (I know it is a short notice... For questions please drop me a mail.) Ciao Hannes From hannes.tschofenig@gmx.net Fri May 31 07:47:21 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F52F21F8528 for ; Fri, 31 May 2013 07:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.417 X-Spam-Level: X-Spam-Status: No, score=-101.417 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RfY-+9QXIGL for ; Fri, 31 May 2013 07:47:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6F52B21F8540 for ; Fri, 31 May 2013 07:47:16 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Ld2ys-1U0G5T2U52-00iBOH for ; Fri, 31 May 2013 16:47:15 +0200 Received: (qmail invoked by alias); 31 May 2013 14:47:15 -0000 Received: from unknown (EHLO [10.255.135.144]) [194.251.119.201] by mail.gmx.net (mp031) with SMTP; 31 May 2013 16:47:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18L9EldrqoLnIqEypgzHv9So9gfV6jjL7AqjxT6vg dX0HgeppMxfpRq Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Fri, 31 May 2013 17:47:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <47CED4BA-C423-4E9C-BF7D-30F204616B96@gmx.net> References: <44D83272-0941-4E26-B8F2-EC5E3377AE65@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC81880121409BAD2D@SISPE7MB1.commscope.com> To: Randall Gellens X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data: Transport Related Question X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 14:47:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Thanks for the feedback.=20 To close this open issue I am suggesting to make the following change to = the draft for improved clarity: Change from " To be conveyed in a SIP body additional data about a call is defined as a series of MIME objects, each with an XML data structure contained inside. " to:=20 " For transport in SIP or HTTP, the additional data is defined as a series of MIME objects, one for each of the data structures. " I would also suggest to add the example to the draft.=20 Ciao Hannes On May 31, 2013, at 3:28 AM, Randall Gellens wrote: > Hi everyone, >=20 > James' response matches my understanding: there is no wrapping or = encapsulation; the MIME type is used to identify the type of data. In = the example Hannes provided, the MIME type = "application/emergencyCall.SubInfo+xml" identifies the data. >=20 > (When the data is carried in the SIP body, MIME Multipart/Mixed is = used to separate the body parts, so in that sense, Multipart/Mixed = encapsulates the data, but at least for body parts which are XML or = other textual data, the individual MIME types of each body part only = identifies the data, there is no extra encapsulation.) >=20 >=20 >=20 >=20 > At 6:42 AM +0800 5/29/13, James Winterbottom wrote: >=20 >> I don't entirely agree with this last point. >> For starters I don't think that you are "wrapping" the XML object = with MIME, you are simply signaling to the receiver that the contents of = the body are xml that refer to a specific type of object. This is kind = and cost nothing since the MIME types already exist. >> =20 >> Secondly, it can be used in the header of the actual request to = indicate what the receiver is expecting to get back. >> =20 >> I will add that both HELD and LoST specify and use MIME types in = their HTTP bindings, so it isn't clear to me why this should be = different. >> =20 >> Cheers >> James >> =20 >> =20 >> =20 >> =20 >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of Brian Rosen >> Sent: Tuesday, 28 May 2013 10:47 PM >> To: Hannes Tschofenig >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Additional Data: Transport Related Question >> =20 >> We need the MIME types to separate them in the body and reference = them with the CID. Wrapping the XML object with MIME provides no = benefit when you get them by reference. >> =20 >> Brian >> =20 >> On May 28, 2013, at 4:04 AM, Hannes Tschofenig = wrote: >>=20 >>=20 >> Hi all, >> =20 >> in offlist discussions Randy raised an interesting question regarding = -08 (http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-08) I = would like to bring to your attention. >> Randy wrote: >> =20 >> In Section 4 first numbered hanging indent there is text: >> =20 >> " >> To be conveyed in a SIP body additional data about a call is >> defined as a series of MIME objects, each with an XML data >> structure contained inside. >> " >> =20 >> and soon after there is this text: >> =20 >> " >> When additional data is >> provided by reference (in SIP signaling or Provided-By), each >> HTTPS URL references one block; the data is retrieved with an >> HTTP GET operation, which returns one of the blocks as an XML >> object. >> " >> =20 >> I thought that even when HTTPS is used, the XML data is still=20 >> identified as a MIME type? That is, the HTTP response indicates that=20= >> data of MIME type 'application/emergencyCall.ProviderInfo+xml' or=20 >> whatever is being sent? >> =20 >> If I'm incorrect and the data is not identified as a MIME type, then=20= >> the first text should be reworded for clarity as: >> =20 >> " >> To be conveyed in a SIP body, the additional data is >> defined as a series of MIME objects, one for each of the >> XML data structures. >> " >> =20 >> Otherwise (if the data is identified using MIME types) then we should=20= >> change the first text to: >> =20 >> " >> For transport in SIP or HTTP, the additional data is >> defined as a series of MIME objects, one for each of the >> data structures. >> " >> =20 >> I think it was slightly misleading to talk about the MIME type=20 >> "containing" the XML data structure, since there is no additional=20 >> encapsulation (aside from any 8-bit character considerations);=20 >> rather, the MIME type is used to identify the data. This is separate=20= >> from the use of MIME body parts inside the SIP body to delineate the=20= >> various parts. >> =20 >> My understanding so far was that MIME encapsulation is used for data = that is carried in SIP and in HTTP. >> =20 >> Here is an example. Imagine that a PSAP obtains an HTTPS URI pointing = to Owner/Subscriber Information data. >> =20 >> This would lead to the following request: >> =20 >> GET /path/file.html HTTP/1.1 >> Host: www.example.com >> Accept: text/*, text/html, application/emergencyCall.SubInfo+xml >> =20 >> Here is an example response: >> =20 >> HTTP/1.1 200 OK >> Date: Mon, 27 Jul 2009 12:28:53 GMT >> Server: Apache >> Cache-control: private >> Content-Type: application/emergencyCall.SubInfo+xml;charset=3Dutf-8 >> Content-Length: tbd >> =20 >> >> > xmlns:ad=3D"urn:ietf:params:xml:ns:emergencyCall.SubInfo" >> xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"> >> >> >> >> Simon Perreault >> >> Perreault >> Simon >> >> >> ing. jr >> M.Sc. >> >> --0203 >> >> 20090808T1430-0500 >> >> M >> >> 1 >> >> fr >> >> >> 2 >> >> en >> >> >> work >> >> Viagenie >> >> >> >> work >> >> >> >> >> 2875 boul. Laurier, suite D2-630 >> Quebec >> QC >> G1V 2M2 >> Canada >> >> >> >> >> work >> voice >> >> >> tel:+1-418-656-9254;ext=3D102 >> >> >> >> >> work >> text >> voice >> cell >> video >> >> >> tel:+1-418-262-6501 >> >> >> work >> >> simon.perreault@viagenie.ca >> >> >> work >> >> geo:46.766336,-71.28955 >> >> >> work >> >> >> http://www.viagenie.ca/simon.perreault/simon.asc >> >> >> America/Montreal >> >> home >> >> http://nomis80.org >> >> >> >> >> >> =20 >> Ciao >> Hannes >> =20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> =20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > --=20 >=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > 640K ought to be enough for anybody. --Bill Gates, 1981 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJRqLfwAAoJEGhJURNOOiAtL4YH/imeY3yr7trGPHzgRWj7v76P a+d6EUbopG3/j8K3llaSeuT6lcYEXgn6PRqL4gMffttlCYZNeVbByVpfiOq5AE3z bTT8xb6/1LWXCJ/xb8zb3wFMAkcQbunbat6cgWKmfqQ6hXR90boV4nMdid407Efc Ku1uDQ/ePhaZVWwjNzFjmo0WvaQfky8FXevGTP35hhGBWBRXoMeksjrP66pXF0Fp 2tdC70PksCJECF6HMnfY0p0d3TP+Pgq0zs8j4A4zog1wO8PHpqQrTsZ63vJ9cLTO 2ZQAZEeE9krWivBaAQDe+f1Di2ReuVuvmMwcgC1ynhp9PtWpK3LXb4lcQqpikW4=3D =3D05bX -----END PGP SIGNATURE-----