From James.Winterbottom@commscope.com Tue Oct 11 19:42:33 2011 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 736AC21F8BB9; Tue, 11 Oct 2011 19:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.089 X-Spam-Level: X-Spam-Status: No, score=-1.089 tagged_above=-999 required=5 tests=[AWL=-1.511, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, SARE_GIF_ATTACH=1.42] 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 UuYFRERsdfoF; Tue, 11 Oct 2011 19:42:30 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 72E2521F8BB6; Tue, 11 Oct 2011 19:42:30 -0700 (PDT) X-AuditID: 0a0404e8-b7c2eae000002297-38-4e94fe9425f8 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 96.E7.08855.49EF49E4; Tue, 11 Oct 2011 21:42:28 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 11 Oct 2011 21:42:27 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 12 Oct 2011 10:42:26 +0800 From: "Winterbottom, James" To: "geopriv@ietf.org" , "ecrit@ietf.org" Date: Wed, 12 Oct 2011 10:42:23 +0800 Thread-Topic: Local-Civic and LoST Thread-Index: AcyIiJHRCQ55IpfyTGWVYncNvj3WXg== Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012114AEEB4B@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_5A55A45AE77F5941B18E5457ECAC8188012114AEEB4BSISPE7MB1co_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Ecrit] Local-Civic and LoST 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, 12 Oct 2011 02:42:33 -0000 --_004_5A55A45AE77F5941B18E5457ECAC8188012114AEEB4BSISPE7MB1co_ Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC8188012114AEEB4BSISPE7MB1co_" --_000_5A55A45AE77F5941B18E5457ECAC8188012114AEEB4BSISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, At the last IETF meeting we reached a consensus call on what was thought to= be the remaining issue with the local-civic specification (http://tools.ie= tf.org/html/draft-ietf-geopriv-local-civic-01). This issue was to do with t= he registration of extended CAtypes and their associated namespaces. This i= ssue was resolved through consensus and we have a good write up on it. Local-civic has some impacts on LoST implementations, most notably when LoS= T is used for civic location validation. When used in this manner the LoST = server returns a set of qualified civic address elements that it has found = to valid, invalid or hasn't checked. The example in figure 6 of RFC5222 doe= s not show these civic address elements as being qualified and this gave ri= se to an errata (http://www.rfc-editor.org/errata_search.php?rfc=3D5222) th= at points this out. After some discussion on the ECRIT list, the errata has been moved to a sta= te of "Held for document update", and this is largely because it was deemed= that the proposed errata correction requires some kind of consensus call. It has been proposed that since local-civic depends on the errata, that loc= al-civic could normatively update LoST to point out a corrected example and= hence mandate that all these civic elements be qualified in future. I thin= k that this is quite a good idea, and propose the addition below to the loc= al-civic draft, but I would like to get feedback from both ECRIT and GeoPri= v on their views. Cheers James 6. Using Local Civic Extension with the LoST Protocol One ciritical use of civic location information is in next generation emergency services applications, in particular call routing applications. In such cases location information is provided to location-based routing service using the location to service transtion (LoST) protcol [RFC5222]. LoST is used to provide call routing information, but it is also used to validate location information to ensure that it can route to an emergency center when required. LoST is an XML-based protocol and so the namespace extension mechansims described in this document do not impact LoST. When LoST is used for validation a element is returned containing a list valid, a list of invalid, and a list of unchecked civic elements. Figure 6 is an extract of the validation response in Figure 6 from [RFC5222]. country A1 A3 A6 PC HNO Figure 6: Location Validation Example from LoST (RFC5222) The RelaxNG schema in [RFC5222] requires the elements in each of these lists to be namespace qualified, which makes the example in Figure 6 from [RFC5222] in error. This issue is especially significant when local-civic extensions are used as the domain to which the extensions are attributed may impact their interpretation by the server or client. To ensure that local-civic extensions do not cause issues with LoST server and client implementations, all elements listed in a , , or element MUST be qualified with a namespace. To illustrate this the extract above from figure 6 in [RFC5222] becomes Figure 7. ca:country ca:A1 ca:A3 ca:A6 ca:PC ca:HNO Figure 7: Corrected Location Validation Example If validation request has also included the extensions defined in section Section 5 then the validation would response would look like Figure 8. ca:country ca:A1 ca:A3 ca:A6 cae:PN cae:STP ca:PC ca:HNO cae:MP cae:HNP Figure 8: Corrected Location Validation Example James Winterbottom Global Product Manager Commscope GeoLENs IP Location Product Portfolio Andrew Building (39), University of Wollongong Northfields Ave, Wollongong, NSW, 2522 Australia Email: james.winterbottom@commscope.com Phone: +61-2-42-212938 Mobile: +61-447-773-560 [cid:image001.gif@01CC88E4.C53D6D40] www.commscope.com | www.commscopeblogs.com --_000_5A55A45AE77F5941B18E5457ECAC8188012114AEEB4BSISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

At the last IETF meeting we reached a consensus call on = what was thought to be the remaining issue with the local-civic specification (<= a href=3D"http://tools.ietf.org/html/draft-ietf-geopriv-local-civic-01">http:= //tools.ietf.org/html/draft-ietf-geopriv-local-civic-01). This issue was to do with the registration of extended CAtypes and their associated namespaces. This issue was resolved through consensus and we hav= e a good write up on it.

 

Local-civic has some impacts on LoST implementations, mo= st notably when LoST is used for civic location validation. When used in this manner t= he LoST server returns a set of qualified civic address elements that it has f= ound to valid, invalid or hasn’t checked. The example in figure 6 of RFC52= 22 does not show these civic address elements as being qualified and this gave rise to an errata (http://www.= rfc-editor.org/errata_search.php?rfc=3D5222) that points this out.

 

After some discussion on the ECRIT list, the errata has = been moved to a state of “Held for document update”, and this is lar= gely because it was deemed that the proposed errata correction requires some kin= d of consensus call.

 

It has been proposed that since local-civic depends on t= he errata, that local-civic could normatively update LoST to point out a corre= cted example and hence mandate that all these civic elements be qualified in fut= ure. I think that this is quite a good idea, and propose the addition below to t= he local-civic draft, but I would like to get feedback from both ECRIT and Geo= Priv on their views.

 

Cheers

James

 

6=
.  Using Local Civic Extension with the LoST Protocol
 <=
/o:p>
  =
 One ciritical use of civic location information is in next generation=

  =
 emergency services applications, in particular call routing
  =
 applications.  In such cases location information is provided to=

  =
 location-based routing service using the location to service
  =
 transtion (LoST) protcol [RFC5222].  LoST is used to provide call
  =
 routing information, but it is also used to validate location
  =
 information to ensure that it can route to an emergency center when
  =
 required.
 <=
/o:p>
  =
 LoST is an XML-based protocol and so the namespace extension
  =
 mechansims described in this document do not impact LoST.  When LoST<=
o:p>
  =
 is used for validation a <locationValidation> element is returned
  =
 containing a list valid, a list of invalid, and a list of unchecked
  =
 civic elements.  Figure 6 is an extract of the validation response in=

  =
 Figure 6 from [RFC5222].
 <=
/o:p>
 <=
/o:p>
  =
 <locationValidation>
  =
     <valid>country A1 A3 A6</valid>
  =
     <invalid>PC</invalid>
  =
     <unchecked>HNO</unchecked><=
/span>
  =
 </locationValidation>
 <=
/o:p>
  =
       Figure 6: Location Validation Example =
from LoST (RFC5222)
 <=
/o:p>
  =
 The RelaxNG schema in [RFC5222] requires the elements in each of
  =
 these lists to be namespace qualified, which makes the example in
  =
 Figure 6 from [RFC5222] in error.  This issue is especially
  =
 significant when local-civic extensions are used as the domain to
  =
 which the extensions are attributed may impact their interpretation
  =
 by the server or client.  To ensure that local-civic extensions do
  =
 not cause issues with LoST server and client implementations, all
  =
 elements listed in a <valid>, <invalid>, or <unchecked> =
element MUST
  =
 be qualified with a namespace.  To illustrate this the extract above<=
o:p>
  =
 from figure 6 in [RFC5222] becomes Figure 7.
 <=
/o:p>
 <=
/o:p>
  =
 <locationValidation
  =
        xmlns:ca=3D"urn:ietf:params=
:xml:ns:pidf:geopriv10:civicAddr">
  =
     <valid>ca:country ca:A1 ca:A3 ca:A6</vali=
d>
  =
     <invalid>ca:PC</invalid>
  =
     <unchecked>ca:HNO</unchecked>
  =
 </locationValidation>
 <=
/o:p>
  =
            Figure 7=
: Corrected Location Validation Example
=
 <=
/o:p>
  =
 If validation request has also included the extensions defined in
  =
 section Section 5 then the validation would response would look like<=
/o:p>
  =
 Figure 8.
 <=
/o:p>
 <=
/o:p>
 <locatio=
nValidation
  =
      xmlns:ca=3D"urn:ietf:params:xml:ns:pidf=
:geopriv10:civicAddr"
  =
      xmlns:cae=3D"urn:ietf:params:xml:ns:pid=
f:geopriv10:civicAddr:ext">
  =
   <valid>ca:country ca:A1 ca:A3 ca:A6 cae:PN cae:STP</v=
alid>
  =
   <invalid>ca:PC</invalid><=
/pre>
  =
   <unchecked>ca:HNO cae:MP cae:HNP</unchecked><=
/o:p>
 </locati=
onValidation>
 <=
/o:p>
  =
            Figure 8=
: Corrected Location Validation Example



 



 







 

  
  
James
  Winterbottom

  
Global Product Manager

  
Commscope GeoLENs

  
IP Location Product Portfo=
lio

  
Andrew Building (39), University of Wollongong

  
Northfields Ave, Wollongong, NSW=
, 2522 Australia

  
Email: james.winterbottom@comms=
cope.com

  
Phone:
  +61-2-42-212938

  
Mobile:
  +61-447-773-560

  

  
www.commscope.com | www.commscopeblogs.com=


  		
 








 
--_000_5A55A45AE77F5941B18E5457ECAC8188012114AEEB4BSISPE7MB1co_-- --_004_5A55A45AE77F5941B18E5457ECAC8188012114AEEB4BSISPE7MB1co_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=4560; creation-date="Wed, 12 Oct 2011 02:42:23 GMT"; modification-date="Wed, 12 Oct 2011 02:42:23 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhyAAhAHcAACH/C01TT0ZGSUNFOS4wDQAAAAFzUkdCAK7OHOkAIf8LTVNPRkZJQ0U5LjAX AAAAC21zT1BNU09GRklDRTkuMEI8pPUALAAAAADIACEAh/X19QGCtYjY+AC18eP0/nGyzJWTlOXl 5X16e1fL9XVyc97d3RgUFcvr/P7+/qvh+gG48R0ZGkqMqISBguLi4gBqlIyLiwaVzBYSE+34/unp 6dbV1tPu/WxpapHa+aXH1wB9rC6151xaWu3s7CfD9GPO9bPj+mqkvIvG3FRRUhBWdha98vz8/Oj2 /ra1tfr6+vn9/vDw8E1KSwCs7NTx/s7NzUbK9b28vfX9/2ViY6Xe+DnI9Zvd+TUxMnjN7tLR0XzU 9sbi7QFjiz06O0az3EVCQ/D5/sLBwsrJySAcHZqYmbq5ubnl+6qoqdnx/SmaxODr8sTp/NnZ2S4q K8bFxfLy8hyDq4C81GrR+CUhIrXa6wCY0prT7PD1+vj4+DSTt7Kxsq6srfn7/qKgofP6/vz+/wB0 onvW+mhmZt72/qypqe/u7nDQ9rzp/xeKtDAsLTCk0NHj66nU6dbq897y/aelpp+dnZnb9ygkJvz8 /9r0/gGKwDg0NW3E5Bd1mwu78lBNToiFhvT7/li74QF4pwBwnACj4UhFRl9dXhsWF3BtbkA8Pbi2 t0Gu1wJagTo3OPD5/amnqLCurpeWll3Q9hy/9KWjpKSio8Dn+8zLy5uZmqimp8fGx7SyswCh3ACx 8LSztJ+ennd1dvP6/PD6/4+Njtrx+7y7vL++vgwICQqz8EtHSDIvMIF/gImHiBAMDaGfoHJvcF2g uSonKMjHx2JfYCIeH7u6u1JPUFdVVpmXmBCCqxQQEUI/QFpXWPj3+PDv8Hp4eezr6+zr7M/Pz9/f 3+7t7pKQkOjn5/Dv7/f39/v7+9zc3ODg4NHQ0PH5/vLx8vr5+rPQ3PH4+//8++vr65jP6MG/wACu 73TB32+Tpev09xys4/39/SR9oBF8pKHM3tzb29Ha3cfo9dPT0zJzj7Pp/Lzi87i3uPv8/Mjf59TU 1H98ffD6/dfv+/Dw7wB7rw6r4kSky/T09FWjwsTDxNzy+u3t7fHx8Z2bnOP6/6yrq/n6+vn5+XPW +v///wj/AP8JHEhQ4LJlBRMmTLeMhcKHECNKnEhxoIMXFQseRKjQQUEY9pwQwFHQgceMKFMKJDcJ DSAZMnApaoIMYr8jgUTAlIGoVCaJP8C4AMNs4j1QLjod6UawmVAwNSb2uwUKFLp5CQFI6iBjFSAE GyYqOzJBxCqYviagwkjw5DgfPu60iaLlg9041B5SEOqi75ENVRL2W4K0r2HDoJYA+MdijChRdpgW pIIoCwYGmDMz6FHqV8kmhyJgTkSaAYYkKRhBRJSKQaocE5WkwvCqRwyCx2a/eoQ1Ii0MGHglIlYQ yaHRiUxn0QVx2ZgiES6PNp1o1ZKCc4gQuUPHCDgJu/Zs/9lygUgQhZdmA8cQAc+jDjcICrPFa719 4LxsUfhnAZEmSzmUQpAXEyTBgGiJZDFFFslFEAEvKSwwEAWIMJAIgkkkEUGDFiqCj0K+MGBLElMc EJEDuCQyYg/VEORKfrZEgIpE7GBgy4i0EEQLHgwYGEESpIkWiUIbpGBhg3hMAWSPB06gjEBcXDAI AYK0cAIInkCwQwI2kPDJDGfAUFAkDGQRHXAWdhjYPyMoact9672SxAHJiNAJIrWEIcNAwIjAi4FT xCLJBhRIgc4EQxzIi2r/kDPEaQzwEUwYxKxTQySKvNEjBjLsR1A3gKhoCwNDQrROFkmMOIuJAyFg 45vBRP9UxRAR3MjAKQNB00uPWYhyxDqghBoBKxoUdAQrBzJQhAVHhNMMOZGgwWMirLSIwh59wGCE IAXsMUAlZ+jARBRReFDJDDaQQhCZESyCAAKxyJBFj690wFSb7Sny7r7vBjNBFVKgUc9ZUgAiEAAi nJZIB1IoNEIpEeTgUTF8HGhLIDUltIAoP2Kwyj0DHpJID1NgABtEpfAyyxBJZCHhQIpgMEUPiQyx 2EOnJLiIZaAMpEaPtnRC0DwpJILBJgQRM8uFeCjRW0Hk1IKBJP+gEAAROJCBQxzeQlCCAB7w8IAJ DTBRCTYJlDEQmQx0MNALzuTwYyLXsDlFBG8YExEAuRj/MEYd7KQg0AR/RjCJRFQU888vuBw4S3wR WZIhBm4PlEyiLzEwRcYJvXAIL4DkkEgSxA0k9RByR1D3Q7HwwocoSWBgyUAKXKZAQqfQpshAa/Ry IStIRMSCakEEcEED2jqAQpYrlMAGEALcocMDUQgwADYCrI0ZGiWJjsHt99z9hqcQ3SCDJqEccsQ/ SGTIgAUZTXKaLZBLdMmPDPQsEDI9MCDCBJiZnUIyEbtAiKJHVLBICjAwBF1E53YKuUcPMFALJSSH OQKpEAMEKBCPVIERYAieQFrxp1n8ZCIw+EIABlGGdkCiG9n4BAT+YIMEYAF6YXvAA1bwCVXQQCBs 415B/2gBJIOtQXzkg8gClKCEojigFpjJhUMoUg0+REdAFVGAhQ7hBYE0YxYYQMMRRIOIh7SCPbTQ YgTQMZB0HGcI65hCIh6xpoKAwTR2uARm4CeQDmAmEBMpxiwMNIaKgAMee9BBGYwACRYAYQAQgAAJ tuQ86PFAByu4HiWAuL2EDANZQ/jHEfGWRIqQY0RJECFFxsCeRTxtIhRQUiIgtwED5UAZrEhEibKy CAY84hdaTIQaBqKMR/iSBbmw0IwSkgMbFaMOmGHHQAxwmjc4QyIWYM8h2CIRB3wBHheggyCeYQQx mAOSM5xkDZ/nATZEsod0+EcQE6KBNyRiEaJEYkpKgf+BROQCJSHCABYzogjTiEIgSIgO96DIgEsk BBVGu10rMFNIgYygf6E8hu0ScoApMGAV/5BEcmIxoVk4iBVqeJJClrGK5MCiInEgRADgkAEyPIMU z2iHDdAJgUqQoIZYKEEmITCAGfBAnp0syDU2JDhjiG8YKclFcjSREQ304Eely0gntoiQU4jmoLCw kAhOQrt+XmeiGDjGQJrh0T0RQ0N8uA1BLGEa+O0jObUgSBgctKFDTKKU/wiHSfGgOIp8oBABaIRN GQkJMehhBzz9wwoqUYk/oLOoCfhHE5I6EBaIwGitsFsEZmGAOljitKiFxS0ewgoN5agi5NDQIz6E Ein/mPQNNQlDcmLFDDwkYRZJXEPF+PCOf5TCNK4YyDp4ZLAXQCcR1yFIiGxBnBuIxhcFkcQbFIaB N4iiYQNBBVcrUgDEKpYMkGCsGDIgABJEkqeRfO8nQvCPn1FuIN0gh+gyFJU2pUozmkkFLh6SoSkU pSIQTYQMuFkRYNAMD+v4Ryj2yJgUMaCiArkjBkj6j0mYJlYIHVUZ/1EjBkBQIOHg0SEQMsZEAIKs AimGAsDYsVkoYSCbZUBeKyKLCgTgCV0ggxGGPGQy5IEA5vDHDv4Q3/heLwRl+FkEemEBVyggBTxK Ai8mYFE3ATgzAn7IiKbwMoowgjQpkExGipkIPPzg/x/HwIxa/0HNRIiAIB3o5zJZyYDdCWSpDDjZ UiMw24FoAjhYfGsiDuGZhDAjEBXTEAak+Q+6ti0jPQ6AG6CAg/QSucgw6IYYaEAJ+BaVG1Euk4Go g6BgsAVfs2CHBWZNawsEolQJGREewEsRTlyoCCrNyAHeMNqGnfHCAtmAmabgKQkyYAhrCsNlTvYP MGz0H7PaEK7+4YBkZiEs/5CChhYBjbbIxwByfNOQfubPjJygAiAgxAcc8Ol6P+MZYshDqeU7A/r+ DFWZwRsi6ifaN4wgJT0AEsElIgVU7RIlmYhRD5LxD1FcpgkCAVVyMP4PUBgNAQNxAWn+KZA6AAfE //8IhmlA/o8F8CjNMTZpD4oVkXXQKgJDeAEVLmSzilxBCIQAgQQEkYEM1PvTjaWBZYmKDU8QQbMH kkET6hCGerCKIPgaX0oQkRwuVyTbidBfRg6diBR4xI8YiC6ck1rQCLz2H6jYkAxO4mFeJFcg1p1y F/NhmhsLZNgReHhEaoCqCHBiGHezRVQoIg0hIFYI0sgAAVrQAqMf3aYkGMAAvrSFPiD10hHJOmAl cugpB3sifmSAECvCAhkY7e4iOND6BPID2c4DAI/AALAHggRb1IwtgTCNAQaS7SRERWp4OPA/7vGI Wik/Ip/FgB3+UTQMeH0i2/ADvM1QDnekgQ50mHz/5S1vhGeQIfOfwIYhLqCFz6/+IaJPicsNhOuJ MAJoi6dIJ0Znizd3o3G2cEL/0A8iEwE1UAPRcXcrgQeJwAe9oXIM8FK0YxqaUAXbdWcDgQ+L8CMR lgmo4AJXVxAqxwuHc2hJwAohGBGy4HgBIAQSwAF6wAFOYArhJ34ZgANzEA/pZwhb8AQZ4H4SEX8p EQvs0QMpCBFeIDIKdjMSgQzNxwCI4BFeUARtBm4CEQjAYQDURF0EIUjUQnN+lAhhQBAep3o3YDQY 9g/R0FIRkEC5QBtpSBBowAC8cGPVcFWgNxHqIAQVEHSOIAHnEIMcwAHu4ATg1wI4cAKGoH5bsAco /8BJqheE+pQSUuBbDJALdSQRIjcqHcBgCrEGRpIqpTMPfKBLhSUQBORPKcALMjBFf0dsU1BYsbdG BGEMNLMIfiR4/6BxtEhC95UQa3BVEbBa/3Bovjd8EoERJ8CHQScEfnAFmEAD0kgDeqAPpqANZjAD ntCIQAaJ7+cwk5gSEzYqKXCKHIUIAmRxo1ILo5dsMiAiGICM/1AN9jRzBNEPVJgFeJBWBVEFDwZu gNAjnFAQfqSPgZYQISKG/zBGLfN2AxF8w9IiaugLpxEBgeCJBHEDgHAA2+ANzBgAhVAIVkAPKCAH cvABBaACjjAeF7AHAdB+3iiJeHOEFREMf8IArP+gCSmIDLDwCK/ACooDAL6QH5GiCym4AK6QbrwQ C2rmhYVGEBNgIy1jhQJRTLUSPMsgMlxIEFtlK2NYEBoUCv+wDI0TAT1AjGqoBCOyZQSBDIcAKSmg GAWxAaJgC6+ABoKgBX7Ah2YAAgFACBUgBELgCCqgAhVwAS35l1dACmQQk6F3N1PwAyMwmZQ5mfeg ZgrBAuxwIaLBCrXgCvngCjnQPxsSdgJRBWjAHp3pCwhgQLngURrCAAjAYM7AIIuAmeyTKmUHY2NZ gOtTBRuYBebIJq11ggdXELGAGchIBTHyI7nQCgjgegbSCyBDEBQgA3/ya7FwDEoQOFnGC48QB2n/ YA17WQGFEHQBAALqiUh74JKEQAgFIIMtICbz9JgtwwdD8Aj6uZ98UAQ0WRD7wAeqiRnSQRoY0Ato KRBKsF0XkhwBZzSPsA8JQQUPUgS8+QuLwAuv4HcEwQKrQBs9U08YgAdHiAavUC8KoQCvkAqhJRD7 MCpLYiEP0gvhoBDAgABvsiGmEXDskQPikAZR0AZc8AWCaZ7nqZ7qSQhmUAFWkA1t0AYcQABiUgcn Sm0PIQwMKBpfRof6QRHIUAq9sGqjMQspEAq0VRDNYAFFEKMWkgWrYAASaSyPwAeVUxAGUAS4MHoK wAc9wEYHcAiPAAhrkBBLcAjqoxBK0AOcQRBU/5ACozIab8AOx/kQmaAIeBhwrNABdYMDTlA2D3AH g2AFgVmkFVCqFfAN8iAAOhQFUSomoMCnLAcRa3AIQ7AItnqrtzoEh8A5EwEAxLAJBjAJmsAIxcCb WfED+zAJyjooGPk2MRADr9ShxnowwBADXdQN+BADVTCt3YCbA/ELz8qEGfcDYxCsoMCrEaEB15AP ygoLVEBz/0AGBNAAmPAAPOABQDAIcOAGu9CvbvAERMAGAnBJTNAAppABasMPMQAM4toR2YoPEBux ERsD+OCtKnGxGJuxGruxFVEGGdCp9XqvAnAGWEAJCUAJWOAPZxA94hIF7jASHBuzMjuzNFuzKXEB AxlABw0QBSZgr3fgAQIQtB4QNjpgApjQAO6AiDa7tEzbtE6rEmVABi3QqVHABCbQszo0NkxwtFGa AWLytGAbtmLrtN1AdATgBIPYAGrbADJIBy3wDF87tnI7t3SrsWUAA4JgBEVndIKAA2UwrWIbEAA7 --_004_5A55A45AE77F5941B18E5457ECAC8188012114AEEB4BSISPE7MB1co_-- From lreeder@bandwidth.com Tue Oct 18 15:51:50 2011 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 02EF921F8B7A for ; Tue, 18 Oct 2011 15:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 tyviNlf+Kotm for ; Tue, 18 Oct 2011 15:51:49 -0700 (PDT) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with SMTP id 14DE721F867F for ; Tue, 18 Oct 2011 15:51:48 -0700 (PDT) Received: from mail-yx0-f182.google.com ([209.85.213.182]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP; Tue, 18 Oct 2011 15:51:49 PDT Received: by mail-yx0-f182.google.com with SMTP id 16so1641811yxn.27 for ; Tue, 18 Oct 2011 15:51:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.192.99 with SMTP id hf3mr770168obc.64.1318978301160; Tue, 18 Oct 2011 15:51:41 -0700 (PDT) Received: by 10.182.14.100 with HTTP; Tue, 18 Oct 2011 15:51:41 -0700 (PDT) Date: Tue, 18 Oct 2011 16:51:41 -0600 Message-ID: From: Larry Reeder To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Ecrit] Construction of LoST findService response path element? 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, 19 Oct 2011 01:16:26 -0000 We've got a question regarding the construction of the path element in the LoST findServiceResponse. Consider the simple case where the first server contacted by the client is the authoritative server. RFC-5222 says this about path construction: "The server that answers the request instead of forwarding it, such as the authoritative server, copies the element verbatim into the response. The element is not modified in responses as the responses traverses the server chain back to the querying client." In my reading, this paragraph says the LoST client (or any LoST servers recursing to other LoST servers) must include the with a for the server it is contacting in findService, and that the authoritative server must copy what the client sent into its findServiceResponse. However, none of the findService request examples in RFC 5222 contain a path element, so it's unclear how the findServiceResponse path element was generated. Anyone have any guidance on this? Regards............. Larry -- Larry Reeder EVS Software Team Lead www.inetwork.com Office: 303.228.8805 lreeder@inetwork.com 1855 Blake Street, Suite 101 Denver, CO 80202 inetwork is a division of Bandwidth From rbarnes@bbn.com Wed Oct 19 07:18:17 2011 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 51D5B21F8BBF for ; Wed, 19 Oct 2011 07:18:17 -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 u1mcprsA85OP for ; Wed, 19 Oct 2011 07:18:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 904F321F8BB7 for ; Wed, 19 Oct 2011 07:18:16 -0700 (PDT) Received: from ros-dhcp192-1-51-60.bbn.com ([192.1.51.60]:51798) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RGWxT-000CK1-8h; Wed, 19 Oct 2011 10:17:27 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 19 Oct 2011 10:17:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <80476389-0579-4DFB-AF86-D81A24A8DFD3@bbn.com> References: To: Larry Reeder X-Mailer: Apple Mail (2.1084) Cc: ecrit@ietf.org Subject: Re: [Ecrit] Construction of LoST findService response path element? 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, 19 Oct 2011 14:18:17 -0000 Hi Larry, It seems to me that the answer is contained in the following paragraph: " If a query is answered iteratively, the querier includes all servers = that it has already contacted. " So the first query the client sends goes out without a element, = but if the client gets back a redirect, then it adds a to the = second query. For example, if Server1 delegates to Server2 and Server2 = is authoritative: Client->Server1 ... Server1->Client Client->Server2 ... Server1 Server2->Client ... Server1 Hope this helps, --Richard On Oct 18, 2011, at 6:51 PM, Larry Reeder wrote: > We've got a question regarding the construction of the path element in > the LoST findServiceResponse. >=20 > Consider the simple case where the first server contacted by the > client is the authoritative server. RFC-5222 says this about path > construction: >=20 > "The server that answers the request instead of forwarding it, such as > the authoritative server, copies the element verbatim into the > response. The element is not modified in responses as the > responses traverses the server chain back to the querying client." >=20 > In my reading, this paragraph says the LoST client (or any LoST > servers recursing to other LoST servers) must include the with > a for the server it is contacting in findService, and that the > authoritative server must copy what the client sent into its > findServiceResponse. However, none of the findService request > examples in RFC 5222 contain a path element, so it's unclear how the > findServiceResponse path element was generated. >=20 > Anyone have any guidance on this? >=20 >=20 > Regards............. Larry >=20 > --=20 > Larry Reeder > EVS Software Team Lead > www.inetwork.com > Office: 303.228.8805 > lreeder@inetwork.com >=20 > 1855 Blake Street, Suite 101 > Denver, CO 80202 > inetwork is a division of Bandwidth > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From apenniston@geo-comm.com Wed Oct 19 08:21:13 2011 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 3D56521F8A80 for ; Wed, 19 Oct 2011 08:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.993 X-Spam-Level: X-Spam-Status: No, score=0.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PENIS1=3.592] 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 MDQKb8MJ49Bu for ; Wed, 19 Oct 2011 08:21:12 -0700 (PDT) Received: from mail.geo-comm.com (mail.geo-comm.com [66.173.42.245]) by ietfa.amsl.com (Postfix) with ESMTP id 069DF21F8AD8 for ; Wed, 19 Oct 2011 08:21:12 -0700 (PDT) Received: from EXCHANGE10.geo-comm.local ([::1]) by EXCHANGE10.geo-comm.local ([::1]) with mapi id 14.01.0323.003; Wed, 19 Oct 2011 10:20:12 -0500 From: Avery Penniston To: "Richard L. Barnes" , Larry Reeder Thread-Topic: [Ecrit] Construction of LoST findService response path element? Thread-Index: AQHMjfyfTVGlQqF4YEuNx10LrVjptJWEC3SA//+20jA= Date: Wed, 19 Oct 2011 15:20:11 +0000 Message-ID: References: <80476389-0579-4DFB-AF86-D81A24A8DFD3@bbn.com> In-Reply-To: <80476389-0579-4DFB-AF86-D81A24A8DFD3@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 009B3B3E002A30009B3C8B x-ninja-pim: Scanned by Ninja x-ninja-attachmentfiltering: (no action) x-originating-ip: [192.168.10.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Construction of LoST findService response path element? 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, 19 Oct 2011 15:21:13 -0000 I had a couple questions/comments to add: 1.) Shouldn't the response in your example also include a via element for t= he answering server? What happens when the recursion goes more than 1 level= deep; how would the original querier know who answered the query? =20 ... Server1 Server2 2.) What if the initial query which contained no path was sent to Server1 a= nd Server1 is the authoritative source? The RELAX NG Schema for LoST indica= tes that requests can optionally have a path, but responses MUST have one, = and the path has ONE or more vias. My personal opinion is that when a LoST server receives a request it should= append the path with its own application unique string before either retur= ning a response, or sending the request on to another LoST server in recurs= ion. This opinion does go against this line in section 6, "The server that= answers the request instead of forwarding it, such as the authoritative s= erver, copies the element verbatim into the response." This could be remedied by changing that line to something like " The server= that answers the request instead of forwarding it, such as the authoritat= ive server, copies the element's elements verbatim into the r= esponse, and appends its own application unique string as the last el= ement." Perhaps I'm missing something here, but why does the client LoST server in = a recursive query need to put the target server's application unique string= at the end of the request path before even sending it? Shouldn't the targ= et server do that? Avery Penniston=20 Software Developer GeoComm Inc. 601 W. Saint Germain St., Saint Cloud, MN 56301 Office: 320.240.0040=20 www.geo-comm.com -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= ichard L. Barnes Sent: Wednesday, October 19, 2011 9:17 AM To: Larry Reeder Cc: ecrit@ietf.org Subject: Re: [Ecrit] Construction of LoST findService response path element= ? Hi Larry, It seems to me that the answer is contained in the following paragraph: " If a query is answered iteratively, the querier includes all servers that i= t has already contacted. " So the first query the client sends goes out without a element, but = if the client gets back a redirect, then it adds a to the second que= ry. For example, if Server1 delegates to Server2 and Server2 is authoritat= ive: Client->Server1 ... Server1->Client Client->Server2 ... Server1 Server2->Client ... Server1 Hope this helps, --Richard On Oct 18, 2011, at 6:51 PM, Larry Reeder wrote: > We've got a question regarding the construction of the path element in=20 > the LoST findServiceResponse. >=20 > Consider the simple case where the first server contacted by the=20 > client is the authoritative server. RFC-5222 says this about path > construction: >=20 > "The server that answers the request instead of forwarding it, such as=20 > the authoritative server, copies the element verbatim into the=20 > response. The element is not modified in responses as the=20 > responses traverses the server chain back to the querying client." >=20 > In my reading, this paragraph says the LoST client (or any LoST=20 > servers recursing to other LoST servers) must include the with=20 > a for the server it is contacting in findService, and that the=20 > authoritative server must copy what the client sent into its > findServiceResponse. However, none of the findService request > examples in RFC 5222 contain a path element, so it's unclear how the=20 > findServiceResponse path element was generated. >=20 > Anyone have any guidance on this? >=20 >=20 > Regards............. Larry >=20 > -- > Larry Reeder > EVS Software Team Lead > www.inetwork.com > Office: 303.228.8805 > lreeder@inetwork.com >=20 > 1855 Blake Street, Suite 101 > Denver, CO 80202 > inetwork is a division of Bandwidth > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From lreeder@bandwidth.com Thu Oct 20 12:42:12 2011 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 D34BC21F8997 for ; Thu, 20 Oct 2011 12:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.03 X-Spam-Level: X-Spam-Status: No, score=-4.03 tagged_above=-999 required=5 tests=[AWL=-1.646, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAHa2GyUKu5D for ; Thu, 20 Oct 2011 12:42:11 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with SMTP id 00F0921F89BA for ; Thu, 20 Oct 2011 12:42:10 -0700 (PDT) Received: from mail-qy0-f175.google.com ([209.85.216.175]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP; Thu, 20 Oct 2011 12:42:11 PDT Received: by qyk35 with SMTP id 35so4825704qyk.20 for ; Thu, 20 Oct 2011 12:42:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.8 with SMTP id l8mr1626755qci.168.1319139723373; Thu, 20 Oct 2011 12:42:03 -0700 (PDT) Received: by 10.229.247.149 with HTTP; Thu, 20 Oct 2011 12:42:03 -0700 (PDT) In-Reply-To: References: <80476389-0579-4DFB-AF86-D81A24A8DFD3@bbn.com> Date: Thu, 20 Oct 2011 13:42:03 -0600 Message-ID: From: Larry Reeder To: Avery Penniston Content-Type: multipart/alternative; boundary=0016e65519d69eed1504afc026b2 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Construction of LoST findService response path element? 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 Oct 2011 19:42:12 -0000 --0016e65519d69eed1504afc026b2 Content-Type: text/plain; charset=ISO-8859-1 Hey Richard, What you say makes sense for an ECRF and client acting in iterative mode, and is probably the only way for that system to provide loop detection given the current LoST schema. Since you can't put path info in a redirect, it would be up to the client to update the request with path info. However, what Avery says still holds for recursive mode. Given the examples, the server must put a path in its response, otherwise the response breaks the schema. It's true that a client acting in recursive mode could create or update the path with the ECRF it's about to connect to, and then the authoritative ECRF could return the path verbatim in its response. If that's the recommended approach, the examples should be updated to show this. However, the intent in the LoST schema seems to be that the server should maintain the path element. because the request (client) doesn't need to provide a path, but the response (server) does. The other problem with expecting the client to maintain the path is that a misbehaving client could put the invalid ECRF string (or no string) in its request, leading to an extra node being traversed in a loop situation because the first ECRF in the loop wouldn't recognize itself in the via list. Thanks............... Larry On Wed, Oct 19, 2011 at 9:20 AM, Avery Penniston wrote: > I had a couple questions/comments to add: > > 1.) Shouldn't the response in your example also include a via element for > the answering server? What happens when the recursion goes more than 1 > level deep; how would the original querier know who answered the query? > > > ... > > Server1 > Server2 > > > > > 2.) What if the initial query which contained no path was sent to Server1 > and Server1 is the authoritative source? The RELAX NG Schema for LoST > indicates that requests can optionally have a path, but responses MUST have > one, and the path has ONE or more vias. > > > My personal opinion is that when a LoST server receives a request it > should append the path with its own application unique string before either > returning a response, or sending the request on to another LoST server in > recursion. This opinion does go against this line in section 6, "The > server that answers the request instead of forwarding it, such as the > authoritative server, copies the element verbatim into the > response." > > This could be remedied by changing that line to something like " The > server that answers the request instead of forwarding it, such as the > authoritative server, copies the element's elements verbatim > into the response, and appends its own application unique string as the > last element." > > Perhaps I'm missing something here, but why does the client LoST server in > a recursive query need to put the target server's application unique string > at the end of the request path before even sending it? Shouldn't the > target server do that? > > > Avery Penniston > Software Developer > GeoComm Inc. > 601 W. Saint Germain St., Saint Cloud, MN 56301 > Office: 320.240.0040 > www.geo-comm.com > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Richard L. Barnes > Sent: Wednesday, October 19, 2011 9:17 AM > To: Larry Reeder > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Construction of LoST findService response path > element? > > Hi Larry, > > It seems to me that the answer is contained in the following paragraph: > " > If a query is answered iteratively, the querier includes all servers that > it has already contacted. > " > So the first query the client sends goes out without a element, but > if the client gets back a redirect, then it adds a to the second > query. For example, if Server1 delegates to Server2 and Server2 is > authoritative: > > Client->Server1 > ... > > Server1->Client > > > Client->Server2 > > ... > > Server1 > > > > Server2->Client > > ... > > Server1 > > > > > Hope this helps, > --Richard > > > > On Oct 18, 2011, at 6:51 PM, Larry Reeder wrote: > > > We've got a question regarding the construction of the path element in > > the LoST findServiceResponse. > > > > Consider the simple case where the first server contacted by the > > client is the authoritative server. RFC-5222 says this about path > > construction: > > > > "The server that answers the request instead of forwarding it, such as > > the authoritative server, copies the element verbatim into the > > response. The element is not modified in responses as the > > responses traverses the server chain back to the querying client." > > > > In my reading, this paragraph says the LoST client (or any LoST > > servers recursing to other LoST servers) must include the with > > a for the server it is contacting in findService, and that the > > authoritative server must copy what the client sent into its > > findServiceResponse. However, none of the findService request > > examples in RFC 5222 contain a path element, so it's unclear how the > > findServiceResponse path element was generated. > > > > Anyone have any guidance on this? > > > > > > Regards............. Larry > > > > -- > > Larry Reeder > > EVS Software Team Lead > > www.inetwork.com > > Office: 303.228.8805 > > lreeder@inetwork.com > > > > 1855 Blake Street, Suite 101 > > Denver, CO 80202 > > inetwork is a division of Bandwidth > > _______________________________________________ > > 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 > -- Larry Reeder EVS Software Team Lead www.inetwork.com Office: 303.228.8805 lreeder@inetwork.com 1855 Blake Street, Suite 101 Denver, CO 80202 inetwork is a division of Bandwidth --0016e65519d69eed1504afc026b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Richard,

What you say makes sense for an ECRF and client acting = in iterative mode, and is probably the only way for that system to provide = loop detection given the current LoST schema.=A0 Since you can't put pa= th info in a redirect, it would be up to the client to update the request w= ith path info.=A0=A0 However, what Avery says still holds for recursive mod= e.=A0 Given the examples, the server must put a path in its response, other= wise the response breaks the schema.

It's true that a client acting in recursive mode could create or up= date the path with the ECRF it's about to connect to, and then the auth= oritative ECRF could return the path verbatim in its response.=A0 If that&#= 39;s the recommended approach, the examples should be updated to show this.= =A0=A0 However, the intent in the LoST schema seems to be that the server s= hould maintain the path element. because the request (client) doesn't n= eed to provide a path, but the response (server) does.

The other problem with expecting the client to maintain the path is tha= t a misbehaving client could put the invalid ECRF string (or no string) in = its request, leading to an extra node being traversed in a loop situation b= ecause the first ECRF in the loop wouldn't recognize itself in the via = list.

Thanks...............=A0=A0=A0=A0=A0=A0=A0 Larry

On Wed, Oct 19, 2011 at 9:20 AM, Avery Penniston <apenniston@geo-comm.com<= /a>> wrote:
I had a couple questions/comments to add:
1.) Shouldn't the response in your example also include a via element f= or the answering server? What happens when the recursion goes more than 1 l= evel deep; how would the original querier know who answered the query?

<findServiceResponse>
=A0<mapping>...</mapping>
=A0<path>
=A0 =A0<via>Server1</via>
=A0 =A0<via>Server2</via>
=A0</path>
</findServiceResponse>


2.) What if the initial query which contained no path was sent to Server1 a= nd Server1 is the authoritative source? The RELAX NG Schema for LoST indica= tes that requests can optionally have a path, but responses MUST have one, = and the path has ONE or more vias.


My personal opinion is that when a LoST server receives a request it should= append the path with its own application unique string before either retur= ning a response, or sending the request on to another LoST server in recurs= ion. =A0This opinion does go against this line in section 6, "The serv= er that answers the request instead of forwarding it, such as =A0the author= itative server, copies the <path> element verbatim into the =A0respon= se."

This could be remedied by changing that line to something like " The s= erver that answers the request instead of forwarding it, such as =A0the aut= horitative server, copies the <path> element's <via> elemen= ts verbatim into the =A0response, and appends its own application unique st= ring as the last <via> element."

Perhaps I'm missing something here, but why does the client LoST server= in a recursive query need to put the target server's application uniqu= e string at the end of the request path before even sending it? =A0Shouldn&= #39;t the target server do that?


Avery Penniston
Software Developer
GeoComm Inc.
601 W. Saint Germain St., Saint Cloud, MN 56301
Office: 320.240.0040
www.geo-comm.com<= br>


-----Original Message-----
From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] On Behalf Of Richard L. Barnes
Sent: Wednesday, October 19, 2011 9:17 AM
To: Larry Reeder
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Construction of LoST findService response path element= ?

Hi Larry,

It seems to me that the answer is contained in the following paragraph:
"
If a query is answered iteratively, the querier includes all servers that i= t has already contacted.
"
So the first query the client sends goes out without a <path> element= , but if the client gets back a redirect, then it adds a <path> to th= e second query. =A0For example, if Server1 delegates to Server2 and Server2= is authoritative:

Client->Server1
<findService>...</findService>

Server1->Client
<redirect target=3D"Server2">

Client->Server2
<findService>
=A0...
=A0<path>
=A0 =A0<via>Server1</via>
=A0</path>
</findService>

Server2->Client
<findServiceResponse>
=A0<mapping>...</mapping>
=A0<path>
=A0 =A0<via>Server1</via>
=A0</path>
</findServiceResponse>


Hope this helps,
--Richard



On Oct 18, 2011, at 6:51 PM, Larry Reeder wrote:

> We've got a question regarding the construction of the path elemen= t in
> the LoST findServiceResponse.
>
> Consider the simple case where the first server contacted by the
> client is the authoritative server. =A0RFC-5222 says this about path > construction:
>
> "The server that answers the request instead of forwarding it, su= ch as
> the authoritative server, copies the <path> element verbatim int= o the
> response. =A0The <path> element is not modified in responses as = the
> responses traverses the server chain back to the querying client."= ;
>
> In my reading, this paragraph says the LoST client (or any LoST
> servers recursing to other LoST servers) =A0must include the <path&= gt; with
> a <via> for the server it is contacting in findService, and that= the
> authoritative server must copy what the client sent into its
> findServiceResponse. =A0 =A0However, none of the findService request > examples in RFC 5222 contain a path element, so it's unclear how t= he
> findServiceResponse path element was generated.
>
> Anyone have any guidance on this?
>
>
> Regards............. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Larry
>
> --
> Larry Reeder
> EVS Software Team Lead
> www.inetwork.com=
> Office: 303.228.88= 05
> lreeder@inetwork.com
>
> 1855 Blake Street, Suite 101
> Denver, CO 80202
> inetwork is a division of Bandwidth
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ecrit



--
Larry Reede= r
EVS Software Team Lead
www.inetwork.com
Office: 303.228.8805
lreeder@inetwork.com

1855 Blake Street, Suite 101
Denver, CO 80202
inetwork is a divis= ion of Bandwidth

--0016e65519d69eed1504afc026b2-- From christer.holmberg@ericsson.com Mon Oct 24 05:38:17 2011 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 C856521F8D45 for ; Mon, 24 Oct 2011 05:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pdkbMPBNksS for ; Mon, 24 Oct 2011 05:38:17 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id EF0A721F8D38 for ; Mon, 24 Oct 2011 05:38:16 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-41-4ea55c37d317 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7C.9B.13753.73C55AE4; Mon, 24 Oct 2011 14:38:16 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 24 Oct 2011 14:38:15 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Date: Mon, 24 Oct 2011 14:38:14 +0200 Thread-Topic: Draft new: draft-holmberg-ecrit-emergency-callback-id-00.txt Thread-Index: AcySScx7fErHykWZTUS/FcFqNY3aFQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585223423647D@ESESSCMS0356.eemea.ericsson.se> 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_7F2072F1E0DE894DA4B517B93C6A0585223423647DESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Ecrit] Draft new: draft-holmberg-ecrit-emergency-callback-id-00.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: Mon, 24 Oct 2011 12:38:17 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585223423647DESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a draft, draft-holmberg-ecrit-emergency-callback-id-00.txt, = which defines a new gruu type, emergency gruu (eGRUU). When a UA makes an emergency call, it can insert the eGRUU in the Contact h= eader field of the INVITE request (for the emergency call). The PSAP, when making a callback call, can use the eGRUU in the Request-URI= of the INVITE request (for the callback call). Regards, Christer NOTE: By misstake I also submitted a draft named draft-holmberg-emergency-c= allback-id-00 (i.e. without the "ecrit" part), which I will request to be w= ithdrawn. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585223423647DESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I've submitted a draft, draft-holmberg-ecrit-emergenc= y-callback-id-00.txt, which defines a new gruu type, emergency gruu (eGRUU)= .
 
When a UA makes an emergency call, it can insert the = eGRUU in the Contact header field of the INVITE request (for the emergency = call).
 
The PSAP, when making a callback call, can use the eG= RUU in the Request-URI of the INVITE request (for the callback call).
 
Regards,
 
Christer
 
NOTE: By misstake I also submitted a draft named draf= t-holmberg-emergency-callback-id-00 (i.e. without the "ecrit" par= t), which I will request to be withdrawn.
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A0585223423647DESESSCMS0356e_-- From internet-drafts@ietf.org Thu Oct 27 12:22:00 2011 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 DB7B721F8B1E; Thu, 27 Oct 2011 12:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 t1qo17Vljf5z; Thu, 27 Oct 2011 12:22:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D74421F8ABB; Thu, 27 Oct 2011 12:22:00 -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: 3.62 Message-ID: <20111027192200.21914.78943.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2011 12:22:00 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-psap-callback-03.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, 27 Oct 2011 19:22:01 -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 Int= ernet Technologies Working Group of the IETF. Title : Public Safety Answering Point (PSAP) Callback Author(s) : Henning Schulzrinne Hannes Tschofenig Christer Holmberg Milan Patel Filename : draft-ietf-ecrit-psap-callback-03.txt Pages : 23 Date : 2011-10-27 After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call-taker) it is possible that the call-taker feels the need for further communication. For example, the call may have been dropped by accident without the call- taker having sufficient information about the current situation of a wounded person. A call-taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and as a consequence it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture offers capabilities to allow callbask to bypass authorization policies to reach the caller without unnecessary delays. However, the mechanism specified prior to this document supports only limited scenarios. This document discusses some shortcomings, presents additional scenarios where better-than- normal call treatment behavior would be desirable, and specifies a protocol solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-psap-callback-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-psap-callback-03.txt From hannes.tschofenig@gmx.net Thu Oct 27 22:51:54 2011 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 045BF11E8097 for ; Thu, 27 Oct 2011 22:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.532 X-Spam-Level: X-Spam-Status: No, score=-100.532 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJ4YR3w137mT for ; Thu, 27 Oct 2011 22:51:53 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1FAEB11E807F for ; Thu, 27 Oct 2011 22:51:52 -0700 (PDT) Received: (qmail invoked by alias); 28 Oct 2011 05:51:51 -0000 Received: from unknown (EHLO [10.255.131.15]) [192.100.123.77] by mail.gmx.net (mp006) with SMTP; 28 Oct 2011 07:51:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18tIfkOguQtgb4Pdu8bhUx1Qv2xtEcd/kogoSCIzS 2vK1NCspBacYuw From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Oct 2011 08:51:47 +0300 Message-Id: <92E2A016-483D-443B-808E-AA837C9B7C8A@gmx.net> To: ECRIT Org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] draft-ietf-ecrit-psap-callback-03.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: Fri, 28 Oct 2011 05:51:54 -0000 Hi all,=20 I have updated the PSAP callback document. I made the following changes:=20= * Added Christer as a co-author since he helped a lot with pushing the = solution specific discussions forward. * Deleted the solution description since the current proposal on the = table is documented in Christer's document. Once there is agreement on = the solution we will merge in there. * Improved the scenario description per discussion at the last IETF = meeting. * Added an informational section summarizing what solution approaches we = had considered and why we rejected them. This text is in the appendix.=20= * Updated the acknowledgment section. * Improved the introduction a bit.=20 Here is the updated draft:=20 = http://www.ietf.org/internet-drafts/draft-ietf-ecrit-psap-callback-03.txt Ciao Hannes From hannes.tschofenig@gmx.net Mon Oct 31 03:47:17 2011 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 B3C9021F8CCB for ; Mon, 31 Oct 2011 03:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 TFkABTgG7j7r for ; Mon, 31 Oct 2011 03:47:17 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 75AB921F8CB8 for ; Mon, 31 Oct 2011 03:47:16 -0700 (PDT) Received: (qmail invoked by alias); 31 Oct 2011 10:47:14 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.216.191] by mail.gmx.net (mp069) with SMTP; 31 Oct 2011 11:47:14 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/fUlRfuQnfTpUoCCuszbg2uahaXZIpHNbxjm9Y1P OuK496CnozIbUU From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Oct 2011 12:47:12 +0200 Message-Id: <078EA6A6-3E27-4D57-A2A3-9AB1A2728145@gmx.net> To: ECRIT Org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] Additional Call Data & VCard 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, 31 Oct 2011 10:47:17 -0000 Hi all,=20 I am currently working on the update of the additional call data draft = and I now reference the XML-based draft of vCard, as discussed on the = list. vCards are used in the XML schema.=20 Now, when I looked again at the vCard draft=20 http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-11 I noticed that they have actually defined a Relax NG schema rather than = an XML schema.=20 Including an XML schema is easy but I have not included a Relax NG = schema into an XML schema yet.=20 Does anyone have an experience in that area?=20 Ciao Hannes From br@brianrosen.net Mon Oct 31 06:39:44 2011 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 F047C21F84B8 for ; Mon, 31 Oct 2011 06:39:44 -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 Y7xTePb1PiIN for ; Mon, 31 Oct 2011 06:39:44 -0700 (PDT) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7F64A21F8468 for ; Mon, 31 Oct 2011 06:39:44 -0700 (PDT) X-ASG-Debug-ID: 1320068383-0491e5718d1b9620001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barracuda.barmail5.idig.net with ESMTP id gNAIuTCTceDtfXSn; Mon, 31 Oct 2011 06:39:43 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.129.114]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RKs5W-000DV0-Fx; Mon, 31 Oct 2011 06:39:42 -0700 X-Barracuda-BBL-IP: 209.173.53.233 X-Barracuda-RBL-IP: 209.173.53.233 Mime-Version: 1.0 (Apple Message framework v1251.1) X-ASG-Orig-Subj: Re: [Ecrit] Additional Call Data & VCard Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <078EA6A6-3E27-4D57-A2A3-9AB1A2728145@gmx.net> Date: Mon, 31 Oct 2011 09:39:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <40D1383E-E0EE-4C9E-8023-1B0A6C5C5640@brianrosen.net> References: <078EA6A6-3E27-4D57-A2A3-9AB1A2728145@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1251.1) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1320068383 X-Barracuda-URL: http://64.34.111.236:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.78920 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: ECRIT Org Subject: Re: [Ecrit] Additional Call Data & VCard 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, 31 Oct 2011 13:39:45 -0000 It's hard I understand. I asked about, and was pointed to, an unofficial XML schema for this. I = can supply it to you if you want it, but I doubt we could reference it = in an I-D or RFC. Brian On Oct 31, 2011, at 6:47 AM, Hannes Tschofenig wrote: > Hi all,=20 >=20 > I am currently working on the update of the additional call data draft = and I now reference the XML-based draft of vCard, as discussed on the = list. vCards are used in the XML schema.=20 >=20 > Now, when I looked again at the vCard draft=20 > http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-11 > I noticed that they have actually defined a Relax NG schema rather = than an XML schema.=20 >=20 > Including an XML schema is easy but I have not included a Relax NG = schema into an XML schema yet.=20 > Does anyone have an experience in that area?=20 >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From internet-drafts@ietf.org Mon Oct 31 13:05:05 2011 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 05DE711E81ED; Mon, 31 Oct 2011 13:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 fUAS+VuCJFLO; Mon, 31 Oct 2011 13:05:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478B811E81D8; Mon, 31 Oct 2011 13:05:04 -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: 3.62 Message-ID: <20111031200504.31485.3043.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 13:05:04 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-lost-sync-13.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: Mon, 31 Oct 2011 20:05:05 -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 Int= ernet Technologies Working Group of the IETF. Title : Synchronizing Location-to-Service Translation (LoST) Pro= tocol based Service Boundaries and Mapping Elements Author(s) : Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-ecrit-lost-sync-13.txt Pages : 29 Date : 2011-10-31 The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the <mapping> element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative <mapping> elements between two entities. Exchanging cached <mapping> elements, i.e. non-authoritative elements, is possible but not envisioned. In any case, this document can also be used without the LoST protocol even though the format of the <mapping> element is re-used from the LoST specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-13.txt From internet-drafts@ietf.org Mon Oct 31 13:08:24 2011 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 BCEDE11E81FB; Mon, 31 Oct 2011 13:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 5QeLJQS8jlsa; Mon, 31 Oct 2011 13:08:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A9511E81F3; Mon, 31 Oct 2011 13:08:22 -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: 3.62 Message-ID: <20111031200822.1841.43836.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 13:08:22 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-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: Mon, 31 Oct 2011 20:08:24 -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 Int= ernet Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Filename : draft-ietf-ecrit-additional-data-02.txt Pages : 41 Date : 2011-10-31 When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any service provider in the path of the call, or access network may have information about the call which the PSAP may be able to use. This document describes an XML data structure that contains this kind of information in a standardized form. A Uniform Resource Identifier (URI) that points to the structure can be included in the SIP signaling with the call, or the data may be included in the body of a SIP message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-additional-data-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-additional-data-02.txt