From James.Winterbottom@commscope.com Sun Jun 2 20:32:19 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 0B1A621F8FB6 for ; Sun, 2 Jun 2013 20:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 F9RlDCeq9p-Y for ; Sun, 2 Jun 2013 20:32:15 -0700 (PDT) Received: from cdcsmgw02.commscope.com (cdcsmgw02.commscope.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id F169921F8267 for ; Sun, 2 Jun 2013 20:32:10 -0700 (PDT) X-AuditID: 0a0404e9-b7fa16d000005100-48-51ac0e39eabb Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id 03.F3.20736.93E0CA15; Sun, 2 Jun 2013 22:32:09 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sun, 2 Jun 2013 22:32:08 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 3 Jun 2013 11:32:06 +0800 From: "Winterbottom, James" To: Hannes Tschofenig , Randall Gellens Date: Mon, 3 Jun 2013 11:32:03 +0800 Thread-Topic: [Ecrit] Additional Data: Transport Related Question Thread-Index: Ac5eDcDL2EvnCQeRSIGu2k6DCkGNKgB/IaEA Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121409BB092@SISPE7MB1.commscope.com> References: <44D83272-0941-4E26-B8F2-EC5E3377AE65@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC81880121409BAD2D@SISPE7MB1.commscope.com> <47CED4BA-C423-4E9C-BF7D-30F204616B96@gmx.net> In-Reply-To: <47CED4BA-C423-4E9C-BF7D-30F204616B96@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+NgFnrMKsWRmVeSWpSXmKPExsXCFSYjqmvJtybQYNUkOYun96exWTQuespq sXTnPVaLa486mB1YPO5/+8vusXjTfjaPJUt+MnksmvqMMYAlissmJTUnsyy1SN8ugStjx+Wr bAW7oyv2ta5laWC8aNfFyMkhIWAicXbGWxYIW0ziwr31bCC2kMAuRolDu4Ih7PWMEnOmi3Ux cgHZaxklNtyeyAySYBOwkzi8/gaYLSIQK7F791KmLkYODmYBN4mrG4pBwiwCKhJvL24DKxEW cJBY/vkzO0S5o8Szn9+gbCOJe2/+M4LYvAJBEl2NTxkhdm1hkpi49SUTSIJTwFqie+ISsEMZ gQ79fmoNWJxZQFzi1pP5TBAPCEgs2XOeGcIWlXj5+B8rRL2oxJ329YwQ9ToSC3Z/YoOwtSWW LXzNDLFYUOLkzCcsEA/rSjTt/Mo6gVFiFpIVs5C0z0LSPgtJ+wJGllWM4skpycW56eUGRnrJ +bm5xcn5Bakg1iZGUGyysLzcwXh2g/YhRgEORiUe3o7tqwKFWBPLiitzDzFKcjApifJGc60J FOJLyk+pzEgszogvKs1JLT7EKMHBrCTCm7xydaAQb0piZVVqUT5MSoODQ+D0k/unGKVY8vLz UpUkePfxAo0QLEpNT61Iy8wBJiaYUiYOTpBRPECj1oHU8BYXJOYWZ6ZD5E8xGnJsPj/5HSPH jJlTgeTFw0BSCGyolDhvCUiDAEhDRmke3MxXjOJAjwjzngHJ8gBTLty0V0CLmIAWTX69CmRR SSJCSqqBUdYo6vOfR5e/Gwl3WLF0ft/1PnxX3QyrhqWbu6ymRz2Ue5R3akXOpriVHmfNTjvf vmd0YbdhjO303v77/+O+LPPW5G5pEivrqRC7w5z5bhvzpetP2l3atDfGfum6IZx4+WTvRAHn qumK5bUHi5ZNeeDn9YAj6lrNFSmvxVe+r14h3Szy5t/jj0osxRmJhlrMRcWJAKMv9GJ2AwAA 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: Mon, 03 Jun 2013 03:32:19 -0000 Hi Hannes, I think I would change the last sentence of the proposed new 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 structure types." This allows multiple structures of the same type to be fetched at the same = time. For example a NENA LIF could return multiple emergencyCall.ProviderInfo str= uctures depending on what is provisioned. Cheers James -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Saturday, 1 June 2013 12:47 AM To: Randall Gellens Cc: Hannes Tschofenig; Winterbottom, James; Brian Rosen; ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: Transport Related Question -----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 th= e 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 encapsu= lation; the MIME type is used to identify the type of data. In the example= Hannes provided, the MIME type "application/emergencyCall.SubInfo+xml" ide= ntifies the data. >=20 > (When the data is carried in the SIP body, MIME Multipart/Mixed is=20 > used to separate the body parts, so in that sense, Multipart/Mixed=20 > encapsulates the data, but at least for body parts which are XML or=20 > other textual data, the individual MIME types of each body part only=20 > 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 M= IME, 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 not= hing 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 H= TTP 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=20 >> 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 w= ith the CID. Wrapping the XML object with MIME provides no benefit when yo= u 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 -0= 8 (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 tha= t 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 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- 640K ought to be=20 > 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----- From James.Winterbottom@commscope.com Sun Jun 2 20:45:38 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 7969821F8F38 for ; Sun, 2 Jun 2013 20:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, 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 NMFijHOtc3d7 for ; Sun, 2 Jun 2013 20:45:33 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id 49BA321F8EAE for ; Sun, 2 Jun 2013 20:45:33 -0700 (PDT) X-AuditID: 0a0404e8-b7fdb6d000001d37-d5-51ac115ca324 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id 2A.8C.07479.C511CA15; Sun, 2 Jun 2013 22:45:32 -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; Sun, 2 Jun 2013 22:45:32 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 3 Jun 2013 11:45:28 +0800 From: "Winterbottom, James" To: "ecrit@ietf.org" Date: Mon, 3 Jun 2013 11:45:26 +0800 Thread-Topic: Additional Data -09 Data Provider Schema Thread-Index: Ac5gDMjEtg/AYbuTS0CalOYQQtCS2w== Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121409BB093@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_5A55A45AE77F5941B18E5457ECAC81880121409BB093SISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRmVeSWpSXmKPExsXCFSaSphsjuCbQ4Mc3eYvGRU9ZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0bdqDnvBMvGKzU2fWBsY74l0MXJySAiYSMz428AKYYtJXLi3 nq2LkYtDSGA3o0TnjlNQznpGiYvfbzFCOGsZJVZs/wzWwiZgJ3F4/Q1mEFtEQFViw5mVjCA2 i4CKxNRbS1lAbGEBQ4nmzZfYIWrMJN6cOMUKYetJbO6dABbnFQiSWDx9ItgcRqAzvp9awwRi MwuIS9x6Mp8J4jwBiSV7zjND2KISLx//Y4WoF5W4076eEaI+X6K7A2Ivr4CgxMmZT8BsIQFd iaadX1knMIrMQjJ2FpKWWUhaIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG8eSU5OLc 9HIDQ73k/Nzc4uT8glQQaxMjKJZYWF7sYDy9QfsQowAHoxIPb9f2VYFCrIllxZW5hxglOZiU RHl5+dcECvEl5adUZiQWZ8QXleakFh9ilOBgVhLhTV65OlCINyWxsiq1KB8mpcHBIXD6yf1T jFIsefl5qUoSvIECQCMEi1LTUyvSMnOAiQSmlImDE2QUD9AoTpAa3uKCxNzizHSI/ClGVY6L h6e+YxQCGyQlzusLUiQAUpRRmgc35xWjONDxwrwpIFkeYCqEm/AKaDgT0PDJr1eBDC9JREhJ NTA2zdndMkPv/6GAO8kXtmlHhfzm4tcxCVM5o8iv8NqKryn6xsKdP5gqvxnUMi1cfZNpSZXo q++qDjGmEgdMFX3Pfjsc+O/mf+dMkTDekIdvz8yyEbWTVbVPZa3S28jNMP9f2Lw0xfvnFqrx zOEz6+BXVdq6PcjtWtTjWvbmzxMaLp2bbZRxyV6JpTgj0VCLuag4EQDHtzEuQgMAAA== Subject: [Ecrit] Additional Data -09 Data Provider Schema 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, 03 Jun 2013 03:45:38 -0000 --_000_5A55A45AE77F5941B18E5457ECAC81880121409BB093SISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hannes, The Data Provider Information sections in the document are covered in secti= on 3.1. Section 3.1.8 "Subcontractor Principal" and Section 3.1.9 "Subcontractor Pr= iority" seem to be missing from the element sequence defined in the emergen= cyCall.ProviderInfo schema defined in section 6.1. Cheers James --_000_5A55A45AE77F5941B18E5457ECAC81880121409BB093SISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hannes,<= /o:p>

 

The= Data Provider Information sections in the document are covered in section = 3.1.

Section 3.1.8 “Subcontractor = Principal” and Section 3.1.9 “Subcontractor Priority” see= m to be missing from the element sequence defined in the emergencyCall.Prov= iderInfo schema defined in section 6.1.

=  

Cheers

James

 

= --_000_5A55A45AE77F5941B18E5457ECAC81880121409BB093SISPE7MB1co_-- From br@brianrosen.net Mon Jun 3 07:00: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 ABC2221F93F8 for ; Mon, 3 Jun 2013 07:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 WulwJDY-PWZp for ; Mon, 3 Jun 2013 07:00:31 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9DA21F9399 for ; Mon, 3 Jun 2013 07:00: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=EABBk8S6mcHyJWnos+FlEMKowfH4WO/5TAbs98HJRrA=; b=J1wt6IL4yh/F8HfwIFklEIz5mdgY4z8KjBCjAuF6sp2To2ALNEe+cHNhJ5/RcHS6v3Bbm+Zv4oPR1tIdPhp7lWq/qkgVErWPUQEM0ElQ3pMhZ7E+OUCIoX5v8U8YVwWGwGM7/gvJuLa9BrBk7Z19207ZuN62BvE7peHJkRPpJi4=; Received: from neustargw.va.neustar.com ([209.173.53.233]:29140 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UjVJG-0001JR-0A; Mon, 03 Jun 2013 10:00: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: <5A55A45AE77F5941B18E5457ECAC81880121409BB092@SISPE7MB1.commscope.com> Date: Mon, 3 Jun 2013 10:00:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3BAA88A9-4502-44CE-9D0F-72A2621A2325@brianrosen.net> References: <44D83272-0941-4E26-B8F2-EC5E3377AE65@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC81880121409BAD2D@SISPE7MB1.commscope.com> <47CED4BA-C423-4E9C-BF7D-30F204616B96@gmx.net> <5A55A45AE77F5941B18E5457ECAC81880121409BB092@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: Randall Gellens , "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: Mon, 03 Jun 2013 14:00:35 -0000 That would mean we would need the Additional Data by Reference to be a = web service where you could list all the mime types and get them all in = one operation. The current situation is that you get a URI for each block with a = parameter that tells you what type it is, and you fetch them one by one. = =20 Brian On Jun 2, 2013, at 11:32 PM, "Winterbottom, James" = wrote: > Hi Hannes, >=20 > I think I would change the last sentence of the proposed new 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 structure types." >=20 > This allows multiple structures of the same type to be fetched at the = same time. > For example a NENA LIF could return multiple = emergencyCall.ProviderInfo structures depending on what is provisioned. >=20 > Cheers > James >=20 >=20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Saturday, 1 June 2013 12:47 AM > To: Randall Gellens > Cc: Hannes Tschofenig; Winterbottom, James; Brian Rosen; = ecrit@ietf.org > Subject: Re: [Ecrit] Additional Data: Transport Related Question >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Thanks for the feedback.=20 >=20 > To close this open issue I am suggesting to make the following change = to the draft for improved clarity: >=20 > Change from >=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 >=20 > to:=20 >=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 would also suggest to add the example to the draft.=20 >=20 > Ciao > Hannes >=20 > On May 31, 2013, at 3:28 AM, Randall Gellens wrote: >=20 >> 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=20 >> used to separate the body parts, so in that sense, Multipart/Mixed=20 >> encapsulates the data, but at least for body parts which are XML or=20= >> other textual data, the individual MIME types of each body part only=20= >> 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=20 >>> 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 >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself = only >> -------------- Randomly selected tag: --------------- 640K ought to = be=20 >> enough for anybody. --Bill Gates, 1981 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org >=20 > iQEcBAEBCgAGBQJRqLfwAAoJEGhJURNOOiAtL4YH/imeY3yr7trGPHzgRWj7v76P > a+d6EUbopG3/j8K3llaSeuT6lcYEXgn6PRqL4gMffttlCYZNeVbByVpfiOq5AE3z > bTT8xb6/1LWXCJ/xb8zb3wFMAkcQbunbat6cgWKmfqQ6hXR90boV4nMdid407Efc > Ku1uDQ/ePhaZVWwjNzFjmo0WvaQfky8FXevGTP35hhGBWBRXoMeksjrP66pXF0Fp > 2tdC70PksCJECF6HMnfY0p0d3TP+Pgq0zs8j4A4zog1wO8PHpqQrTsZ63vJ9cLTO > 2ZQAZEeE9krWivBaAQDe+f1Di2ReuVuvmMwcgC1ynhp9PtWpK3LXb4lcQqpikW4=3D > =3D05bX > -----END PGP SIGNATURE----- From James.Winterbottom@commscope.com Mon Jun 3 13:58: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 D4CCF21F973D for ; Mon, 3 Jun 2013 13:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 vpf718McPgwG for ; Mon, 3 Jun 2013 13:57:59 -0700 (PDT) Received: from cdcsmgw02.commscope.com (smtp1.andrew.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7616E11E8102 for ; Mon, 3 Jun 2013 13:53:15 -0700 (PDT) X-AuditID: 0a0404e9-b7fa16d000005100-1a-51ad023a9465 Received: from CDCE10HC2.commscope.com ( [10.86.28.22]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id 0A.80.20736.A320DA15; Mon, 3 Jun 2013 15:53:14 -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; Mon, 3 Jun 2013 15:53:13 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 4 Jun 2013 04:53:10 +0800 From: "Winterbottom, James" To: "'br@brianrosen.net'" Date: Tue, 4 Jun 2013 04:53:09 +0800 Thread-Topic: [Ecrit] Additional Data: Transport Related Question Thread-Index: Ac5gYrbd29gTBjVeT7acvv43bQAg0AAOaPSf Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121407DA0F8@SISPE7MB1.commscope.com> In-Reply-To: <3BAA88A9-4502-44CE-9D0F-72A2621A2325@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA01SbUgTYRzvubvNc3n1OF/2NEpiRJSiqQUtCTE/1PBLaiAVgV3b6QZ7kZ2a SoQaoQiJMBc6LctUyLeVBuqQJKXCN1TIlDAXqRtqRPku5Opup7YvD7/7/97+D/eQuHRKJCd1 xmzGbKT1CrGEkKQdDY2Mw9pSole7DisXnI/FyqL6BZGysWdWpPz8vRRPIFTOjR0/1YuOPrGq oWEbU9VbXSCZuCm5qGH0ulzGfCb+tkRb576ftanJe9htJwpB/5Uy4E8ieA59XXCKBRyKxmft HJaQUugAqKh2ERM+7ACtTf3eZdoBqvjbTfAWMYxHA/ZpvAyQZDCMRE+sGl6DwxqAOh1uP15D wBPom/sTxuMgmIDGiye882B4Cbm2N3ZxLHr/qFbEYwqmopbyXoLP9IeJqLYplR8DbrvNoVZv DA5l6Mt8HSZsDVFD7xgu4BC0OOcRCfoQNFNiB4I+Ck1bK8UCjkBNz5dxoSoQDVbPe68i5dYv 7lkXVQCZzafC5mO3+dhtPvZngGgGMrVGzRoy70bHRqlNBgOrNmUxPOoA/B8kiMVuMPoqoh9A EigCqONvWlOkIjqXzTf0gyMkpgihPB5udOiOSZOvpVltujlHz7D9AJG4Ipia/MhxlIbOL2DM pj3qFEnC4XnnEJATRpORUSAqCrSlSAPNTCaTl6HTcw9oT4qR/nxUABfl1VBsFm1gdZkCPwRi yM4xy09AVlVbuXNigDul3lC5jPIc4AyQN2hzjPuZS0DGXSSIiuHjArjXup+2xBVhXJFluZkv yqb/U/JCkOwKu/CufJWOw8pyDn44j79UN60d13Zd3lkfLrU0NpyOtDDl+NOVpuXgKUnLYFIz HOlLuZX0+kHXj46Mkq2Z1hHW1iV967na7rQWXKtZCe8N1LnkW2762Hjlr5OO6+lz0TOFOwuj 7mRnYVpV3uCf3snstsoph+vsjXuJ6rCtaAXBaumYcNzM0v8A/Qix6WoDAAA= Cc: "'randy@qti.qualcomm.com'" , "'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: Mon, 03 Jun 2013 20:58:12 -0000 No, I have two companies that provide that access service. In this case I want a single URI that return two provider data blobs.=20 Cheers James ----- Original Message ----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, June 03, 2013 10:00 PM=0A= To: Winterbottom, James Cc: Hannes Tschofenig ; Randall Gellens ; Brian Rosen ; ecrit@ietf.org Subject: Re: [Ecrit] Additional Data: Transport Related Question That would mean we would need the Additional Data by Reference to be a web = service where you could list all the mime types and get them all in one ope= ration. The current situation is that you get a URI for each block with a parameter= that tells you what type it is, and you fetch them one by one. =20 Brian On Jun 2, 2013, at 11:32 PM, "Winterbottom, James" wrote: > Hi Hannes, >=20 > I think I would change the last sentence of the proposed new 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 structure types." >=20 > This allows multiple structures of the same type to be fetched at the sam= e time. > For example a NENA LIF could return multiple emergencyCall.ProviderInfo s= tructures depending on what is provisioned. >=20 > Cheers > James >=20 >=20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Saturday, 1 June 2013 12:47 AM > To: Randall Gellens > Cc: Hannes Tschofenig; Winterbottom, James; Brian Rosen; ecrit@ietf.org > Subject: Re: [Ecrit] Additional Data: Transport Related Question >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Thanks for the feedback.=20 >=20 > To close this open issue I am suggesting to make the following change to = the draft for improved clarity: >=20 > Change from >=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 >=20 > to:=20 >=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 would also suggest to add the example to the draft.=20 >=20 > Ciao > Hannes >=20 > On May 31, 2013, at 3:28 AM, Randall Gellens wrote: >=20 >> Hi everyone, >>=20 >> James' response matches my understanding: there is no wrapping or encaps= ulation; the MIME type is used to identify the type of data. In the exampl= e Hannes provided, the MIME type "application/emergencyCall.SubInfo+xml" id= entifies the data. >>=20 >> (When the data is carried in the SIP body, MIME Multipart/Mixed is=20 >> used to separate the body parts, so in that sense, Multipart/Mixed=20 >> encapsulates the data, but at least for body parts which are XML or=20 >> other textual data, the individual MIME types of each body part only=20 >> 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 bod= y are xml that refer to a specific type of object. This is kind and cost no= thing since the MIME types already exist. >>>=20 >>> Secondly, it can be used in the header of the actual request to indicat= e 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=20 >>> 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 y= ou 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 th= at is carried in SIP and in HTTP. >>>=20 >>> Here is an example. Imagine that a PSAP obtains an HTTPS URI pointing t= o 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 >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- 640K ought to be=20 >> enough for anybody. --Bill Gates, 1981 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org >=20 > iQEcBAEBCgAGBQJRqLfwAAoJEGhJURNOOiAtL4YH/imeY3yr7trGPHzgRWj7v76P > a+d6EUbopG3/j8K3llaSeuT6lcYEXgn6PRqL4gMffttlCYZNeVbByVpfiOq5AE3z > bTT8xb6/1LWXCJ/xb8zb3wFMAkcQbunbat6cgWKmfqQ6hXR90boV4nMdid407Efc > Ku1uDQ/ePhaZVWwjNzFjmo0WvaQfky8FXevGTP35hhGBWBRXoMeksjrP66pXF0Fp > 2tdC70PksCJECF6HMnfY0p0d3TP+Pgq0zs8j4A4zog1wO8PHpqQrTsZ63vJ9cLTO > 2ZQAZEeE9krWivBaAQDe+f1Di2ReuVuvmMwcgC1ynhp9PtWpK3LXb4lcQqpikW4=3D > =3D05bX > -----END PGP SIGNATURE----- From br@brianrosen.net Mon Jun 3 14:05:38 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 DDB9B11E80F6 for ; Mon, 3 Jun 2013 14:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 VWI95wvQ-Qso for ; Mon, 3 Jun 2013 14:05:25 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 99F1A21F972C for ; Mon, 3 Jun 2013 13:58:05 -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=DnAWX7MwxKg8hUURKEbAQC5Pjxy29tYOpbeiFdgpTQ4=; b=EW7OevC0ZlXXPpirDCdpmCunajR6cHM+PgIRlxIeGWxxxvG7g3ZwpW+UapC7anrBRF8qPtIlR8QB1hHqqHp5Q/2qoMSL7nOFUFBasdTXabUCsAq01XKs/jax5LLb3532p6MRHY260m4M4BtRf9HKrRx2d90ACIW2J5Ww7mTg6IU=; Received: from neustargw.va.neustar.com ([209.173.53.233]:35995 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UjbpL-0000ja-Um; Mon, 03 Jun 2013 16:58:04 -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: <5A55A45AE77F5941B18E5457ECAC81880121407DA0F8@SISPE7MB1.commscope.com> Date: Mon, 3 Jun 2013 16:58:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A55A45AE77F5941B18E5457ECAC81880121407DA0F8@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: "'randy@qti.qualcomm.com'" , "'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: Mon, 03 Jun 2013 21:05:39 -0000 Sorry, I don't understand this case. An access network would provide a PIDF with a provided-by that had the = URI in it. That would be the (single) access provider who provided the = PIDF. How do I get two access providers and how does one PIDF have data from = both of them? Brian On Jun 3, 2013, at 4:53 PM, "Winterbottom, James" = wrote: > No, I have two companies that provide that access service. > In this case I want a single URI that return two provider data blobs.=20= >=20 > Cheers > James >=20 > ----- Original Message ----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, June 03, 2013 10:00 PM > To: Winterbottom, James > Cc: Hannes Tschofenig ; Randall Gellens = ; Brian Rosen ; = ecrit@ietf.org > Subject: Re: [Ecrit] Additional Data: Transport Related Question >=20 > That would mean we would need the Additional Data by Reference to be a = web service where you could list all the mime types and get them all in = one operation. >=20 > The current situation is that you get a URI for each block with a = parameter that tells you what type it is, and you fetch them one by one. = =20 >=20 > Brian >=20 > On Jun 2, 2013, at 11:32 PM, "Winterbottom, James" = wrote: >=20 >> Hi Hannes, >>=20 >> I think I would change the last sentence of the proposed new 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 structure types." >>=20 >> This allows multiple structures of the same type to be fetched at the = same time. >> For example a NENA LIF could return multiple = emergencyCall.ProviderInfo structures depending on what is provisioned. >>=20 >> Cheers >> James >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >> Sent: Saturday, 1 June 2013 12:47 AM >> To: Randall Gellens >> Cc: Hannes Tschofenig; Winterbottom, James; Brian Rosen; = ecrit@ietf.org >> Subject: Re: [Ecrit] Additional Data: Transport Related Question >>=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >>=20 >> Thanks for the feedback.=20 >>=20 >> To close this open issue I am suggesting to make the following change = to the draft for improved clarity: >>=20 >> Change from >>=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 >>=20 >> to:=20 >>=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 would also suggest to add the example to the draft.=20 >>=20 >> Ciao >> Hannes >>=20 >> On May 31, 2013, at 3:28 AM, Randall Gellens wrote: >>=20 >>> 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=20= >>> used to separate the body parts, so in that sense, Multipart/Mixed=20= >>> encapsulates the data, but at least for body parts which are XML or=20= >>> other textual data, the individual MIME types of each body part only=20= >>> 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=20 >>>> 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 >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself = only >>> -------------- Randomly selected tag: --------------- 640K ought to = be=20 >>> enough for anybody. --Bill Gates, 1981 >>=20 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >> Comment: GPGTools - http://gpgtools.org >>=20 >> iQEcBAEBCgAGBQJRqLfwAAoJEGhJURNOOiAtL4YH/imeY3yr7trGPHzgRWj7v76P >> a+d6EUbopG3/j8K3llaSeuT6lcYEXgn6PRqL4gMffttlCYZNeVbByVpfiOq5AE3z >> bTT8xb6/1LWXCJ/xb8zb3wFMAkcQbunbat6cgWKmfqQ6hXR90boV4nMdid407Efc >> Ku1uDQ/ePhaZVWwjNzFjmo0WvaQfky8FXevGTP35hhGBWBRXoMeksjrP66pXF0Fp >> 2tdC70PksCJECF6HMnfY0p0d3TP+Pgq0zs8j4A4zog1wO8PHpqQrTsZ63vJ9cLTO >> 2ZQAZEeE9krWivBaAQDe+f1Di2ReuVuvmMwcgC1ynhp9PtWpK3LXb4lcQqpikW4=3D >> =3D05bX >> -----END PGP SIGNATURE----- >=20 From randy@qti.qualcomm.com Mon Jun 3 15:45: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 1D18A21F90A5 for ; Mon, 3 Jun 2013 15:45:58 -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 ZH1FP6s+hOUO for ; Mon, 3 Jun 2013 15:45:42 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 51B0E11E80BA for ; Mon, 3 Jun 2013 15:42:12 -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=1370299336; x=1401835336; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=tQfbE3MHGBXyU2JFcC69MzRdScGbQSZj09eNaU0D+3I=; b=wY1zKfwnpI7tBtt14RR+n0IPyyvzGtbU12sgyfphZGX212jksP9YmygT Qd0l25Fuk3ix5M6EANuMUctaXjvtVFoOCVOB0F/PxR+I86UUnqKMW3rsZ hyUu4yk9QaZ10KRKzd1EptIP/flVI07dn3Uz0KI1oKvA2btt2gZ8xOptd Q=; X-IronPort-AV: E=Sophos;i="4.87,795,1363158000"; d="scan'208";a="43123766" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 03 Jun 2013 15:41:58 -0700 Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jun 2013 15:41:57 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 3 Jun 2013 15:35:31 -0700 Message-ID: In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880121407DA0F8@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880121407DA0F8@SISPE7MB1.commscope.com> X-Mailer: Eudora for Mac OS X Date: Mon, 3 Jun 2013 15:26:12 -0700 To: "Winterbottom, James" , "'br@brianrosen.net'" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: "'randy@qti.qualcomm.com'" , "'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: Mon, 03 Jun 2013 22:45:58 -0000 The model of one URI = one block makes sense for a number of reasons, including that it makes it easy for the emergency service agency to decide which blocks to access. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Did you know that clones never use mirrors? From James.Winterbottom@commscope.com Mon Jun 3 15:48: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 33C3D21F962B for ; Mon, 3 Jun 2013 15:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 wJlaYuAagzgh for ; Mon, 3 Jun 2013 15:48:15 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id 58A3411E8144 for ; Mon, 3 Jun 2013 15:43:23 -0700 (PDT) X-AuditID: 0a0404e8-b7fdb6d000001d37-49-51ad1c0a8c4c Received: from CDCE10HC2.commscope.com ( [10.86.28.22]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id 18.7D.07479.A0C1DA15; Mon, 3 Jun 2013 17:43:22 -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; Mon, 3 Jun 2013 17:43:22 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 4 Jun 2013 06:39:53 +0800 From: "Winterbottom, James" To: Brian Rosen Date: Tue, 4 Jun 2013 06:39:51 +0800 Thread-Topic: [Ecrit] Additional Data: Transport Related Question Thread-Index: Ac5gnQ8V4OtWoM64Rq6kahh8BNN3HgADaBQQ Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121409BB12D@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880121407DA0F8@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: H4sIAAAAAAAAA01SW0hTYRzn2zk7O46dOM3LPi+IHSVlamn6sEBEy4f15gV6CMuWHp2xi+x4 zwcVIxMR8dbcIC+tJC/NNLN5IVArp5D5kISZi5wzNYIUTYuic3bUfPn4ffxu35/vjyNSl9AP z9Xl0wadSkNhYlR8OcAnUhzQlxI1XH5KsepowRQVnatCxUPbslCx8KUaSUCVjt0/IuWDgZeY 0mLZFyg7m10gGb0ijsuiNbmFtOFs/HWxusl1G82bzyv+3DGCloPa1BrggUMyFg5NjYp47APf LVuxGiDGpeQIgNOPtwF/sQJovG87YPoA3DG2YJwFI+PhpPUDwmEvMhjaFu+KOBFCmgEcHFlz 56JkCHxd+UvAYU8yAXZtb4t4QyJ07e8e4HPw06sfbg1BpkKLZQhwWErWADjVE8hhD/ICdM23 ufWAfevPmV63HiFlcNHZJuBnIKFlbA7hsTdcX/kr5PXecOmOFfD6CNg+uoXxOBw+6thE+N6T 0N7qRPneSFhp2xHWA2g6VmE6Zjcds5uO2dsB2g1kmVmZjDanKCr6TKZeq2Uy9Xk0hwYA96Eo +vUFmO0PnwAkDigJEfSsN0UqVBUyJdoJ4IsLKG+i1KcvRXrihj6rRK1i1BmGAg3NTACII5QX 8f4NKyeyVCWltEF/SIXhODnrdMwAP1Sn19EUJKr82YiTBjqHLs7O1bD7dCgV4B5clISNKuU0 BJOn0jK5OTw/A6LxwbnG7wA3tjaz5/wke0rdoX4yoo4zkJxBXaA7ytwAMnYQT6KIYyXs8h6l bbBFAraocbObK8pX/af8ysHpgvDE4Le3goxbsQ0bmCDJHLi80m/0B43mcSin7LaxCGYhMt1u ZowRV+sy6m823Nt6mhIEay/FhIauNbnsiWXyuPCQNd+9ZIeI6t8bLsOcMWk91WnnL2qeh3Q9 iZSXh/WnD3zzT0v6vS5rkVwbal1atH50VtWEZo9P769VUCijVkXLEQOj+gdDgYWFeQMAAA== Cc: "'randy@qti.qualcomm.com'" , "'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: Mon, 03 Jun 2013 22:48:28 -0000 Brian, I can have up to 3 different organizations coming together to provide a dom= estic broadband service in many countries. In my case, my ISP knows who my = layers 2 and physical access providers are. They could easily therefore hav= e three provider data blobs one for them and one for each of the others. In= this case I want to only provide a single URI and get back all three data = provider blobs. This would be valid using the MIME in the HTTP header anywa= y. All I am asking for is for the text to say so. Cheers James -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, 4 June 2013 6:58 AM To: Winterbottom, James Cc: 'br@brianrosen.net'; 'hannes.tschofenig@gmx.net'; 'randy@qti.qualcomm.c= om'; 'ecrit@ietf.org' Subject: Re: [Ecrit] Additional Data: Transport Related Question Sorry, I don't understand this case. An access network would provide a PIDF with a provided-by that had the URI = in it. That would be the (single) access provider who provided the PIDF. How do I get two access providers and how does one PIDF have data from both= of them? Brian On Jun 3, 2013, at 4:53 PM, "Winterbottom, James" wrote: > No, I have two companies that provide that access service. > In this case I want a single URI that return two provider data blobs.=20 >=20 > Cheers > James >=20 > ----- Original Message ----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, June 03, 2013 10:00 PM > To: Winterbottom, James > Cc: Hannes Tschofenig ; Randall Gellens=20 > ; Brian Rosen ;=20 > ecrit@ietf.org > Subject: Re: [Ecrit] Additional Data: Transport Related Question >=20 > That would mean we would need the Additional Data by Reference to be a we= b service where you could list all the mime types and get them all in one o= peration. >=20 > The current situation is that you get a URI for each block with a paramet= er that tells you what type it is, and you fetch them one by one. =20 >=20 > Brian >=20 > On Jun 2, 2013, at 11:32 PM, "Winterbottom, James" wrote: >=20 >> Hi Hannes, >>=20 >> I think I would change the last sentence of the proposed new 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 structure types." >>=20 >> This allows multiple structures of the same type to be fetched at the sa= me time. >> For example a NENA LIF could return multiple emergencyCall.ProviderInfo = structures depending on what is provisioned. >>=20 >> Cheers >> James >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Saturday, 1 June 2013 12:47 AM >> To: Randall Gellens >> Cc: Hannes Tschofenig; Winterbottom, James; Brian Rosen;=20 >> ecrit@ietf.org >> Subject: Re: [Ecrit] Additional Data: Transport Related Question >>=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >>=20 >> Thanks for the feedback.=20 >>=20 >> To close this open issue I am suggesting to make the following change to= the draft for improved clarity: >>=20 >> Change from >>=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 >>=20 >> to:=20 >>=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 would also suggest to add the example to the draft.=20 >>=20 >> Ciao >> Hannes >>=20 >> On May 31, 2013, at 3:28 AM, Randall Gellens wrote: >>=20 >>> Hi everyone, >>>=20 >>> James' response matches my understanding: there is no wrapping or encap= sulation; the MIME type is used to identify the type of data. In the examp= le Hannes provided, the MIME type "application/emergencyCall.SubInfo+xml" i= dentifies the data. >>>=20 >>> (When the data is carried in the SIP body, MIME Multipart/Mixed is=20 >>> used to separate the body parts, so in that sense, Multipart/Mixed=20 >>> encapsulates the data, but at least for body parts which are XML or=20 >>> other textual data, the individual MIME types of each body part only=20 >>> 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 bo= dy are xml that refer to a specific type of object. This is kind and cost n= othing since the MIME types already exist. >>>>=20 >>>> Secondly, it can be used in the header of the actual request to indica= te 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=20 >>>> 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 woul= d 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=20 >>>> that data of MIME type 'application/emergencyCall.ProviderInfo+xml'=20 >>>> or whatever is being sent? >>>>=20 >>>> If I'm incorrect and the data is not identified as a MIME type,=20 >>>> then 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=20 >>>> should 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=20 >>>> separate from the use of MIME body parts inside the SIP body to=20 >>>> delineate the various parts. >>>>=20 >>>> My understanding so far was that MIME encapsulation is used for data t= hat 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 >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself only >>> -------------- Randomly selected tag: --------------- 640K ought to=20 >>> be enough for anybody. --Bill Gates, 1981 >>=20 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >> Comment: GPGTools - http://gpgtools.org >>=20 >> iQEcBAEBCgAGBQJRqLfwAAoJEGhJURNOOiAtL4YH/imeY3yr7trGPHzgRWj7v76P >> a+d6EUbopG3/j8K3llaSeuT6lcYEXgn6PRqL4gMffttlCYZNeVbByVpfiOq5AE3z >> bTT8xb6/1LWXCJ/xb8zb3wFMAkcQbunbat6cgWKmfqQ6hXR90boV4nMdid407Efc >> Ku1uDQ/ePhaZVWwjNzFjmo0WvaQfky8FXevGTP35hhGBWBRXoMeksjrP66pXF0Fp >> 2tdC70PksCJECF6HMnfY0p0d3TP+Pgq0zs8j4A4zog1wO8PHpqQrTsZ63vJ9cLTO >> 2ZQAZEeE9krWivBaAQDe+f1Di2ReuVuvmMwcgC1ynhp9PtWpK3LXb4lcQqpikW4=3D >> =3D05bX >> -----END PGP SIGNATURE----- >=20 From br@brianrosen.net Mon Jun 3 16:15: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 141E921E80A4 for ; Mon, 3 Jun 2013 16:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 Td8bC960LYOo for ; Mon, 3 Jun 2013 16:15:22 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 46A9321F888F for ; Mon, 3 Jun 2013 16:12:38 -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=mSt0PHry+QDJutOROubxP2hJMDK/R08Kqs1KclN7+Io=; b=Mz50dnlBI3RtpFc/vQBMEEqFni1LgQ46o7z9Jg+WuFPGADd7MsUUFsisVxyYwIdPsMRlHG9KpGObofh6duwrLL672qmCBJsKOE9F0ZDRfewNplEz+4k8p682uLMISpT0gVazmRf0qYReGc2uG424zKo/gX6Ovcu7HtwtBgcbJAg=; Received: from neustargw.va.neustar.com ([209.173.53.233]:35361 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UjdvY-0008D1-2i; Mon, 03 Jun 2013 19:12:36 -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: <5A55A45AE77F5941B18E5457ECAC81880121409BB12D@SISPE7MB1.commscope.com> Date: Mon, 3 Jun 2013 19:12:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A55A45AE77F5941B18E5457ECAC81880121407DA0F8@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC81880121409BB12D@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: "'randy@qti.qualcomm.com'" , "'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: Mon, 03 Jun 2013 23:15:37 -0000 The stated reason for having separate blocks is to allow PSAPs to = control what they download. This is going in the other direction. It also begs the question of who hosts the blocks for the other = providers, but they could decide that themselves. =20 Brian On Jun 3, 2013, at 6:39 PM, "Winterbottom, James" = wrote: > Brian, >=20 > I can have up to 3 different organizations coming together to provide = a domestic broadband service in many countries. In my case, my ISP knows = who my layers 2 and physical access providers are. They could easily = therefore have three provider data blobs one for them and one for each = of the others. In this case I want to only provide a single URI and get = back all three data provider blobs. This would be valid using the MIME = in the HTTP header anyway. All I am asking for is for the text to say = so. >=20 > Cheers > James >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, 4 June 2013 6:58 AM > To: Winterbottom, James > Cc: 'br@brianrosen.net'; 'hannes.tschofenig@gmx.net'; = 'randy@qti.qualcomm.com'; 'ecrit@ietf.org' > Subject: Re: [Ecrit] Additional Data: Transport Related Question >=20 > Sorry, I don't understand this case. >=20 > An access network would provide a PIDF with a provided-by that had the = URI in it. That would be the (single) access provider who provided the = PIDF. >=20 > How do I get two access providers and how does one PIDF have data from = both of them? >=20 > Brian >=20 > On Jun 3, 2013, at 4:53 PM, "Winterbottom, James" = wrote: >=20 >> No, I have two companies that provide that access service. >> In this case I want a single URI that return two provider data blobs.=20= >>=20 >> Cheers >> James >>=20 >> ----- Original Message ----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Monday, June 03, 2013 10:00 PM >> To: Winterbottom, James >> Cc: Hannes Tschofenig ; Randall Gellens=20 >> ; Brian Rosen ;=20 >> ecrit@ietf.org >> Subject: Re: [Ecrit] Additional Data: Transport Related Question >>=20 >> That would mean we would need the Additional Data by Reference to be = a web service where you could list all the mime types and get them all = in one operation. >>=20 >> The current situation is that you get a URI for each block with a = parameter that tells you what type it is, and you fetch them one by one. = =20 >>=20 >> Brian >>=20 >> On Jun 2, 2013, at 11:32 PM, "Winterbottom, James" = wrote: >>=20 >>> Hi Hannes, >>>=20 >>> I think I would change the last sentence of the proposed new 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 structure types." >>>=20 >>> This allows multiple structures of the same type to be fetched at = the same time. >>> For example a NENA LIF could return multiple = emergencyCall.ProviderInfo structures depending on what is provisioned. >>>=20 >>> Cheers >>> James >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Saturday, 1 June 2013 12:47 AM >>> To: Randall Gellens >>> Cc: Hannes Tschofenig; Winterbottom, James; Brian Rosen;=20 >>> ecrit@ietf.org >>> Subject: Re: [Ecrit] Additional Data: Transport Related Question >>>=20 >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>>=20 >>> Thanks for the feedback.=20 >>>=20 >>> To close this open issue I am suggesting to make the following = change to the draft for improved clarity: >>>=20 >>> Change from >>>=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 >>>=20 >>> to:=20 >>>=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 would also suggest to add the example to the draft.=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>> On May 31, 2013, at 3:28 AM, Randall Gellens wrote: >>>=20 >>>> 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=20= >>>> used to separate the body parts, so in that sense, Multipart/Mixed=20= >>>> encapsulates the data, but at least for body parts which are XML or=20= >>>> other textual data, the individual MIME types of each body part = only=20 >>>> 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=20 >>>>> 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=20= >>>>> that data of MIME type = 'application/emergencyCall.ProviderInfo+xml'=20 >>>>> or whatever is being sent? >>>>>=20 >>>>> If I'm incorrect and the data is not identified as a MIME type,=20 >>>>> then 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=20 >>>>> should 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=20 >>>>> separate from the use of MIME body parts inside the SIP body to=20 >>>>> delineate the 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 >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself = only >>>> -------------- Randomly selected tag: --------------- 640K ought to=20= >>>> be enough for anybody. --Bill Gates, 1981 >>>=20 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >>> Comment: GPGTools - http://gpgtools.org >>>=20 >>> iQEcBAEBCgAGBQJRqLfwAAoJEGhJURNOOiAtL4YH/imeY3yr7trGPHzgRWj7v76P >>> a+d6EUbopG3/j8K3llaSeuT6lcYEXgn6PRqL4gMffttlCYZNeVbByVpfiOq5AE3z >>> bTT8xb6/1LWXCJ/xb8zb3wFMAkcQbunbat6cgWKmfqQ6hXR90boV4nMdid407Efc >>> Ku1uDQ/ePhaZVWwjNzFjmo0WvaQfky8FXevGTP35hhGBWBRXoMeksjrP66pXF0Fp >>> 2tdC70PksCJECF6HMnfY0p0d3TP+Pgq0zs8j4A4zog1wO8PHpqQrTsZ63vJ9cLTO >>> 2ZQAZEeE9krWivBaAQDe+f1Di2ReuVuvmMwcgC1ynhp9PtWpK3LXb4lcQqpikW4=3D >>> =3D05bX >>> -----END PGP SIGNATURE----- >>=20 >=20 From James.Winterbottom@commscope.com Mon Jun 3 16:38:42 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 AFE7221E8097 for ; Mon, 3 Jun 2013 16:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.233, 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 cwoGBUl8-d0m for ; Mon, 3 Jun 2013 16:38:25 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id D6C9E21E80A0 for ; Mon, 3 Jun 2013 16:29:31 -0700 (PDT) X-AuditID: 0a0404e8-b7fdb6d000001d37-7a-51ad26c3554f Received: from CDCE10HC2.commscope.com ( [10.86.28.22]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id 47.0E.07479.3C62DA15; Mon, 3 Jun 2013 18:29:07 -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; Mon, 3 Jun 2013 18:29:06 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 4 Jun 2013 07:29:03 +0800 From: "Winterbottom, James" To: Brian Rosen Date: Tue, 4 Jun 2013 07:29:02 +0800 Thread-Topic: [Ecrit] Additional Data: Transport Related Question Thread-Index: Ac5gr9lj6IG3MJznTPGGP8d86LouLwAAg0kA Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121409BB131@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880121407DA0F8@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC81880121409BB12D@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: H4sIAAAAAAAAA01Sa0hTURz37N47r8sr1+tjJ/FD3CxCM136YR9CLIxGUKmYVF9sbVc32Ktd 31iYUPnAUMzwQfhomom6fBRNhUg/RFpYDCOGaI/5SMOhU5eR1r27aX45/A6/1/9w/jhCzWNh uNaQzZgNSh0tlqCS9PDQ6NHD3SmxLWtS+ezMA7H8VussJm+zTWPyj19LkURUMbOx5at41PdS rLBYNkWK1to5kIxekZxQMzptLmOOSbgq0Ty58w6YxvPzG3+VIsWg/XI58MMhGQ83XHaxgEPh +2krhyU4RQ4CONmzjQoXK4Bv7dUi4dIN4MrWGuAtYjIBjlo/ITwOJg9Cm6PMlxchZCOA/YPz vjyBkhGwaqUO5XEQmQgfu92+guEknNvc+IePwy+lkyIeE2Qq7BjuxYS2ChG02FwYT/iRp2BZ 2R2vAXDDesa6vAaElEKHs0kkPIKEluEJRMAh8Pu3bUzQh8Cpu1Yg6I/C5qFVsYCjYHvLEiIU B8I39U7voBQZDUts61gVgA17Khr22Bv22Bv22JsB2gmkKrWK1WflxcqOqYx6Pasymhge9QH+ R1F04QUYfxo1Akgc0P7EgYGuFApT5rIF+hGwHxfRIQSM6E6hAq4Z1QUaJavJMOfoGHYEQByh g4nJ15ycUCsLChmzcYc6guPkuHNmDIShBqOBoSGxcIiLCDQzWUx+plbHLdSOVIT78VH+XNQ9 XkOwJqWe1WYJ/BiQ4f0TNcsAr6uv5c4Po9xJeUPDpISLN5C8QZNj2M1cBFLuIUGEhFtTyp/b 3t20Ra5IxBXVLHXyRdnK/1RYMbif6jp9Pi6tUuq5EJkqM6Z40pvc7lc3VTaf9so1hdhnOSNt pKfbTqvK0+0dljzHlHWprzXGEz5aEnQD7luvdjo+354rTI0n4vAi0w8skklyX5TLVpPY65m6 3+7knwGmTab3XFpb+FDFQBFdeyl56MzD9efLJfNnKWfHsz8MjbIapSwSMbPKvwRU7U16AwAA Cc: "'randy@qti.qualcomm.com'" , "'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: Mon, 03 Jun 2013 23:38:42 -0000 I don't think that they can decide it for themselves easily Brian. There is not enough granularity in the current ref Uri definitions to provi= de the degree of visibility that you describe here, so at present it seems = to me that either we allow multiple blocks of the same type to be returned = from the same fetch or the information ins't provided to the PSAP at all. Cheers James -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, 4 June 2013 9:13 AM To: Winterbottom, James Cc: Brian Rosen; 'hannes.tschofenig@gmx.net'; 'randy@qti.qualcomm.com'; 'ec= rit@ietf.org' Subject: Re: [Ecrit] Additional Data: Transport Related Question The stated reason for having separate blocks is to allow PSAPs to control w= hat they download. This is going in the other direction. It also begs the question of who hosts the blocks for the other providers, = but they could decide that themselves. Brian On Jun 3, 2013, at 6:39 PM, "Winterbottom, James" wrote: > Brian, > > I can have up to 3 different organizations coming together to provide a d= omestic broadband service in many countries. In my case, my ISP knows who m= y layers 2 and physical access providers are. They could easily therefore h= ave three provider data blobs one for them and one for each of the others. = In this case I want to only provide a single URI and get back all three dat= a provider blobs. This would be valid using the MIME in the HTTP header any= way. All I am asking for is for the text to say so. > > Cheers > James > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, 4 June 2013 6:58 AM > To: Winterbottom, James > Cc: 'br@brianrosen.net'; 'hannes.tschofenig@gmx.net'; 'randy@qti.qualcomm= .com'; 'ecrit@ietf.org' > Subject: Re: [Ecrit] Additional Data: Transport Related Question > > Sorry, I don't understand this case. > > An access network would provide a PIDF with a provided-by that had the UR= I in it. That would be the (single) access provider who provided the PIDF. > > How do I get two access providers and how does one PIDF have data from bo= th of them? > > Brian > > On Jun 3, 2013, at 4:53 PM, "Winterbottom, James" wrote: > >> No, I have two companies that provide that access service. >> In this case I want a single URI that return two provider data blobs. >> >> Cheers >> James >> >> ----- Original Message ----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Monday, June 03, 2013 10:00 PM >> To: Winterbottom, James >> Cc: Hannes Tschofenig ; Randall Gellens >> ; Brian Rosen ; >> ecrit@ietf.org >> Subject: Re: [Ecrit] Additional Data: Transport Related Question >> >> That would mean we would need the Additional Data by Reference to be a w= eb service where you could list all the mime types and get them all in one = operation. >> >> The current situation is that you get a URI for each block with a parame= ter that tells you what type it is, and you fetch them one by one. >> >> Brian >> >> On Jun 2, 2013, at 11:32 PM, "Winterbottom, James" wrote: >> >>> Hi Hannes, >>> >>> I think I would change the last sentence of the proposed new 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 structure types." >>> >>> This allows multiple structures of the same type to be fetched at the s= ame time. >>> For example a NENA LIF could return multiple emergencyCall.ProviderInfo= structures depending on what is provisioned. >>> >>> Cheers >>> James >>> >>> >>> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Saturday, 1 June 2013 12:47 AM >>> To: Randall Gellens >>> Cc: Hannes Tschofenig; Winterbottom, James; Brian Rosen; >>> ecrit@ietf.org >>> Subject: Re: [Ecrit] Additional Data: Transport Related Question >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>> >>> Thanks for the feedback. >>> >>> To close this open issue I am suggesting to make the following change t= o 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: >>> >>> " >>> 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. >>> >>> Ciao >>> Hannes >>> >>> On May 31, 2013, at 3:28 AM, Randall Gellens wrote: >>> >>>> Hi everyone, >>>> >>>> James' response matches my understanding: there is no wrapping or enca= psulation; the MIME type is used to identify the type of data. In the exam= ple 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 wit= h MIME, you are simply signaling to the receiver that the contents of the b= ody 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 indic= ate what the receiver is expecting to get back. >>>>> >>>>> I will add that both HELD and LoST specify and use MIME types in thei= r 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 the= m 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 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 wou= ld 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=3Dutf-8 >>>>> Content-Length: tbd >>>>> >>>>> >>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 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 onl= y >>>> -------------- 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----- >> > From James.Winterbottom@commscope.com Mon Jun 3 21:02:39 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 24A5621F99AE for ; Mon, 3 Jun 2013 21:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 dOghdouJjzck for ; Mon, 3 Jun 2013 21:02:25 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id A588511E8179 for ; Mon, 3 Jun 2013 20:05:33 -0700 (PDT) X-AuditID: 0a0404e8-b7fdb6d000001d37-aa-51ad597c47bd Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id 70.A0.07479.C795DA15; Mon, 3 Jun 2013 22:05:32 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 3 Jun 2013 22:05:31 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 4 Jun 2013 11:05:26 +0800 From: "Winterbottom, James" To: Randall Gellens , Brian Rosen Date: Tue, 4 Jun 2013 11:05:24 +0800 Thread-Topic: [Ecrit] Additional Data: Transport Related Question Thread-Index: Ac5guwdmnLI09d9BR9WSy3dqgjxCdQAFIt7A Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140A08E37@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880121407DA0F8@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC81880121409BB12D@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC81880121409BB131@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: H4sIAAAAAAAAA01SfUgTYRjnvbvNc+zknF9vQySGQbQsjaD9YcNCclGSGkkJkWs73dJtttOl krA+oA8QFmrgLDKbJupaOleaZTCNUEEToSTEiU7Jj7Q0FcNJdzu1/fd7+X09D++DoyIPT4xr 9YWUUa/Ml/AFmCAzOiLu5iV7evzTTzGyac9jvuxW3TRPVt85zpN9nbyPJmEKz5ovSPGi7SNf YbNtIIq6qhmQhmUJEtVUvtZEGQ/LswWa5u5JUHD3ESjuc8jNwJr3EATjkDwK6xcm+ByOhF/G HQwW4CLyHYAPfDU87uEAcOtVM8o97ADaJn9irIVPymGPYxRlcTiZCl0LZsBilFTDP22tCIsx Mha6Nn/5K8LIJPhyZSWI05+AMxtr2/gIdFa7GC+OE2QGfOLWcl1bCPxc882vCWZHdXn9OYAZ db2/BeG6ouB37zOEW4GEtvdDKIcj4OzUFo/TR8Cxe47t2Q7C2q5lPoelsOH5vF9PkKGwr9rr 30tExsHbnas8C4DWgAprgN0aYLcG2GsB1gSiVGoVrcu9EZ9wSGXQ6WiVoYBiURtg/xPDfnSA gddSNyBxIBESe9tb0kU8pYku0bnBHhyRRBCD5+3popCrBnWJRklrrhiL8inaDSCOSsKJ8mSG I9TKklLKaNih9uM4OeD19AMxpjfoKQkkqIuMLNRI5VLFOdp85px2pAgezEYJmagsVkPQBUod rc3l+H4gxZ1DFYsAH+6pWgQif5w4ipOSrFRTpN9NmwNRzAphRCbLCpmr3c2ZYyoQpqJivomt KFT+p8RmwDsVZqosTdRv5mSeK7PP7rO8pfi9w9E1Y6Yz5tw1zbWRjlVi8PiUvLFcOLSuGkvx TjRsjrdKI8uGhhvvdC1VnW0fsWtUyXlvzMLTW74UY1Nyi8XizO7OOFl5vd5pEfX+nrn8N63t WE2IKqY29MPy6FK9zEebUmMvFAmil5qzJBitUSYcQI208h9BhPsdcgMAAA== 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, 04 Jun 2013 04:02:39 -0000 Hi Randy, Some of what you are suggesting are is right, some seemed to diverge. See inline. -----Original Message----- From: Randall Gellens [mailto:randy@qti.qualcomm.com] Sent: Tuesday, 4 June 2013 10:33 AM To: Winterbottom, James; Brian Rosen Cc: 'hannes.tschofenig@gmx.net'; 'randy@qti.qualcomm.com'; 'ecrit@ietf.org' Subject: RE: [Ecrit] Additional Data: Transport Related Question Hi James, Let me see if I understand your case: The ISP knows the underlying access provider and has a business rel= ationship with it (one example I'm guessing would be your National Broadban= d Network). The ISP is happy to supply Provider Info blocks for itself and= the underlying NBN. [AJW] Yes, this right. In this case, there are multiple possible ways to make the Provider Info bl= ocks available. E.g., - The ISP adds two Provider Info URIs: its own and another for the = NBN [AJW] This is "sort of" the case I am discussing. If the ISP adds t= wo URIs then there is no way for the PSAP to look at the URI and say "AH!! = I want this one", it has to deference both and then look at the various ele= ments in the responses to work out which order to interpret them in. I am p= roposing that the ISP supply one Data Provider URI. Accessing this URI will= only return Data Provider elements, but it may return more than one Data P= rovider element if the ISP is providing information for more than just itse= lf. Under the current scheme this is legal. or - The ISP adds one URI for its own Provider Info and - The NBN uses the provided-by element in a PIDF-LO to supply a URI= for its info [AJW] No, not this case. But you seem to be discussing a case where multiple entities need to use th= e provided-by element of a PIDF-LO. Is that right? If so, the problem is = that the PIDF-LO schema restricts to zero or one occurrence, = prohibiting the use of two elements. [AJW] This is not what I am suggesting at all. At 7:29 AM +0800 6/4/13, James Winterbottom wrote: > I don't think that they can decide it for themselves easily Brian. > There is not enough granularity in the current ref Uri definitions to > provide the degree of visibility that you describe here, so at present > it seems to me that either we allow multiple blocks of the same type > to be returned from the same fetch or the information ins't provided > to the PSAP at all. > > Cheers > James > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, 4 June 2013 9:13 AM > To: Winterbottom, James > Cc: Brian Rosen; 'hannes.tschofenig@gmx.net'; > 'randy@qti.qualcomm.com'; 'ecrit@ietf.org' > Subject: Re: [Ecrit] Additional Data: Transport Related Question > > The stated reason for having separate blocks is to allow PSAPs to > control what they download. This is going in the other direction. > It also begs the question of who hosts the blocks for the other > providers, but they could decide that themselves. > > Brian > > On Jun 3, 2013, at 6:39 PM, "Winterbottom, James" > wrote: > >> Brian, >> >> I can have up to 3 different organizations coming together to >> provide a domestic broadband service in many countries. In my case, >> my ISP knows who my layers 2 and physical access providers are. They >> could easily therefore have three provider data blobs one for them >> and one for each of the others. In this case I want to only provide a >> single URI and get back all three data provider blobs. This would be >> valid using the MIME in the HTTP header anyway. All I am asking for >> is for the text to say so. >> >> Cheers >> James >> >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Tuesday, 4 June 2013 6:58 AM >> To: Winterbottom, James >> Cc: 'br@brianrosen.net'; 'hannes.tschofenig@gmx.net'; >> 'randy@qti.qualcomm.com'; 'ecrit@ietf.org' >> Subject: Re: [Ecrit] Additional Data: Transport Related Question >> >> Sorry, I don't understand this case. >> > > An access network would provide a PIDF with a provided-by that had > the URI in it. That would be the (single) access provider who > provided the PIDF. >> >> How do I get two access providers and how does one PIDF have data >> from both of them? >> >> Brian >> >> On Jun 3, 2013, at 4:53 PM, "Winterbottom, James" >> wrote: >> >>> No, I have two companies that provide that access service. >>> In this case I want a single URI that return two provider data blobs. >>> >>> Cheers >>> James >>> >>> ----- Original Message ----- >>> From: Brian Rosen [mailto:br@brianrosen.net] >>> Sent: Monday, June 03, 2013 10:00 PM >>> To: Winterbottom, James >>> Cc: Hannes Tschofenig ; Randall Gellens >>> ; Brian Rosen ; >>> ecrit@ietf.org >>> Subject: Re: [Ecrit] Additional Data: Transport Related Question > >> >>> That would mean we would need the Additional Data by Reference to >>> be a web service where you could list all the mime types and get >>> them all in one operation. >>> >>> The current situation is that you get a URI for each block with a >>> parameter that tells you what type it is, and you fetch them one by >>> one. >>> >>> Brian >>> >>> On Jun 2, 2013, at 11:32 PM, "Winterbottom, James" >>> wrote: >>> >>>> Hi Hannes, >>>> >>>> I think I would change the last sentence of the proposed new 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 structure types." >>>> >>>> This allows multiple structures of the same type to be fetched at >>>> the same time. > >>> For example a NENA LIF could return multiple > emergencyCall.ProviderInfo structures depending on what is > provisioned. >>>> >>>> Cheers >>>> James >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Saturday, 1 June 2013 12:47 AM >>>> To: Randall Gellens >>>> Cc: Hannes Tschofenig; Winterbottom, James; Brian Rosen; >>>> ecrit@ietf.org >>>> Subject: Re: [Ecrit] Additional Data: Transport Related Question >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA512 >>>> >>>> Thanks for the feedback. >>>> >>>> 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: >>>> >>>> " >>>> 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. >>>> >>>> Ciao >>>> Hannes >>>> >>>> On May 31, 2013, at 3:28 AM, Randall Gellens wrote: >>>> >>>>> 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 >>>>>> 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+xm= l' >>>>>> 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=3Dutf-8 >>>>>> Content-Length: tbd >>>>>> >>>>>> >>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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 o= nly >>>>> -------------- 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----- >>> >> -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It is bad luck to be = superstitious. From randy@qti.qualcomm.com Tue Jun 4 00:53: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 521F421F9A6D for ; Tue, 4 Jun 2013 00:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 cJuGdcPRyQfb for ; Tue, 4 Jun 2013 00:52:53 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEBD21F9A8A for ; Mon, 3 Jun 2013 23:58:50 -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=1370329130; x=1401865130; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=wujSXMfdPEPYI8JxprHQG5/DTG096W4BjIresbwDnbI=; b=KBeTWQ9udxmJBEEiwCZ12ED632YErpan6R20aD7l71QIRk7xTW1jGA1h sdce9PG15XP0KELRRyYpJadaHMeTB/vALGwbmw4S6g9NeCQVV8Vmd2RKY Pderenn4NrLshtYRiCUqC1VJX9nyzdEC6700FmK8x7jv/5XtQfnf7BChf k=; X-IronPort-AV: E=Sophos;i="4.87,798,1363158000"; d="scan'208";a="53399286" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 03 Jun 2013 23:58:47 -0700 X-IronPort-AV: E=Sophos;i="4.87,798,1363158000"; d="scan'208";a="458849314" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jun 2013 23:58:47 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 3 Jun 2013 23:58:46 -0700 Message-ID: In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188012140A08E37@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880121407DA0F8@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC81880121409BB12D@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC81880121409BB131@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188012140A08E37@SISPE7MB1.commscope.com> X-Mailer: Eudora for Mac OS X Date: Mon, 3 Jun 2013 23:55:56 -0700 To: "Winterbottom, James" , Randall Gellens , Brian Rosen From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: Tue, 04 Jun 2013 07:53:15 -0000 Hi James, Thanks for the clarification, that was helpful. So, if I understand your case, the ISP is happy to provide Data Provider Info for both itself and the access network. This saves the access network from the trouble of adding a item to the PIDF-LO, but introduces your concern regarding the emergency services agency determining which URI it wishes to access and knowing which is for which provider. Is this case different from the more general case where multiple Data Provider Info blocks are provided? Either way, assuming each block is referenced by its own URI, the the emergency services agency is confronted with multiple URIs for Data Provider Info blocks. I'm not sure if the order in which the URIs appear is significant, or if the emergency services agency cares. It seems to me that in both your specific example and in the general case, the emergency services agency determines in advance if they are interested in Data Provider Info blocks, and assuming they are, fetches all available. Inside each block, the Type of Data Provider indicates if the block is for an access network provider, an ISP, or what. So, I'm not sure what benefit there is in your specific example of having the ISP return both its Data Provider Info block and that of the access network via a single URI -- either way the emergency services agency needs to look inside the blocks to see which is which, and either way the emergency services agency accesses both blocks. At 11:05 AM +0800 6/4/13, James Winterbottom wrote: > Hi Randy, > > Some of what you are suggesting are is right, some seemed to diverge. > See inline. > > > > -----Original Message----- > From: Randall Gellens [mailto:randy@qti.qualcomm.com] > Sent: Tuesday, 4 June 2013 10:33 AM > To: Winterbottom, James; Brian Rosen > Cc: 'hannes.tschofenig@gmx.net'; 'randy@qti.qualcomm.com'; 'ecrit@ietf.org' > Subject: RE: [Ecrit] Additional Data: Transport Related Question > > Hi James, > > Let me see if I understand your case: > > The ISP knows the underlying access provider and has a > business relationship with it (one example I'm guessing would be > your National Broadband Network). The ISP is happy to supply > Provider Info blocks for itself and the underlying NBN. > [AJW] Yes, this right. > > In this case, there are multiple possible ways to make the Provider > Info blocks available. E.g., > - The ISP adds two Provider Info URIs: its own and another > for the NBN > [AJW] This is "sort of" the case I am discussing. If the > ISP adds two URIs then there is no way for the PSAP to look at the > URI and say "AH!! I want this one", it has to deference both and > then look at the various elements in the responses to work out > which order to interpret them in. I am proposing that the ISP > supply one Data Provider URI. Accessing this URI will only return > Data Provider elements, but it may return more than one Data > Provider element if the ISP is providing information for more than > just itself. Under the current scheme this is legal. > > or > - The ISP adds one URI for its own Provider Info and > - The NBN uses the provided-by element in a PIDF-LO to > supply a URI for its info > [AJW] No, not this case. > > But you seem to be discussing a case where multiple entities need > to use the provided-by element of a PIDF-LO. Is that right? If > so, the problem is that the PIDF-LO schema restricts > to zero or one occurrence, prohibiting the use of two > elements. > [AJW] This is not what I am suggesting at all. > > > > > At 7:29 AM +0800 6/4/13, James Winterbottom wrote: > >> I don't think that they can decide it for themselves easily Brian. >> There is not enough granularity in the current ref Uri definitions to >> provide the degree of visibility that you describe here, so at present > > it seems to me that either we allow multiple blocks of the same type >> to be returned from the same fetch or the information ins't provided >> to the PSAP at all. >> >> Cheers >> James >> >> >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Tuesday, 4 June 2013 9:13 AM >> To: Winterbottom, James >> Cc: Brian Rosen; 'hannes.tschofenig@gmx.net'; >> 'randy@qti.qualcomm.com'; 'ecrit@ietf.org' >> Subject: Re: [Ecrit] Additional Data: Transport Related Question >> >> The stated reason for having separate blocks is to allow PSAPs to >> control what they download. This is going in the other direction. >> It also begs the question of who hosts the blocks for the other >> providers, but they could decide that themselves. >> >> Brian >> >> On Jun 3, 2013, at 6:39 PM, "Winterbottom, James" >> wrote: >> >>> Brian, >>> >>> I can have up to 3 different organizations coming together to >>> provide a domestic broadband service in many countries. In my case, >>> my ISP knows who my layers 2 and physical access providers are. They >>> could easily therefore have three provider data blobs one for them >>> and one for each of the others. In this case I want to only provide a >>> single URI and get back all three data provider blobs. This would be > >> valid using the MIME in the HTTP header anyway. All I am asking for >>> is for the text to say so. >>> >>> Cheers >>> James >>> >>> -----Original Message----- >>> From: Brian Rosen [mailto:br@brianrosen.net] >>> Sent: Tuesday, 4 June 2013 6:58 AM >>> To: Winterbottom, James >>> Cc: 'br@brianrosen.net'; 'hannes.tschofenig@gmx.net'; >>> 'randy@qti.qualcomm.com'; 'ecrit@ietf.org' >>> Subject: Re: [Ecrit] Additional Data: Transport Related Question >>> >>> Sorry, I don't understand this case. >>> >> > An access network would provide a PIDF with a provided-by that had >> the URI in it. That would be the (single) access provider who >> provided the PIDF. >>> >>> How do I get two access providers and how does one PIDF have data >>> from both of them? >>> >>> Brian >>> >>> On Jun 3, 2013, at 4:53 PM, "Winterbottom, James" >>> wrote: >>> >>>> No, I have two companies that provide that access service. >>>> In this case I want a single URI that return two provider data blobs. >>>> >>>> Cheers >>>> James >>>> >>>> ----- Original Message ----- >>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>> Sent: Monday, June 03, 2013 10:00 PM >>>> To: Winterbottom, James >>>> Cc: Hannes Tschofenig ; Randall Gellens >>>> ; Brian Rosen ; >>>> ecrit@ietf.org >>>> Subject: Re: [Ecrit] Additional Data: Transport Related Question >> >> >>>> That would mean we would need the Additional Data by Reference to >>>> be a web service where you could list all the mime types and get >>>> them all in one operation. >>>> >>>> The current situation is that you get a URI for each block with a >>>> parameter that tells you what type it is, and you fetch them one by >>>> one. >>>> >>>> Brian >>>> >>>> On Jun 2, 2013, at 11:32 PM, "Winterbottom, James" >>>> wrote: >>>> >>>>> Hi Hannes, >>>>> >>>>> I think I would change the last sentence of the proposed new 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 structure types." >>>>> >>>>> This allows multiple structures of the same type to be fetched at >>>>> the same time. >> >>> For example a NENA LIF could return multiple >> emergencyCall.ProviderInfo structures depending on what is >> provisioned. >>>>> >>>>> Cheers >>>>> James >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Saturday, 1 June 2013 12:47 AM >>>>> To: Randall Gellens >>>>> Cc: Hannes Tschofenig; Winterbottom, James; Brian Rosen; >>>>> ecrit@ietf.org >>>>> Subject: Re: [Ecrit] Additional Data: Transport Related Question >>>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA512 > >>>> >>>>> Thanks for the feedback. >>>>> >>>>> 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: >>>>> >>>>> " >>>>> 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. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> On May 31, 2013, at 3:28 AM, Randall Gellens wrote: >>>>> >>>>>> 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 >>>>>>> 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 >>>>>>> >>>>>>> >>>>>> xmlns:ad="urn:ietf:params:xml:ns:emergencyCall.SubInfo" >>>>>>> xmlns:xsi="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=102 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> -----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= >>>>> =05bX >>>>> -----END PGP SIGNATURE----- >>>> >>> > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- It is bad > luck to be superstitious. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Language is a virus from outer space. --William S. Burroughs From James.Winterbottom@commscope.com Tue Jun 4 16:41: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 2E58621F8F41 for ; Tue, 4 Jun 2013 16:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 N-3gBJIU+zo8 for ; Tue, 4 Jun 2013 16:40:59 -0700 (PDT) Received: from cdcsmgw02.commscope.com (cdcsmgw02.commscope.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id 57C3721F8F2C for ; Tue, 4 Jun 2013 16:40:52 -0700 (PDT) X-AuditID: 0a0404e9-b7fa16d000005100-bc-51ae7b025b2f Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id 6E.2A.20736.20B7EA15; Tue, 4 Jun 2013 18:40:51 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 4 Jun 2013 18:40:50 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 5 Jun 2013 07:40:47 +0800 From: "Winterbottom, James" To: Randall Gellens , Brian Rosen Date: Wed, 5 Jun 2013 07:40:45 +0800 Thread-Topic: [Ecrit] Additional Data: Transport Related Question Thread-Index: Ac5g8PjOP+LFsJYFT0Wm4fcGRX67IAAiG5VQ Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140A08F0B@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880121407DA0F8@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC81880121409BB12D@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC81880121409BB131@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188012140A08E37@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+NgFnrEKsWRmVeSWpSXmKPExsXCFSYjqstcvS7Q4NEcPoun96exWTQuespq sXTnPVaLa486mB1YPO5/+8vusXjTfjaPJUt+MnksmvqMMYAlissmJTUnsyy1SN8ugStj6dMl TAVH1zJWTJ65lqWBcV0DYxcjJ4eEgInE0hXHWCBsMYkL99azdTFycQgJ7GKU+HX1HJSznlFi xbKr7BDOWkaJ3esWsYO0sAnYSRxef4MZxBYR8JXY+gZiLLNAisSXTRuZQGwWARWJPRuPg9UI CzhILP/8mR2i3lHi2c9vULaRxJfWP2D1vAJBEovv3mWEWPaRWeLo6eNg93EC3Xr74RswmxHo 1u+n1jBBLBOXuPVkPhPEDwISS/acZ4awRSVePv7HClEvKnGnfT3UcToSC3Z/YoOwtSWWLXzN DLFYUOLkzCdg84UEdCWadn5lncAoMQvJillI2mchaZ+FpH0BI8sqRvHklOTi3PRyAyO95Pzc 3OLk/IJUEGsTIyhKWVhe7mA8u0H7EKMAB6MSD++DT2sDhVgTy4orcw8xSnIwKYnyHipfFyjE l5SfUpmRWJwRX1Sak1p8iFGCg1lJhDc0ASjHm5JYWZValA+T0uDgEDj95P4pRimWvPy8VCUJ 3l2VQGWCRanpqRVpmTnAFAVTysTBCTKKB2iUYRXIqOKCxNzizHSI/ClGbY7N5ye/Y+S4eHjq O0YhsHFS4ryzQcYJgJRmlObBTXvFKA70gjDvDJAsDzDhws15BbSCCWjF5NerQFaUJCKkpBoY J/39efHkbF3DUo5LtXvthBJKXzFb+Iq9rJZr6pPclXvust6klK0lD7sesv1KXJq25kBtl0oc Zxhz1hxTyfm3P+6auXtjQZzM5EmXrEQ3RBdqTz+oacHcx1E39f8lVlWXgP1x1+fEFOvnCi4O rXD4IMqXoHIjvueRukjLgo0+WtpN4iw30pWVWIozEg21mIuKEwHJxUvbdQMAAA== 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, 04 Jun 2013 23:41:03 -0000 Hi Randy, The main advantage is a single request and this indicates that the data is = coming from a single point. However, as I have said before, the mechanism w= e are using doesn't prohibit multiple blobs of the expected type being retu= rned from a single request. It seems ridiculous to me to : a) Introduce a completely artificial constraint that serves no purpose othe= r than to force two fetch operations b) have the same entity produce two different URIs that the PSAP cannot dis= tinguish between for two blobs of the same kind of data that are both requi= red to define the service. Cheers James -----Original Message----- From: Randall Gellens [mailto:randy@qti.qualcomm.com] Sent: Tuesday, 4 June 2013 4:56 PM To: Winterbottom, James; Randall Gellens; Brian Rosen Cc: 'hannes.tschofenig@gmx.net'; 'ecrit@ietf.org' Subject: RE: [Ecrit] Additional Data: Transport Related Question Hi James, Thanks for the clarification, that was helpful. So, if I understand your c= ase, the ISP is happy to provide Data Provider Info for both itself and the= access network. This saves the access network from the trouble of adding = a item to the PIDF-LO, but introduces your concern regarding = the emergency services agency determining which URI it wishes to access and= knowing which is for which provider. Is this case different from the more general case where multiple Data Provi= der Info blocks are provided? Either way, assuming each block is reference= d by its own URI, the the emergency services agency is confronted with mult= iple URIs for Data Provider Info blocks. I'm not sure if the order in whic= h the URIs appear is significant, or if the emergency services agency cares= . It seems to me that in both your specific example and in the general case, = the emergency services agency determines in advance if they are interested = in Data Provider Info blocks, and assuming they are, fetches all available.= Inside each block, the Type of Data Provider indicates if the block is fo= r an access network provider, an ISP, or what. So, I'm not sure what benefit there is in your specific example of having t= he ISP return both its Data Provider Info block and that of the access netw= ork via a single URI -- either way the emergency services agency needs to l= ook inside the blocks to see which is which, and either way the emergency s= ervices agency accesses both blocks. At 11:05 AM +0800 6/4/13, James Winterbottom wrote: > Hi Randy, > > Some of what you are suggesting are is right, some seemed to diverge. > See inline. > > > > -----Original Message----- > From: Randall Gellens [mailto:randy@qti.qualcomm.com] > Sent: Tuesday, 4 June 2013 10:33 AM > To: Winterbottom, James; Brian Rosen > Cc: 'hannes.tschofenig@gmx.net'; 'randy@qti.qualcomm.com'; 'ecrit@ietf.o= rg' > Subject: RE: [Ecrit] Additional Data: Transport Related Question > > Hi James, > > Let me see if I understand your case: > > The ISP knows the underlying access provider and has a > business relationship with it (one example I'm guessing would be your > National Broadband Network). The ISP is happy to supply Provider Info > blocks for itself and the underlying NBN. > [AJW] Yes, this right. > > In this case, there are multiple possible ways to make the Provider > Info blocks available. E.g., > - The ISP adds two Provider Info URIs: its own and another > for the NBN > [AJW] This is "sort of" the case I am discussing. If the ISP > adds two URIs then there is no way for the PSAP to look at the URI and > say "AH!! I want this one", it has to deference both and then look at > the various elements in the responses to work out which order to > interpret them in. I am proposing that the ISP supply one Data > Provider URI. Accessing this URI will only return Data Provider > elements, but it may return more than one Data Provider element if the > ISP is providing information for more than just itself. Under the > current scheme this is legal. > > or > - The ISP adds one URI for its own Provider Info and > - The NBN uses the provided-by element in a PIDF-LO to supply > a URI for its info > [AJW] No, not this case. > > But you seem to be discussing a case where multiple entities need to > use the provided-by element of a PIDF-LO. Is that right? If so, the > problem is that the PIDF-LO schema restricts to zero or > one occurrence, prohibiting the use of two elements. > [AJW] This is not what I am suggesting at all. > > > > > At 7:29 AM +0800 6/4/13, James Winterbottom wrote: > >> I don't think that they can decide it for themselves easily Brian. >> There is not enough granularity in the current ref Uri definitions >> to provide the degree of visibility that you describe here, so at >> present > > it seems to me that either we allow multiple blocks of the same > type >> to be returned from the same fetch or the information ins't provided >> to the PSAP at all. >> >> Cheers >> James >> >> >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Tuesday, 4 June 2013 9:13 AM >> To: Winterbottom, James >> Cc: Brian Rosen; 'hannes.tschofenig@gmx.net'; >> 'randy@qti.qualcomm.com'; 'ecrit@ietf.org' >> Subject: Re: [Ecrit] Additional Data: Transport Related Question >> >> The stated reason for having separate blocks is to allow PSAPs to >> control what they download. This is going in the other direction. >> It also begs the question of who hosts the blocks for the other >> providers, but they could decide that themselves. >> >> Brian >> >> On Jun 3, 2013, at 6:39 PM, "Winterbottom, James" >> wrote: >> >>> Brian, >>> >>> I can have up to 3 different organizations coming together to >>> provide a domestic broadband service in many countries. In my case, >>> my ISP knows who my layers 2 and physical access providers are. They >>> could easily therefore have three provider data blobs one for them >>> and one for each of the others. In this case I want to only provide >>> a single URI and get back all three data provider blobs. This would >>> be > >> valid using the MIME in the HTTP header anyway. All I am asking > for >>> is for the text to say so. >>> >>> Cheers >>> James >>> >>> -----Original Message----- >>> From: Brian Rosen [mailto:br@brianrosen.net] >>> Sent: Tuesday, 4 June 2013 6:58 AM >>> To: Winterbottom, James >>> Cc: 'br@brianrosen.net'; 'hannes.tschofenig@gmx.net'; >>> 'randy@qti.qualcomm.com'; 'ecrit@ietf.org' >>> Subject: Re: [Ecrit] Additional Data: Transport Related Question >>> >>> Sorry, I don't understand this case. >>> >> > An access network would provide a PIDF with a provided-by that >> had the URI in it. That would be the (single) access provider who >> provided the PIDF. >>> >>> How do I get two access providers and how does one PIDF have data >>> from both of them? >>> >>> Brian >>> >>> On Jun 3, 2013, at 4:53 PM, "Winterbottom, James" >>> wrote: >>> >>>> No, I have two companies that provide that access service. >>>> In this case I want a single URI that return two provider data blobs= . >>>> >>>> Cheers >>>> James >>>> >>>> ----- Original Message ----- >>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>> Sent: Monday, June 03, 2013 10:00 PM >>>> To: Winterbottom, James >>>> Cc: Hannes Tschofenig ; Randall >>>> Gellens ; Brian Rosen ; >>>> ecrit@ietf.org >>>> Subject: Re: [Ecrit] Additional Data: Transport Related Question >> >> >>>> That would mean we would need the Additional Data by Reference to >>>> be a web service where you could list all the mime types and get >>>> them all in one operation. >>>> >>>> The current situation is that you get a URI for each block with a >>>> parameter that tells you what type it is, and you fetch them one by >>>> one. >>>> >>>> Brian >>>> >>>> On Jun 2, 2013, at 11:32 PM, "Winterbottom, James" >>>> wrote: >>>> >>>>> Hi Hannes, >>>>> >>>>> I think I would change the last sentence of the proposed new text t= o: >>>>> "For transport in SIP or HTTP, the additional data is >>>>> defined as a series of MIME objects, one for each of the >>>>> data structure types." >>>>> >>>>> This allows multiple structures of the same type to be fetched >>>>> at the same time. >> >>> For example a NENA LIF could return multiple >> emergencyCall.ProviderInfo structures depending on what is >> provisioned. >>>>> >>>>> Cheers >>>>> James >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Saturday, 1 June 2013 12:47 AM >>>>> To: Randall Gellens >>>>> Cc: Hannes Tschofenig; Winterbottom, James; Brian Rosen; >>>>> ecrit@ietf.org >>>>> Subject: Re: [Ecrit] Additional Data: Transport Related Question >>>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA512 > >>>> >>>>> Thanks for the feedback. >>>>> >>>>> 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: >>>>> >>>>> " >>>>> 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. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> On May 31, 2013, at 3:28 AM, Randall Gellens wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> James' response matches my understanding: there is no wrapping >>>>>> or encapsulation; the MIME type is used to identify the type of dat= a. >>>>>> 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 >>>>>>> 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), eac= h >>>>>>> HTTPS URL references one block; the data is retrieved with a= n >>>>>>> HTTP GET operation, which returns one of the blocks as an XM= L >>>>>>> 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=3Dutf-8 >>>>>>> Content-Length: tbd >>>>>>> >>>>>>> >>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 >>>>> >>>>> -----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----- >>>> >>> > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- It is bad luck > to be superstitious. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Language is a virus f= rom outer space. --William S. Burroughs From internet-drafts@ietf.org Thu Jun 20 15:16:18 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 0E10121F9971; Thu, 20 Jun 2013 15:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, 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 CaskZje72RX2; Thu, 20 Jun 2013 15:16:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A457721F991E; Thu, 20 Jun 2013 15:16:17 -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.51.p2 Message-ID: <20130620221617.32304.93107.idtracker@ietfa.amsl.com> Date: Thu, 20 Jun 2013 15:16:17 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-service-urn-policy-02.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: Thu, 20 Jun 2013 22:16:18 -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 : Policy for defining new service-identifying lables Author(s) : Andrea G. Forte Henning Schulzrinne Filename : draft-ietf-ecrit-service-urn-policy-02.txt Pages : 5 Date : 2013-06-20 Abstract: In order to provide location-based services, descriptive terms for services need to be defined. This document updates the policy for defining new service-identifying labels. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-service-urn-policy There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-service-urn-policy-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-service-urn-policy-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pkyzivat@alum.mit.edu Thu Jun 20 16:01: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 18D9421F919D for ; Thu, 20 Jun 2013 16:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[AWL=0.107, 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 7x8JM5hD7y-5 for ; Thu, 20 Jun 2013 16:01:09 -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 269BB21F8C4C for ; Thu, 20 Jun 2013 16:01:09 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta14.westchester.pa.mail.comcast.net with comcast id qb6z1l0011HzFnQ5En1821; Thu, 20 Jun 2013 23:01:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id qn181l00S3ZTu2S3an188H; Thu, 20 Jun 2013 23:01:08 +0000 Message-ID: <51C389B3.2040002@alum.mit.edu> Date: Thu, 20 Jun 2013 19:01:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: ecrit@ietf.org References: <20130620221617.32304.93107.idtracker@ietfa.amsl.com> In-Reply-To: <20130620221617.32304.93107.idtracker@ietfa.amsl.com> 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=1371769268; bh=R2dHDK9vvMKouct/FIfU5WlDZIMulRMsDcM+1el5U4U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=e1I7ksLhnKqEoLjt15LvOvN99ZgUZ9+b+XPQTwJoVCEonqbd2IGFc3dcdbdwqbc2H 23khCEZwa0Hv1aS9aJpl/2hXdE0VgUk/4zlcacHrzvED2N0TPNIaiTJ52Pp46N9egU l402eRh0ZyEwvDQhdQdX0HSR3Irl9goz4V/E5qRJOVjU+fv6IPgQUfyg6kS/P6zK7Y m/u4IBQ5dr+VHTm6uUB4XmF3HwAZZXKK6bgrl9gCLgk7sPdw8HdyZ/qjopIETsMJHP v526RO/JNJIfHWYTkH0mSVfSlXMJc3qRvE7Agakjg89wIY+nm6DwkkUpV67V6532To JAiLKG6CR9Qow== Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-service-urn-policy-02.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: Thu, 20 Jun 2013 23:01:14 -0000 I haven't gotten any further, but I suggest it would be good to correct the spelling in the title of the document. :-) Thanks, Paul On 6/20/13 6:16 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. > > Title : Policy for defining new service-identifying lables > Author(s) : Andrea G. Forte > Henning Schulzrinne > Filename : draft-ietf-ecrit-service-urn-policy-02.txt > Pages : 5 > Date : 2013-06-20 > > Abstract: > In order to provide location-based services, descriptive terms for > services need to be defined. This document updates the policy for > defining new service-identifying labels. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-service-urn-policy > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ecrit-service-urn-policy-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-service-urn-policy-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From James.Winterbottom@commscope.com Thu Jun 20 23:13:17 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 480A521F9A6A for ; Thu, 20 Jun 2013 23:13:17 -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 cjB4NZrZttOL for ; Thu, 20 Jun 2013 23:13:12 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id D02F611E80FC for ; Thu, 20 Jun 2013 23:13:11 -0700 (PDT) X-AuditID: 0a0404e8-b7ff56d00000081e-9d-51c3eee68900 Received: from CDCE10HC2.commscope.com ( [10.86.28.22]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id 7B.CE.02078.6EEE3C15; Fri, 21 Jun 2013 01:12:54 -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; Fri, 21 Jun 2013 01:12:54 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 21 Jun 2013 14:12:51 +0800 From: "Winterbottom, James" To: "Winterbottom, James" , "ecrit@ietf.org" Date: Fri, 21 Jun 2013 14:12:50 +0800 Thread-Topic: Additional Data -09 Data Provider Schema Thread-Index: Ac5gDMjEtg/AYbuTS0CalOYQQtCS2wOOWghw Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140A09D38@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_5A55A45AE77F5941B18E5457ECAC8188012140A09D38SISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA11TWUwTURT1dWMofTqdlvY5ItERoxEVcCFuIUZ/1C+rRqNEYWjHdrRbOlTF FcGI4IdLjIkkrsFdAfkwbjFYVGjBjR8NKhi2gICKkaiJIc6baXHw77xz7rvn3DtvCDV1Lp4m eG8+F/Cybkan1+jXJ1lmdX+ps6U/DacuOHipS7sUrKio+K1aDTbplzg4N7+DC6Rl5epd79uz /ZXTdrX33okrBMNMGYgnEDkP/Qm3qGRsQa9bq3RlQE9Q5AOABiL1cfKhGqDw9yEgHyoBuhwq la7oyCxUV/VOjbGZZFHtiz4Ja8ip6MezbxqMTeR81PzwB5BrMlF/Q0Qr4zlo+GVYqoHkGtT4 pljqCcQYPyO3JKwmrail83w0HokqHr1SyzgR9XYMa+X6RPShpArI9T5U+e5KnNzTiMJnOqX+ FDkLFd0f0h4H5nJF23LFlXLFFZmfiS48/K6TcSq6crFPHcNNtR0qJX8BxN0AVrvDLnicO9Mz Ztt9Ho9g9/k5jGoA/kgaTc890FidGgIkARgDXFVcZ6O07A6hwBMC2wkVkwjTxG9Ijc3zOQpc rODKCQTdnMCYYcOASMMROi/o3s7QcCVmTSOsl9spuLl88VUwydC58YmNso5oQlDw83beFxRy ggF3CCBCLbZd+wG3dbAFu7mATzYLgWJAEGRjZ1sE0Bqvz8sxCNZhI2OAc3K7tvJu0SAazAoP dIkKqVSkbBPhk5miYFEKiniTIbgVslG0Uv4/oYqIDwEnYRBjJuOlQMHPegTeGbU2waM4lCHG Srbj4X5MUjFSYTkRXsQbscSk0XYRsI8oenH3K6CkkWkrrMeNSFztCnpHJqYtMH5MrY0apxCw M50EXbh9ooL/Z05Pgh6sjleoo/0/A7v4IkxQjyc1iH/2v0EpiD6KZEKUlOZE8pzGKKcYMwne lnJElf9dnOIjM8NHN0N4n/lsvnKf9Zg1xNjoPp9ikoqRo/b5HEuWmDTaiS4EG9q6c9nBa+sG h/xTmra0X/1VdvnE3vWZx04zpaWDp8zdRya0plrSjvE9Z2sOe2ChfUx9P6EzXHcYuG/2rD2O Q4uy973JATWLz/a+XVDU8Gpuhm5zy/GO5Tyf3Pxp6Itmzfllz0pOMtvSuZQUXUl64cLczBLT dGPR4w0PEpoTjAU0oxFcbMYMdUBg/wL28Dq2MQUAAA== Subject: Re: [Ecrit] Additional Data -09 Data Provider Schema 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, 21 Jun 2013 06:13:17 -0000 --_000_5A55A45AE77F5941B18E5457ECAC8188012140A09D38SISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hannes, Did you respond to this? If you did I apologize as I don't seem to have the response. If not, could you confirm that these are a problem and are in the pipeline = to be fixed please? Cheers James From: Winterbottom, James Sent: Monday, 3 June 2013 1:45 PM To: ecrit@ietf.org Subject: Additional Data -09 Data Provider Schema Hi Hannes, The Data Provider Information sections in the document are covered in secti= on 3.1. Section 3.1.8 "Subcontractor Principal" and Section 3.1.9 "Subcontractor Pr= iority" seem to be missing from the element sequence defined in the emergen= cyCall.ProviderInfo schema defined in section 6.1. Cheers James --_000_5A55A45AE77F5941B18E5457ECAC8188012140A09D38SISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hannes,

 

Did you respond to this?

If you did I apologize as I= don’t seem to have the response.

If not, could you confirm that these a= re a problem and are in the pipeline to be fixed please?<= /p>

 

Cheers=

James

 = ;

&= nbsp;

From: Winterbottom, = James
Sent: Monday, 3 June 2013 1:45 PM
To: ecrit@ietf= .org
Subject: Additional Data -09 Data Provider Schema=

 

Hi Hannes,

 

The Data Provider Information sections in the doc= ument are covered in section 3.1.

Sectio= n 3.1.8 “Subcontractor Principal” and Section 3.1.9 “Subc= ontractor Priority” seem to be missing from the element sequence defi= ned in the emergencyCall.ProviderInfo schema defined in section 6.1.

 

Chee= rs

James

 

= --_000_5A55A45AE77F5941B18E5457ECAC8188012140A09D38SISPE7MB1co_-- From ivo.sedlacek@ericsson.com Tue Jun 25 23:26:38 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 B44C621E80DD for ; Tue, 25 Jun 2013 23:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Ym8dFwoBH13Y for ; Tue, 25 Jun 2013 23:26:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id AF8EA21F9BAE for ; Tue, 25 Jun 2013 23:26:27 -0700 (PDT) X-AuditID: c1b4fb30-b7fab6d00000040c-5d-51ca89926940 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 55.56.01036.2998AC15; Wed, 26 Jun 2013 08:26:26 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.30]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 08:26:25 +0200 From: Ivo Sedlacek To: "ecrit@ietf.org" Thread-Topic: Question to draft-ietf-ecrit-data-only-ea-05 Thread-Index: Ac5yNO0/BT+1Wf3oSGOSPbvRWIDIag== Date: Wed, 26 Jun 2013 06:26:25 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010EF4FC@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+Jvre6kzlOBBtMWSVk0LnrK6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGnXN7AUXBKv2NJ/hr2BsVm4i5GTQ0LAROLL2ZvMELaYxIV7 69m6GLk4hAQOM0qcWjWTBcJZzCjxYW8LO0gVm4CexMQtR1hBbBEBVYkNZ1YygtjCAqYSPw5t Z4eIW0m8bVjNBGHrSWy62wMWZwGqn/ZgExuIzSvgLfH65GWwOYwCshJX//SCzWEWEJe49WQ+ E8RFAhJL9pyHuk5U4uXjf6wQtqLEx1f7oOr1JG5MncIGYWtLLFv4mhlivqDEyZlPWCYwCs9C MnYWkpZZSFpmIWlZwMiyipE9NzEzJ73cfBMjMJAPbvltsINx032xQ4zSHCxK4ryfTu0KFBJI TyxJzU5NLUgtii8qzUktPsTIxMEp1cBYptBpvzPefu8+xRl3f7I1y83bJfx2F0/znHOtxxK8 FihwKTc8PLt6wuxsVcZ9U01+iFyaHzejYHtz5fQtH04ILEjd1m90WY2HXSmi/9frCu4iickf U+5PPcMhG54x4X8UwyOZtTPORmdcZvd7kSq3YPur886yl16wTezNKvof8+yWz55+jb83lFiK MxINtZiLihMBHCGKDzICAAA= Subject: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 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, 26 Jun 2013 06:26:38 -0000 Hello, draft-ietf-ecrit-data-only-ea-05 states: =A0=A0 This document does not define a mechanism for updates to the data =A0=A0 contained in data-only emergency calls. Is there another I-D describing how to provide the updates of the data to t= he PSAP? I saw some post suggesting that a SUBSCRIBE/NOTIFY mechanism could= be used where the PSAP is subscriber and the UA is notifier, however I hav= e not found such draft. Issue 1: If SUBSCRIBE/NOTIFY mechanism is used, the PSAP is the subscriber = and the UA is the notifier, this would require reachability of UA for initi= al request for dialog (i.e. SUBSCRIBE). However, when the UA is not registe= red e.g. due to missing credentials, the UA is normally not reachable for S= IP requests other than those sent within the dialog of the emergency call. Issue 2: How to send the update of the data __triggered by the UA__? Do we = assume that if the PSAP subscription is not available, the PSAP prevents th= e UE from sending further information? =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 If so, assuming PSAP is interested in any= information available, PSAP will need to subscribe in every single case of= MESSAGE with CAP where UA can potentially provide the update of the data. =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 If not, do we assume that the UE would se= nd updates of data triggered by UE using other mechanism (MESSAGE?) than up= dates of data requested by PSAP (NOTIFY)? Issue 3: In some architectures (like 3GPP), signalling path for inital requ= est for dialog from the PSAP to the UA is different than signalling path fo= r the emergency request from the UA to the PSAP. If the UA has subscription= from network in country X and roams in country Y, there is likelyhood that= information that request comes from the PSAP is lost due to missing trust = among PSAP (in country Y), transit networks (in country Y and X and possibl= y other transit countries), network of registrar and proxy of the UA (in co= untry X), transit networks (in country X and Y and possibly other transit c= ountries) and network of edge proxy serving the UA (in country Y) . If so, = the UA would then handle the inital request for dialog as coming from an at= tacker UE and possibly reject it. Is draft-ietf-ecrit-data-only-ea-05 supposed to be a base for future solut= ion where updates of the data to the PSAP are sent? I do not think it would= work due to issues above. If the UA ever wants to provide the updates of the data to the PSAP, either= triggred by the UA or requested by the PSAP, it would be better to establi= sh a dialog from beginning, e.g. send the initial data in INVITE and update= s (from UE) and requests for updates (from PSAP) in INFOs. Kind regards Ivo Sedlacek=20 Ericsson Mobile +420 608 234 709 ivo.sedlacek@ericsson.com www.ericsson.com=20 This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 From mlinsner@cisco.com Wed Jun 26 05:44:23 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 A6F4121E810B for ; Wed, 26 Jun 2013 05:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 7-Rvqy1IsZmK for ; Wed, 26 Jun 2013 05:44:18 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 003FD11E81BB for ; Wed, 26 Jun 2013 05:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1795; q=dns/txt; s=iport; t=1372250629; x=1373460229; h=from:to:subject:date:message-id:mime-version; bh=jKI9ABBBtPrn0XeBtkqa/HZcA3zgfjOake8Fmkd2K4s=; b=TszQInpmQvLSDp14JCdOZOzRzN9fyqqmLYynejD6ItxrhgphszwLaSuQ 7py5FUIkI92m4yRrRgXBgaJVeG/TxRdYSPnffvkQ85RhUIKGb5U7pIYBu +8feQV4HciJFo8eFRIbqbqUB4W/psLfxri/SMFwbfmdAIVV5dYYZ2r1O2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAOngylGtJV2Z/2dsb2JhbABagkVEer57gQMWdIIaCwEEgQsBCwEeVicEG4gGmgmRAI9OjxqDOmEDqQqDEYIo X-IronPort-AV: E=Sophos;i="4.87,944,1363132800"; d="scan'208,217";a="227636811" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 26 Jun 2013 12:43:48 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5QChmC4028558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Jun 2013 12:43:48 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.35]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 07:43:48 -0500 From: "Marc Linsner (mlinsner)" To: "ecrit@ietf.org" Thread-Topic: WGLC - draft-ietf-ecrit-country-emg-urn-00 Thread-Index: AQHOcmrN9klx/UwAsUmy7KvYedqNBQ== Date: Wed, 26 Jun 2013 12:43:47 +0000 Message-ID: <581E085DEB6A444093CDAEA4C4EE48181356EA58@xmb-rcd-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.195.118] Content-Type: multipart/alternative; boundary="_000_581E085DEB6A444093CDAEA4C4EE48181356EA58xmbrcdx08ciscoc_" MIME-Version: 1.0 Subject: [Ecrit] WGLC - draft-ietf-ecrit-country-emg-urn-00 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, 26 Jun 2013 12:44:23 -0000 --_000_581E085DEB6A444093CDAEA4C4EE48181356EA58xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the Orlando meeting there was consensus that this work move forward alon= g with some volunteers to tweak the text. Since we've seen no discussion o= r text being tweaked, we're wondering if such tweaking is still necessary? If you needed the impetus, how about: This is a notice that we are starting a WGLC on this draft. Please submit = comments to this list by COB on Thursday, July 11, 2013. Thanks, Marc & Roger --_000_581E085DEB6A444093CDAEA4C4EE48181356EA58xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <5047AE34EC14E74BAF0E9645262DC817@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
At the Orlando meeting there was consensus that this work move forward= along with some volunteers to tweak the text.  Since we've seen no di= scussion or text being tweaked, we're wondering if such tweaking is still n= ecessary?

If you needed the impetus, how about:

This is a notice that we are starting a WGLC on this draft.  Plea= se submit comments to this list by COB on Thursday, July 11, 2013.


Thanks,

Marc & Roger
--_000_581E085DEB6A444093CDAEA4C4EE48181356EA58xmbrcdx08ciscoc_-- From pkyzivat@alum.mit.edu Wed Jun 26 07:30: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 6AFCA21E8088 for ; Wed, 26 Jun 2013 07:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.087 X-Spam-Level: X-Spam-Status: No, score=-0.087 tagged_above=-999 required=5 tests=[AWL=0.350, 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 i-xuAQzlq7l6 for ; Wed, 26 Jun 2013 07:30:17 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 95EE421E8085 for ; Wed, 26 Jun 2013 07:30:16 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta13.westchester.pa.mail.comcast.net with comcast id t0Ar1l0051ZXKqc5D2WGei; Wed, 26 Jun 2013 14:30:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id t2WG1l0093ZTu2S3h2WGnX; Wed, 26 Jun 2013 14:30:16 +0000 Message-ID: <51CAFAF7.3030705@alum.mit.edu> Date: Wed, 26 Jun 2013 10:30:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: ecrit@ietf.org References: <581E085DEB6A444093CDAEA4C4EE48181356EA58@xmb-rcd-x08.cisco.com> In-Reply-To: <581E085DEB6A444093CDAEA4C4EE48181356EA58@xmb-rcd-x08.cisco.com> 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=1372257016; bh=9/RZjleVPZZQ9a6Hf/DTuTv8XmQjeS3xsffzNRMV8uE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dG4CUW6Hh7mBOrrPCpg06c+qbuaRiNg6wmG2BzryBlgrJuwFmyLQy84io8xsf0lSL NEsaH34M7c+dNRt54O8XdMQ10VTphUI04YAfC1JLRPr3GTMk0p3LC6R1UHvtMA6lcT oxIdQEwLUSzkyqbT/sB7b7dXlQRpuUQgT0D6VmhGzzn4RnHClCDTRNJsqr2rgVUKBU yhHpx5tM8m3GsTQ6jG3SYkUpvoWxmsWKsAS6z9gHpz+wkHs9GvP2OUJoGz/4cO4VAa Csu89VGPxL8UzoRaUFLorLyaAzmgkJpM4FUOWsfxScen03x5bzgxueagOPzhMGifVf 0+ybFgp6/haVA== Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-country-emg-urn-00 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, 26 Jun 2013 14:30:22 -0000 I support this draft, as is. Thanks, Paul On 6/26/13 8:43 AM, Marc Linsner (mlinsner) wrote: > At the Orlando meeting there was consensus that this work move forward > along with some volunteers to tweak the text. Since we've seen no > discussion or text being tweaked, we're wondering if such tweaking is > still necessary? > > If you needed the impetus, how about: > > This is a notice that we are starting a WGLC on this draft. Please > submit comments to this list by COB on Thursday, July 11, 2013. > > > Thanks, > > Marc & Roger > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From forte@att.com Thu Jun 27 09:24:07 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 6ACA921F996A for ; Thu, 27 Jun 2013 09:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 DbDf0GadkynF for ; Thu, 27 Jun 2013 09:23:56 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF1421F99A7 for ; Thu, 27 Jun 2013 09:23:48 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 4176cc15.0.5405205.00-085.15036143.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 27 Jun 2013 16:23:49 +0000 (UTC) X-MXL-Hash: 51cc671575967ef5-d74e713b037e9df06b1a9838c272ed092b7109bd Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5RGNmh6013025 for ; Thu, 27 Jun 2013 12:23:48 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5RGNkFC012999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Jun 2013 12:23:47 -0400 Received: from mlpi432.sfdc.sbc.com (mlpi432.sfdc.sbc.com [144.151.223.11]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for ; Thu, 27 Jun 2013 16:23:31 GMT Received: from sfdc.sbc.com (localhost [127.0.0.1]) by mlpi432.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5RGNVHn010158 for ; Thu, 27 Jun 2013 12:23:31 -0400 Received: from [151.109.27.216] (dn151-109-27-216.dhcpn.snet.sbc.com [151.109.27.216]) by mlpi432.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5RGNTsj010131 for ; Thu, 27 Jun 2013 12:23:29 -0400 User-Agent: Microsoft-MacOutlook/14.3.4.130416 Date: Thu, 27 Jun 2013 12:23:28 -0400 From: "Andrea G. Forte" To: ECRIT WG Message-ID: Thread-Topic: [OpenPOIs-users] The OGC seeks public input on charter for Point of Interest (POI) encoding standard Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=VapAyiV9 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=QbCPKhKimeEA:10 a=OpJi1_j3i6sA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=D18XjKaT] X-AnalysisOut: [uSYA:10 a=HHKR9qpYAAAA:8 a=lkgqKRNTd8zbxN_puIoA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=TBv-FvLNKxEA:10 a=h8q98ZcSvz4A:10 a=lE7OlQ_Qgr] X-AnalysisOut: [YA:10 a=lYt1auA75VYA:10 a=Pv8S4Sitjj0A:10] Subject: [Ecrit] FW: [OpenPOIs-users] The OGC seeks public input on charter for Point of Interest (POI) encoding standard 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, 27 Jun 2013 16:24:07 -0000 I thought this would be of interest to the WG. Regards, -- Andrea AT&T Labs, Security Research Center http://src.att.com/people/forte.html On 5/30/13 10:50 AM, "Raj Singh" wrote: >The OGC is picking up the W3C work to standardize a universal format for >expressing points of interest data. >http://www.opengeospatial.org/pressroom/pressreleases/1834 > >----- >Raj Singh >rsingh@opengeospatial.org >+1 (617) 642-9372 >The OGC: Making location count. >http://www.opengeospatial.org/ogc/organization/staff/rsingh > > From md3135@att.com Fri Jun 28 04:45: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 562CF21F9DD0 for ; Fri, 28 Jun 2013 04:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 oGjvbiZcZCCB for ; Fri, 28 Jun 2013 04:45:46 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 278B021F9D82 for ; Fri, 28 Jun 2013 04:45:46 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id a677dc15.2aaaeae2a940.5566850.00-577.15520084.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 28 Jun 2013 11:45:46 +0000 (UTC) X-MXL-Hash: 51cd776a7907f465-5109e215af3f05a58ca7fa2355178b44c9ed7e79 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 7677dc15.0.5566842.00-141.15520044.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 28 Jun 2013 11:45:45 +0000 (UTC) X-MXL-Hash: 51cd77696c4d3ad0-e2cbaea1e34b8dc9ba0ca01e5da56a5ecf96d410 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5SBjhZA016694; Fri, 28 Jun 2013 07:45:43 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5SBjUX3016390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 07:45:37 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 28 Jun 2013 11:45:15 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Fri, 28 Jun 2013 07:45:23 -0400 From: "DOLLY, MARTIN C" To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] WGLC - draft-ietf-ecrit-country-emg-urn-00 Thread-Index: AQHOcmrN9klx/UwAsUmy7KvYedqNBZlIUZGAgAKzXOA= Date: Fri, 28 Jun 2013 11:45:22 +0000 Message-ID: References: <581E085DEB6A444093CDAEA4C4EE48181356EA58@xmb-rcd-x08.cisco.com> <51CAFAF7.3030705@alum.mit.edu> In-Reply-To: <51CAFAF7.3030705@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.85.177] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=A9DbydqG c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=PDXGYiBh4g0A:10 a=Pgp7XbPXzRQA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=ehACj4t7WlIA:10 a=48vgC7mUAAAA:8 a=t2N6S8NA63xRIf] X-AnalysisOut: [7FeW0A:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-country-emg-urn-00 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, 28 Jun 2013 11:45:57 -0000 +1 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of P= aul Kyzivat Sent: Wednesday, June 26, 2013 10:30 AM To: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-country-emg-urn-00 I support this draft, as is. Thanks, Paul On 6/26/13 8:43 AM, Marc Linsner (mlinsner) wrote: > At the Orlando meeting there was consensus that this work move forward > along with some volunteers to tweak the text. Since we've seen no > discussion or text being tweaked, we're wondering if such tweaking is > still necessary? > > If you needed the impetus, how about: > > This is a notice that we are starting a WGLC on this draft. Please > submit comments to this list by COB on Thursday, July 11, 2013. > > > Thanks, > > Marc & Roger > > > _______________________________________________ > 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