From patrick.paling@skype.net Thu Jul 28 03:47:29 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 1C82321F8C06 for ; Thu, 28 Jul 2011 03:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4rOaNXICG+m for ; Thu, 28 Jul 2011 03:47:28 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id ADB8621F8C01 for ; Thu, 28 Jul 2011 03:47:27 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id AF63016FF; Thu, 28 Jul 2011 12:47:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=from:to :references:in-reply-to:subject:date:message-id:mime-version: content-type; s=mx; bh=uj4f0C9GNZeOXBw49I94t+u9xEY=; b=O8ouAmS8w r5zACQ1BapWR+eJc2v3sWvzcZAfOHsH557g6wd4xE4B6U5AtVesKXk9NCtTpxhYk e5QwB4UiZKSAKOFKsi1mJGYayntwkjayxZ9LPyMCTd77Ra0ps+w0NA79IL7MO/3Y hd6SxYQ+zghYzH0iYY+CfUj4S1IzX4eids= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type; q=dns; s=mx; b=cbqEt5ijS48+bZXLgVL7/4K250INBnvUiFL4CnHG+hySzS7e y84/C3JBG1MFgB/RJ3RDo7x3xu8JmJSGNfkWhmJsPH6zT81+eOgwJQQe6U1aFEpx Di3MnuCqYWqQ6MFjkeM8dWk+h93KhjLfMRISCRNFGn7pcVOluXnyJJpN0V4= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id ACBDB16E2; Thu, 28 Jul 2011 12:47:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 8DE753507FD4; Thu, 28 Jul 2011 12:47:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+HsigemZ5J6; Thu, 28 Jul 2011 12:47:24 +0200 (CEST) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id 1D05F3507FBE; Thu, 28 Jul 2011 12:47:24 +0200 (CEST) From: "Paling, Patrick" To: , References: <049001cc4ce8$43c26a00$cb473e00$@considine@skype.net> <4E3109A1.2000201@skype.net> In-Reply-To: <4E3109A1.2000201@skype.net> Date: Thu, 28 Jul 2011 12:47:24 +0200 (CEST) Message-ID: <006f01cc4d13$bed77390$3c865ab0$@paling@skype.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0070_01CC4D2C.E424D2A0" X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraConnectorForOutlook/6.0.6058.8) Thread-Index: AcxM9GNiTJeFewjiQJOo5herltsLaQAHKtgA Content-Language: et X-Originating-IP: [194.126.108.2] X-Mailman-Approved-At: Tue, 02 Aug 2011 08:10:12 -0700 Subject: Re: [Ecrit] FW: SWATting 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, 28 Jul 2011 10:56:43 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0070_01CC4D2C.E424D2A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hello, Would be intrested in finding out more on this Swatting issue. If there are Skype users someway making nuisance calls then we can try to help out in blocking these calls, if we recieve relevant info about this. We usually recieve reports of Skype Onlinenumbers reported to us through Level 3, and these numbers are associated with somekind of scams. With prank calls, we normally ask which number has been recieveing these calls , also date and time of these calls, additionally if there is any other information about the caller that the prankcall receiver knows of. And feel free to loop in your contact person from Level 3 aswell. Thanks! Best regards, Patrick Paling Fraud Investigator | Skype Email: patrick.paling@skype.net Skype Name: patrick16paling ------------------------------------------------------------------------------------------- From: "Delaine Arnold ENP" Date: July 26, 2011 8:50:31 PM EDT To: Subject: Re: [Ecrit] SWATting I was on a NENA conference call earlier today and a gentleman from Montgomery County, PA, was telling us about some major SKYPE phone swatting issues going on across the US. PSAPs are being called, linked together and then loud party noises and music are being played. If the calltaker hangs up, within 2-3 minutes they get another call with the same noise - it ties up their lines. They have finally assigned one calltaker to just answer these and let them play themselves out. They have been working with Level 3 who supposedly provides the IP service for SKYPE. If you need more information, I can provide the person's name and contact info. Thank you, Delaine --------------------------------------- Delaine M. Arnold, ENP Chair, NENA Data Technical Committee Voice: 813-960-1698 Cell: 813-928-1692 Email: dmarnold@verizon.net -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Thomson, Martin Sent: Tuesday, July 26, 2011 3:37 PM To: Henning Schulzrinne; Richard L. Barnes Cc: ecrit@ietf.org Org Subject: Re: [Ecrit] SWATting On 2011-07-26 at 14:12:30, Henning Schulzrinne wrote: You would also have to provide a fake credit card, as I suspect none of the E911 interconnected VoIP providers provide free service. Plus, you'd probably also would need to use a non-traceable IP address, such as a coffee shop WiFi AP. It is possible to buy a pre-paid credit card with which to purchase a service. Such a card is indistinguishable from the real thing, but it requires no authentication. For something like this, it would depend on whether the name on the card matters to the service, but I suspect that it would not to many. Capacity to pay tends to be the primary characteristic that is sought by operators. --Martin _______________________________________________ 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 ------=_NextPart_000_0070_01CC4D2C.E424D2A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello,

 

Would be intrested in finding out more on this Swatting issue. If = there are Skype users someway making nuisance calls then we can try to = help out in blocking these calls, if we recieve relevant info about = this. We usually recieve reports of Skype Onlinenumbers =C2=A0reported = to us through Level 3, and these numbers are associated with somekind of = scams.

With prank calls, we normally ask which number =C2=A0has been = recieveing these calls , also date and time of these calls, additionally = if there is any other information about the caller that the prankcall = receiver knows of.

And feel free to loop in your contact person from Level 3 = aswell.

 

Thanks!

 

Best regards,

Patrick Paling

 

Fraud Investigator | Skype

Email: patrick.paling@skype.net

Skype Name: patrick16paling

 

 

-------------------------------------------------= ------------------------------------------

 

From: "Delaine Arnold ENP" <dmarnold@verizon.net>

Date: July 26, 2011 8:50:31 PM = EDT

To: = <ecrit@ietf.org>

Subject: Re: [Ecrit] = SWATting

 

I = was on a NENA conference call earlier today and a gentleman = from

Montgomery County, PA, was telling us about some major = SKYPE phone

swatting

issues going on across the US.  PSAPs are being = called, linked = together

and

then = loud party noises and music are being played.  If the = calltaker

hangs

up, = within 2-3 minutes they get another call with the same noise - = it

ties

up = their lines.  They have finally assigned one calltaker to just = answer

these and let them play themselves out.  They = have been working = with

Level = 3

who = supposedly provides the IP service for SKYPE.  If you need = more

information, I can provide the person's name and = contact info.

 

Thank = you,

Delaine

---------------------------------------

<= /blockquote>

Delaine M. Arnold, = ENP

Chair, NENA Data Technical = Committee

Voice: =  813-960-1698

Cell: =     813-928-1692

Email:  dmarnold@verizon.net<= /p>

 

-----Original = Message-----

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]= On Behalf

Of

Thomson, = Martin

Sent: Tuesday, July 26, 2011 3:37 = PM

To: = Henning Schulzrinne; Richard L. = Barnes

Cc: = ecrit@ietf.org = Org

Subject: Re: [Ecrit] = SWATting

 

On = 2011-07-26 at 14:12:30, Henning Schulzrinne = wrote:

You = would also have to provide a fake credit card, as I suspect = none

of = the E911 interconnected VoIP providers provide free service. = Plus,

you'd probably also would need to use a non-traceable = IP address, = such

as a = coffee shop WiFi = AP.

 

It = is possible to buy a pre-paid credit card with which to purchase = a

service.  Such a card is indistinguishable from = the real thing, but = it

requires no = authentication.

 

For = something like this, it would depend on whether the name on the = card

matters to the service, but I suspect that it would = not to many.

Capacity

to = pay tends to be the primary characteristic that is sought = by

operators.

 

--Martin

_______________________________________________

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

 

 

------=_NextPart_000_0070_01CC4D2C.E424D2A0-- From christer.holmberg@ericsson.com Thu Aug 4 03:41: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 8085721F8B6F for ; Thu, 4 Aug 2011 03:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYJ5f+CozNSd for ; Thu, 4 Aug 2011 03:41:43 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5918721F8B65 for ; Thu, 4 Aug 2011 03:41:43 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f3-4e3a7774b1f5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 16.A6.20773.4777A3E4; Thu, 4 Aug 2011 12:41:56 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 4 Aug 2011 12:41:55 +0200 From: Christer Holmberg To: Mary Barnes , Hannes Tschofenig Date: Thu, 4 Aug 2011 12:41:55 +0200 Thread-Topic: [Ecrit] PSAP Callback Informal Meeting, Tuesday, 17:10 Thread-Index: AcxNVy7sGFyASLcyRLeVPjEj84+hWwAmrxCq Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6190FEC@ESESSCMS0356.eemea.ericsson.se> References: <9C045A2C-2B23-415C-A5D7-BFF5A779611B@gmx.net> <55FE70DF-CBDD-4672-9EE6-2D392D60FE9B@bbn.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] PSAP Callback Informal Meeting, Tuesday, 17:10 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, 04 Aug 2011 10:41:44 -0000 Hi Mary, It is sad that the meetings were held at the same time, but it was very dif= ficult to find another time. However, I think we had very good discussions, and made progress, at the in= formal meeting, which in my opinion at least from a 3GPP/IETF co-operation = perspective is important. Also, not "all" 3GPP people were at the informal meeting. I am aware of at = least a couple of delegates who did participate in the RAI meeting :) Regards, Christer ________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Mary Bar= nes [mary.ietf.barnes@gmail.com] Sent: Thursday, July 28, 2011 9:50 PM To: Hannes Tschofenig Cc: ecrit@ietf.org Org Subject: Re: [Ecrit] PSAP Callback Informal Meeting, Tuesday, 17:10 And, it was a really bad idea to schedule this during the RAI area meeting.= In particular, since all the 3GPP people were at this meeting and not at = the RAI area meeting. I would have thought that they had some feedback on h= ow the process is working. Mary. On Thu, Jul 28, 2011 at 9:06 AM, Richard L. Barnes > wrote: > The following persons attended our informal gathering: > - Christer Holmberg > - Marc Linsner > - Richard Barnes For the record, I did not attend this meeting. Not sure how I ended up on = the list... --Richard _______________________________________________ Ecrit mailing list https://www.ietf.org/mailman/listinfo/ecrit From rjsparks@nostrum.com Thu Aug 4 12:12:07 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 91A6A21F87F0; Thu, 4 Aug 2011 12:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OARj2LQOCc5; Thu, 4 Aug 2011 12:12:06 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A49DA21F88B7; Thu, 4 Aug 2011 12:12:05 -0700 (PDT) Received: from [192.168.2.105] (pool-173-71-50-10.dllstx.fios.verizon.net [173.71.50.10]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p74JCJPi082324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2011 14:12:20 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: multipart/alternative; boundary=Apple-Mail-21--829509233 Date: Thu, 4 Aug 2011 14:12:19 -0500 Message-Id: <1220336F-08F3-4B50-A1A8-5AF28944BF8C@nostrum.com> To: ecrit@ietf.org, GEOPRIV Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 173.71.50.10 is authenticated by a trusted mechanism) Subject: [Ecrit] Verifying errata 2511 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:12:07 -0000 --Apple-Mail-21--829509233 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (note the crosspost - please reply only to ecrit@ietf.org) Please see and thread on the Ecrit list titled Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service = Translation Protocol) which started Nov 23, 2010. Given the subsequent discussion of draft-ietf-geopriv-local-civic, I = plan to mark this errata as Verified. If you don't think this is the correct thing to do, please let = me know ASAP. If there are no replies, I will verify that errata next Thursday (11Aug)= --Apple-Mail-21--829509233 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
(note the crosspost - please reply only to ecrit@ietf.org)

Please see <http://www.rfc-editor.org/errata_search.php?eid=2511>
and thread on the Ecrit list titled

Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service Translation Protocol)

which started Nov 23, 2010.

Given the subsequent discussion of draft-ietf-geopriv-local-civic, I plan to mark this errata as
Verified. If you don't think this is the correct thing to do, please let me know ASAP. If there are no
replies, I will verify that errata next Thursday (11Aug)
--Apple-Mail-21--829509233-- From ted.ietf@gmail.com Thu Aug 4 15:28:37 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 4F98522800E for ; Thu, 4 Aug 2011 15:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6p-bULfe4BO for ; Thu, 4 Aug 2011 15:28:36 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B16B222800D for ; Thu, 4 Aug 2011 15:28:36 -0700 (PDT) Received: by gxk19 with SMTP id 19so1570744gxk.31 for ; Thu, 04 Aug 2011 15:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1iD2FxazsMw7whnBfYWnt/UdMzrrUqB3AfLWHG+Dst4=; b=V/bn9+BVKHhw1Rjtua0NkjuL75Wm80nkh4bPIpXuAB69ZyL3H0gCMak9IZD2hIwHKp ob3ywg/qpxpDhqOWUCHX/QnB7A0AARuR/jbTQDgq782NpCMo/Xj3xS6Dx53dahp3YZPG atmpDEN+zjL7mTI+UWHHnlscNdFhscgyJ+2vM= MIME-Version: 1.0 Received: by 10.236.190.42 with SMTP id d30mr1972026yhn.258.1312496931547; Thu, 04 Aug 2011 15:28:51 -0700 (PDT) Received: by 10.236.109.39 with HTTP; Thu, 4 Aug 2011 15:28:51 -0700 (PDT) In-Reply-To: <1220336F-08F3-4B50-A1A8-5AF28944BF8C@nostrum.com> References: <1220336F-08F3-4B50-A1A8-5AF28944BF8C@nostrum.com> Date: Thu, 4 Aug 2011 15:28:51 -0700 Message-ID: From: Ted Hardie To: rjsparks@nostrum.com Content-Type: text/plain; charset=ISO-8859-1 Cc: ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Verifying errata 2511 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, 04 Aug 2011 22:28:37 -0000 I don't think this is needed. If you look at the full response, you'll see that this namespace is declared in reference to the civicAddress in both the query and response: DE Bavaria Munich 81675 The location ID is present in both as well, so I don't think there should be much confusion about how the location validation response elements are to be interepreted. They are specific to a location, which already has a namespace attached. It may be that further text is required to make that even more clear, but I don't think adding a namespace within the locationValidation response itself is needed. regards, Ted On Thu, Aug 4, 2011 at 12:12 PM, Robert Sparks wrote: > (note the crosspost - please reply only to ecrit@ietf.org) > Please see > and thread on the Ecrit list titled > > Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service > Translation Protocol) > > which started Nov 23, 2010. > Given the subsequent discussion of draft-ietf-geopriv-local-civic, I plan to > mark this errata as > Verified. If you don't think this is the correct thing to do, please let me > know ASAP. If there are no > replies, I will verify that errata next Thursday (11Aug) > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > > From rbarnes@bbn.com Thu Aug 4 17:15:22 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 0C98711E808D for ; Thu, 4 Aug 2011 17:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkBbzc0Qq6pt for ; Thu, 4 Aug 2011 17:15:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 98E5F11E807C for ; Thu, 4 Aug 2011 17:15:20 -0700 (PDT) Received: from [128.89.254.134] (port=58212 helo=[192.168.1.14]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qp84c-000GTw-Kg; Thu, 04 Aug 2011 20:15:35 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 4 Aug 2011 20:15:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1220336F-08F3-4B50-A1A8-5AF28944BF8C@nostrum.com> To: Ted Hardie X-Mailer: Apple Mail (2.1082) Cc: ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Verifying errata 2511 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, 05 Aug 2011 00:15:22 -0000 The confusion arises when you have civic address elements that originate = from multiple namespaces, as in draft-ietf-geopriv-local-civic: UK Devon Monkokehampton Deckport Cross 21451338 On Aug 4, 2011, at 6:28 PM, Ted Hardie wrote: > I don't think this is needed. If you look at the full response, > you'll see that this namespace is declared in reference to the > civicAddress in both the query and response: >=20 > xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> > DE > Bavaria > Munich > 81675 > >=20 > The location ID is present in both as well, so I don't think there > should be much confusion about how the location validation response > elements are to be interepreted. They are specific to a location, > which already has a namespace attached. >=20 > It may be that further text is required to make that even more clear, > but I don't think adding a namespace within the locationValidation > response itself is needed. >=20 > regards, >=20 > Ted >=20 >=20 >=20 > On Thu, Aug 4, 2011 at 12:12 PM, Robert Sparks = wrote: >> (note the crosspost - please reply only to ecrit@ietf.org) >> Please see >> and thread on the Ecrit list titled >>=20 >> Erratum report on erratum 2511 to RFC 5222 (LoST: A = Location-to-Service >> Translation Protocol) >>=20 >> which started Nov 23, 2010. >> Given the subsequent discussion of draft-ietf-geopriv-local-civic, I = plan to >> mark this errata as >> Verified. If you don't think this is the correct thing to do, please = let me >> know ASAP. If there are no >> replies, I will verify that errata next Thursday (11Aug) >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv >>=20 >>=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From ted.ietf@gmail.com Fri Aug 5 14:56:11 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 0AA2721F8B4F for ; Fri, 5 Aug 2011 14:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+7FGfdLB8rG for ; Fri, 5 Aug 2011 14:56:10 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 15E4B21F8B37 for ; Fri, 5 Aug 2011 14:56:10 -0700 (PDT) Received: by yie12 with SMTP id 12so347495yie.31 for ; Fri, 05 Aug 2011 14:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2ZNP42o3vGuIbzMBE7hOGINrEFkMUfQ1mUStrEf+mg0=; b=aiEx99RGBMbp2ObvDbB6YjMtyJVRM5O14yB7V2loixPIh6/gMXIc5uEp/TnN91oB+d b8SvCsu98fT0mtWGZFfgiqr158koxJUNaZNttq+a6rsUIzkqnYRjEXq3iymQ+id6vKkP LcQda2mSj7z2gbAUdSRtC5ml29W0jMkeFokDU= MIME-Version: 1.0 Received: by 10.236.76.201 with SMTP id b49mr3280564yhe.526.1312581386853; Fri, 05 Aug 2011 14:56:26 -0700 (PDT) Received: by 10.236.109.39 with HTTP; Fri, 5 Aug 2011 14:56:26 -0700 (PDT) In-Reply-To: References: <1220336F-08F3-4B50-A1A8-5AF28944BF8C@nostrum.com> Date: Fri, 5 Aug 2011 14:56:26 -0700 Message-ID: From: Ted Hardie To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Verifying errata 2511 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, 05 Aug 2011 21:56:11 -0000 Howdy Richard, Your example is definitely better than the text in the erratum, but I still don't think this is an erratum for RFC 5222. RFC 5222 says: The element enumerates those civic address elements that have been recognized as valid by the LoST server and that have been used to determine the mapping. The elements enumerates the civic address elements that the server did not check and that were not used in determining the response. The element enumerate civic address elements that the server attempted to check, but that did not match the other civic address elements found in the list. Civic location tokens that are not listed in either the , or element belong to the class of unchecked tokens. In the examples used in RFC 5222, there was only one namespace, so there was no need for a disambiguation prefix for the elements. Even in your example, the disambiguation occurs with a prefix only on one of the two namespaces; the erratum appears to suggest it is required even when there is a single namespace. I don't think it is. A better approach here, at least in my opinion, would be to add a locationValidation example to draft-ietf-geopriv-local-civic, to show how it works when there are multiple namespaces. I don't think that would require the draft to update RFC 5222--it's just an example, not a substantive change (again, just my opinion). It's also far more likely to be seen there than in an erraturm. Ted On Thu, Aug 4, 2011 at 5:15 PM, Richard L. Barnes wrote: > The confusion arises when you have civic address elements that originate = from multiple namespaces, as in draft-ietf-geopriv-local-civic: > > =A0 =A0 xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" > =A0 =A0 xmlns:cdc=3D"http://devon.canals.org.uk/civic"> > =A0 UK > =A0 Devon > =A0 Monkokehampton > =A0 Deckport > =A0 Cross > > =A0 21451338 > > > > > On Aug 4, 2011, at 6:28 PM, Ted Hardie wrote: > >> I don't think this is needed. =A0If you look at the full response, >> you'll see that this namespace is declared in reference to the >> civicAddress in both the query and response: >> >> > =A0 =A0 =A0 =A0 =A0 xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civic= Addr"> >> =A0 =A0 =A0 =A0 =A0 DE >> =A0 =A0 =A0 =A0 =A0 Bavaria >> =A0 =A0 =A0 =A0 =A0 Munich >> =A0 =A0 =A0 =A0 =A0 81675 >> =A0 =A0 =A0 =A0 >> >> The location ID is present in both as well, so I don't think there >> should be much confusion about how the location validation response >> elements are to be interepreted. =A0They are specific to a location, >> which already has a namespace attached. >> >> It may be that further text is required to make that even more clear, >> but I don't think adding a namespace within the locationValidation >> response itself is needed. >> >> regards, >> >> Ted >> >> >> >> On Thu, Aug 4, 2011 at 12:12 PM, Robert Sparks wr= ote: >>> (note the crosspost - please reply only to ecrit@ietf.org) >>> Please see >>> and thread on the Ecrit list titled >>> >>> Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service >>> Translation Protocol) >>> >>> which started Nov 23, 2010. >>> Given the subsequent discussion of draft-ietf-geopriv-local-civic, I pl= an to >>> mark this errata as >>> Verified. If you don't think this is the correct thing to do, please le= t me >>> know ASAP. If there are no >>> replies, I will verify that errata next Thursday (11Aug) >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www.ietf.org/mailman/listinfo/geopriv >>> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From brian.rosen@neustar.biz Fri Aug 5 15:05:43 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 0202221F8B00 for ; Fri, 5 Aug 2011 15:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.385 X-Spam-Level: X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-fb4WTLfl+b for ; Fri, 5 Aug 2011 15:05:42 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id DACE321F8AFE for ; Fri, 5 Aug 2011 15:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1312581953; x=1627924273; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=f/BH/0Ngl4Nkkq/No8B2l zOpD2TVMUQd1O96BcRNyvE=; b=STEjCerbLhKZe5maLkND+nAh1vfG3N7YNxi0P ckhjZ661+WFc+ay3j9iiTkUXplxZZkz7UnthCgopL9ZSECaTQ== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.25548902; Fri, 05 Aug 2011 18:05:52 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 5 Aug 2011 18:05:52 -0400 From: "Rosen, Brian" To: Ted Hardie Date: Fri, 5 Aug 2011 18:05:51 -0400 Thread-Topic: [Ecrit] [Geopriv] Verifying errata 2511 Thread-Index: AcxTu9bYjd06NuokT8iozbMsGl/VwQ== Message-ID: References: <1220336F-08F3-4B50-A1A8-5AF28944BF8C@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [Geopriv] Verifying errata 2511 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, 05 Aug 2011 22:05:43 -0000 Also, there are implementations that do it the way the text currently illus= trates, and it works, so this would require them to change, for little gain= . While I would have preferred that we handled this better in 5222, I'm with = Ted here. Brian On Aug 5, 2011, at 5:56 PM, Ted Hardie wrote: > Howdy Richard, >=20 > Your example is definitely better than the text in the erratum, but I > still don't think this is an erratum for RFC 5222. >=20 > RFC 5222 says: >=20 > The element enumerates those civic address elements that have > been recognized as valid by the LoST server and that have been used to > determine the mapping. The elements enumerates the civic > address elements that the server did not check and that were not used > in determining the response. The element enumerate civic > address elements that the server attempted to check, but that did not > match the other civic address elements found in the list. > Civic location tokens that are not listed in either the > , or element belong to the class of unchecked > tokens. >=20 > In the examples used in RFC 5222, there was only one namespace, so > there was no need for a disambiguation prefix for the elements. Even > in your example, the disambiguation occurs with a prefix only on one > of the two namespaces; the erratum appears to suggest it is required > even when there is a single namespace. I don't think it is. >=20 > A better approach here, at least in my opinion, would be to add a > locationValidation example to draft-ietf-geopriv-local-civic, to show > how it works when there are multiple namespaces. I don't think that > would require the draft to update RFC 5222--it's just an example, not > a substantive change (again, just my opinion). It's also far more > likely to be seen there than in an erraturm. >=20 > Ted >=20 >=20 > On Thu, Aug 4, 2011 at 5:15 PM, Richard L. Barnes wrote= : >> The confusion arises when you have civic address elements that originate= from multiple namespaces, as in draft-ietf-geopriv-local-civic: >>=20 >> > xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" >> xmlns:cdc=3D"http://devon.canals.org.uk/civic"> >> UK >> Devon >> Monkokehampton >> Deckport >> Cross >>=20 >> 21451338 >>=20 >> >>=20 >>=20 >> On Aug 4, 2011, at 6:28 PM, Ted Hardie wrote: >>=20 >>> I don't think this is needed. If you look at the full response, >>> you'll see that this namespace is declared in reference to the >>> civicAddress in both the query and response: >>>=20 >>> >> xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> >>> DE >>> Bavaria >>> Munich >>> 81675 >>> >>>=20 >>> The location ID is present in both as well, so I don't think there >>> should be much confusion about how the location validation response >>> elements are to be interepreted. They are specific to a location, >>> which already has a namespace attached. >>>=20 >>> It may be that further text is required to make that even more clear, >>> but I don't think adding a namespace within the locationValidation >>> response itself is needed. >>>=20 >>> regards, >>>=20 >>> Ted >>>=20 >>>=20 >>>=20 >>> On Thu, Aug 4, 2011 at 12:12 PM, Robert Sparks w= rote: >>>> (note the crosspost - please reply only to ecrit@ietf.org) >>>> Please see >>>> and thread on the Ecrit list titled >>>>=20 >>>> Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Servic= e >>>> Translation Protocol) >>>>=20 >>>> which started Nov 23, 2010. >>>> Given the subsequent discussion of draft-ietf-geopriv-local-civic, I p= lan to >>>> mark this errata as >>>> Verified. If you don't think this is the correct thing to do, please l= et me >>>> know ASAP. If there are no >>>> replies, I will verify that errata next Thursday (11Aug) >>>> _______________________________________________ >>>> Geopriv mailing list >>>> Geopriv@ietf.org >>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>=20 >>>>=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 From James.Winterbottom@commscope.com Fri Aug 5 15:18:41 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 8CFFE21F8B67 for ; Fri, 5 Aug 2011 15:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQbdyHY9G9ag for ; Fri, 5 Aug 2011 15:18:40 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id EA54021F8AD1 for ; Fri, 5 Aug 2011 15:18:39 -0700 (PDT) X-AuditID: 0a0404e9-b7b99ae000002f72-ae-4e3c6c57046a Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id B0.7E.12146.75C6C3E4; Fri, 5 Aug 2011 17:19:03 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 5 Aug 2011 17:18:53 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Sat, 6 Aug 2011 06:18:50 +0800 From: "Winterbottom, James" To: Ted Hardie , "Richard L. Barnes" Date: Sat, 6 Aug 2011 06:18:50 +0800 Thread-Topic: [Ecrit] [Geopriv] Verifying errata 2511 Thread-Index: AcxTuoxaQmbWgT5CTEi/+3KiVv5zkwAAQqdQ Message-ID: <5A55A45AE77F5941B18E5457ECAC818801210D7B0763@SISPE7MB1.commscope.com> References: <1220336F-08F3-4B50-A1A8-5AF28944BF8C@nostrum.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: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [Geopriv] Verifying errata 2511 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, 05 Aug 2011 22:18:41 -0000 I don't think that local-civic needs to update RFC5222, but I don't think t= hat the examples in RFC5222 are correct either when it comes to the token s= hown in the validation examples. The schema clearly calls for a qualified n= ame list, and the tokens in the examples are not suitably qualified.=20 I don't think that it hurts to have an annex in local-civic that shows what= a LoST query and validation response might look like, I would like to hear= if anybody else is okay with approach before we update local-civic though = since we have agreement to call a WGLC once the document is updated with th= e registry consensus. Cheers James ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Ted Hard= ie [ted.ietf@gmail.com] Sent: Friday, August 05, 2011 4:56 PM To: Richard L. Barnes Cc: ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Verifying errata 2511 Howdy Richard, Your example is definitely better than the text in the erratum, but I still don't think this is an erratum for RFC 5222. RFC 5222 says: The element enumerates those civic address elements that have been recognized as valid by the LoST server and that have been used to determine the mapping. The elements enumerates the civic address elements that the server did not check and that were not used in determining the response. The element enumerate civic address elements that the server attempted to check, but that did not match the other civic address elements found in the list. Civic location tokens that are not listed in either the , or element belong to the class of unchecked tokens. In the examples used in RFC 5222, there was only one namespace, so there was no need for a disambiguation prefix for the elements. Even in your example, the disambiguation occurs with a prefix only on one of the two namespaces; the erratum appears to suggest it is required even when there is a single namespace. I don't think it is. A better approach here, at least in my opinion, would be to add a locationValidation example to draft-ietf-geopriv-local-civic, to show how it works when there are multiple namespaces. I don't think that would require the draft to update RFC 5222--it's just an example, not a substantive change (again, just my opinion). It's also far more likely to be seen there than in an erraturm. Ted On Thu, Aug 4, 2011 at 5:15 PM, Richard L. Barnes wrote: > The confusion arises when you have civic address elements that originate = from multiple namespaces, as in draft-ietf-geopriv-local-civic: > > xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" > xmlns:cdc=3D"http://devon.canals.org.uk/civic"> > UK > Devon > Monkokehampton > Deckport > Cross > > 21451338 > > > > > On Aug 4, 2011, at 6:28 PM, Ted Hardie wrote: > >> I don't think this is needed. If you look at the full response, >> you'll see that this namespace is declared in reference to the >> civicAddress in both the query and response: >> >> > xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> >> DE >> Bavaria >> Munich >> 81675 >> >> >> The location ID is present in both as well, so I don't think there >> should be much confusion about how the location validation response >> elements are to be interepreted. They are specific to a location, >> which already has a namespace attached. >> >> It may be that further text is required to make that even more clear, >> but I don't think adding a namespace within the locationValidation >> response itself is needed. >> >> regards, >> >> Ted >> >> >> >> On Thu, Aug 4, 2011 at 12:12 PM, Robert Sparks wr= ote: >>> (note the crosspost - please reply only to ecrit@ietf.org) >>> Please see >>> and thread on the Ecrit list titled >>> >>> Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service >>> Translation Protocol) >>> >>> which started Nov 23, 2010. >>> Given the subsequent discussion of draft-ietf-geopriv-local-civic, I pl= an to >>> mark this errata as >>> Verified. If you don't think this is the correct thing to do, please le= t me >>> know ASAP. If there are no >>> replies, I will verify that errata next Thursday (11Aug) >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www.ietf.org/mailman/listinfo/geopriv >>> >>> >> _______________________________________________ >> 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 James.Winterbottom@commscope.com Fri Aug 5 15:22:57 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 5E7A721F8745 for ; Fri, 5 Aug 2011 15:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUO56w0W5UG6 for ; Fri, 5 Aug 2011 15:22:56 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 60CB221F86BD for ; Fri, 5 Aug 2011 15:22:56 -0700 (PDT) X-AuditID: 0a0404e9-b7b99ae000002f72-27-4e3c6d5c8095 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 32.8E.12146.C5D6C3E4; Fri, 5 Aug 2011 17:23:24 -0500 (CDT) Received: from CDCE10HC2.commscope.com (10.86.28.22) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 5 Aug 2011 17:23:13 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 5 Aug 2011 17:23:13 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sat, 6 Aug 2011 06:23:09 +0800 From: "Winterbottom, James" To: "Rosen, Brian" , Ted Hardie Date: Sat, 6 Aug 2011 06:21:09 +0800 Thread-Topic: [Ecrit] [Geopriv] Verifying errata 2511 Thread-Index: AcxTu9bYjd06NuokT8iozbMsGl/VwQAAiK3t Message-ID: <5A55A45AE77F5941B18E5457ECAC818801210D7B0764@SISPE7MB1.commscope.com> References: <1220336F-08F3-4B50-A1A8-5AF28944BF8C@nostrum.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: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [Geopriv] Verifying errata 2511 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, 05 Aug 2011 22:22:57 -0000 This just highlights the fact that we need to errata the examples because p= eople are implementing from non-normative examples rather than from normati= ve schema.=20 ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Rosen, B= rian [Brian.Rosen@neustar.biz] Sent: Friday, August 05, 2011 5:05 PM To: Ted Hardie Cc: ecrit@ietf.org Subject: Re: [Ecrit] [Geopriv] Verifying errata 2511 Also, there are implementations that do it the way the text currently illus= trates, and it works, so this would require them to change, for little gain= . While I would have preferred that we handled this better in 5222, I'm with = Ted here. Brian On Aug 5, 2011, at 5:56 PM, Ted Hardie wrote: > Howdy Richard, > > Your example is definitely better than the text in the erratum, but I > still don't think this is an erratum for RFC 5222. > > RFC 5222 says: > > The element enumerates those civic address elements that have > been recognized as valid by the LoST server and that have been used to > determine the mapping. The elements enumerates the civic > address elements that the server did not check and that were not used > in determining the response. The element enumerate civic > address elements that the server attempted to check, but that did not > match the other civic address elements found in the list. > Civic location tokens that are not listed in either the > , or element belong to the class of unchecked > tokens. > > In the examples used in RFC 5222, there was only one namespace, so > there was no need for a disambiguation prefix for the elements. Even > in your example, the disambiguation occurs with a prefix only on one > of the two namespaces; the erratum appears to suggest it is required > even when there is a single namespace. I don't think it is. > > A better approach here, at least in my opinion, would be to add a > locationValidation example to draft-ietf-geopriv-local-civic, to show > how it works when there are multiple namespaces. I don't think that > would require the draft to update RFC 5222--it's just an example, not > a substantive change (again, just my opinion). It's also far more > likely to be seen there than in an erraturm. > > Ted > > > On Thu, Aug 4, 2011 at 5:15 PM, Richard L. Barnes wrote= : >> The confusion arises when you have civic address elements that originate= from multiple namespaces, as in draft-ietf-geopriv-local-civic: >> >> > xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" >> xmlns:cdc=3D"http://devon.canals.org.uk/civic"> >> UK >> Devon >> Monkokehampton >> Deckport >> Cross >> >> 21451338 >> >> >> >> >> On Aug 4, 2011, at 6:28 PM, Ted Hardie wrote: >> >>> I don't think this is needed. If you look at the full response, >>> you'll see that this namespace is declared in reference to the >>> civicAddress in both the query and response: >>> >>> >> xmlns=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> >>> DE >>> Bavaria >>> Munich >>> 81675 >>> >>> >>> The location ID is present in both as well, so I don't think there >>> should be much confusion about how the location validation response >>> elements are to be interepreted. They are specific to a location, >>> which already has a namespace attached. >>> >>> It may be that further text is required to make that even more clear, >>> but I don't think adding a namespace within the locationValidation >>> response itself is needed. >>> >>> regards, >>> >>> Ted >>> >>> >>> >>> On Thu, Aug 4, 2011 at 12:12 PM, Robert Sparks w= rote: >>>> (note the crosspost - please reply only to ecrit@ietf.org) >>>> Please see >>>> and thread on the Ecrit list titled >>>> >>>> Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Servic= e >>>> Translation Protocol) >>>> >>>> which started Nov 23, 2010. >>>> Given the subsequent discussion of draft-ietf-geopriv-local-civic, I p= lan to >>>> mark this errata as >>>> Verified. If you don't think this is the correct thing to do, please l= et me >>>> know ASAP. If there are no >>>> replies, I will verify that errata next Thursday (11Aug) >>>> _______________________________________________ >>>> Geopriv mailing list >>>> Geopriv@ietf.org >>>> https://www.ietf.org/mailman/listinfo/geopriv >>>> >>>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From Martin.Thomson@commscope.com Sun Aug 7 17:22:19 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 EA9C921F8548 for ; Sun, 7 Aug 2011 17:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 WHj88Hwumd8f for ; Sun, 7 Aug 2011 17:22:15 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 599C121F86C3 for ; Sun, 7 Aug 2011 17:22:09 -0700 (PDT) X-AuditID: 0a0404e8-b7cb4ae000004e51-28-4e3f2c5212d3 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 0E.E9.20049.25C2F3E4; Sun, 7 Aug 2011 19:22:42 -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.159.2; Sun, 7 Aug 2011 19:22:29 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 8 Aug 2011 08:22:26 +0800 From: "Thomson, Martin" To: Ted Hardie , "Richard L. Barnes" Date: Mon, 8 Aug 2011 08:22:24 +0800 Thread-Topic: [Ecrit] [Geopriv] Verifying errata 2511 Thread-Index: AcxTuovT5OV9EYWVQRGh4cVaViy5pABpGzEg Message-ID: <8B0A9FCBB9832F43971E38010638454F040D45BACF@SISPE7MB1.commscope.com> References: <1220336F-08F3-4B50-A1A8-5AF28944BF8C@nostrum.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: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [Geopriv] Verifying errata 2511 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, 08 Aug 2011 00:22:20 -0000 On 2011-08-06 at 07:56:26, Ted Hardie wrote: > In the examples used in RFC 5222, there was only one namespace, so=20 > there was no need for a disambiguation prefix for the elements. Even=20 > in your example, the disambiguation occurs with a prefix only on one=20 > of the two namespaces; the erratum appears to suggest it is required=20 > even when there is a single namespace. I don't think it is. The problem isn't that the example is ambiguous to you or I. Machine inter= pretation of these elements is unable to make the sorts of inferences you a= re describing. The type of each of these elements is clear: qnameList =3D list { xsd:QName* } Say that I implement this in Java with JAXB. The type of each of these ele= ments (based on the schema) is java.util.List. = When I go looking to see if the "A3" element is valid, I would use somethin= g like: List valid =3D locationValidation.getValid(); for (QName n : valid) { if (n.getNamespaceURI().equals("urn:...:civicAddr") && n.getLocalPart().equals("A3")) { return true; } } return false; That wouldn't work with the example as it stands, because the value that my= parser reads is {urn:ietf:params:xml:ns:lost1}:A3. Another secondary benefit of the schema being as it is: noise is flagged as= being in error. The following would be picked up in parsing and validatio= n unless the "foo" prefix was bound: foo:bar --Martin From James.Winterbottom@commscope.com Mon Aug 15 23:15:02 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 A41DB11E809F for ; Mon, 15 Aug 2011 23:15:02 -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=[AWL=-0.000, 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 scP+ryo89ROR for ; Mon, 15 Aug 2011 23:15:00 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 1306811E8085 for ; Mon, 15 Aug 2011 23:15:00 -0700 (PDT) X-AuditID: 0a0404e9-b7b99ae000002f72-03-4e4a0b1c7c01 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id D6.96.12146.C1B0A4E4; Tue, 16 Aug 2011 01:15:56 -0500 (CDT) Received: from CDCE10HC2.commscope.com (10.86.28.22) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 16 Aug 2011 01:15:47 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 16 Aug 2011 01:15:46 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 16 Aug 2011 14:15:40 +0800 From: "Winterbottom, James" To: "ecrit@ietf.org" Date: Tue, 16 Aug 2011 14:15:38 +0800 Thread-Topic: Review of draft-ietf-ecrit-additional-data-01 Thread-Index: Acxb2+s49qHioKNKSpW7/jhed/n5mg== Message-ID: <5A55A45AE77F5941B18E5457ECAC818801210D7D8403@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_5A55A45AE77F5941B18E5457ECAC818801210D7D8403SISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Ecrit] Review of draft-ietf-ecrit-additional-data-01 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, 16 Aug 2011 06:15:02 -0000 --_000_5A55A45AE77F5941B18E5457ECAC818801210D7D8403SISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I have been reading this document closely with an eye to implementing it, a= nd have the following substantial comments: 1) Much of the document describes specific XML elements, but without having= an up to date schema this becomes very hard follow. I see the schema as be= ing a critical update required by this document. If you need or want help i= n producing the schema please let me know and I will try to help. 2) Section 3.1.2 in the Note says that this field must be the NENA company = ID in the US. I think that this text needs to be revised to say something a= long the lines of "for example in the US this could be the NENA company ID"= , since this document hasn't been finalized it is not appropriate for the I= ETF to dictate what NENA must do. 3) I have argued against the inclusion of vCard into this data structure co= untless times in multiple forums, and I know that Brian and I are unlikely = to agree on its applicability here. Having said that, if we are going to in= clude vCard, then the need for the separate elements in sections 3.1.3 and = 3.1.4 is not apparent to me when they can be captured in 3.1.5 and hence ke= ep all of the operator data together. 4) The description in 3.1.3 says "If a telephone number is the contact addr= ess it should be provided in the form of sip:telephonenumber@serviceprovide= r:user=3Dphone". It seems to me that this would more sensibly be provided a= s a teluri. 5) Operators may provide more than one means for providing 24x7 support. Is= this allowed here, because it isn't described in section 3.1.3? 6) I think that a lot more rigor needs to go into the description and defin= itions for . It seems to conflate the issues of the type = of access medium and the notional service-type being provided. It would be = much cleaner to have two separate fields as this will make the intent clear= er. For example the first registry item listed and the last registry item l= isted may be mutually inclusive, for this field to have any real value then= it needs to be unambiguous. Instead this could be broken up into (WiMAX, LTE, CDMA-2000, GERAN, UTRAN, POTS, ADSL, Cable ..) and (VoIP, One way outbound, Pay Phone, MLTS ...) 7) suffers from the same problem that does in that the fields are not mutually exclusive, and so this will c= ause confusion. For example, what is the difference between "Tablet computi= ng device", and "Internet Tablet", or "mobile handset" and "Smart phone"? = My recommendation here would be to reduce the number of things in this list= substantially so that the general "type" of thing is known (you can provid= ed examples as to what falls in what category). If more information is requ= ired in some circumstances then have a "description" field in the data type= that allows for anything extra to be provided. 8) 3.5 the use of the term subscriber is problematic and has particular ser= vice model connotations that may not be applicable. I would like to see thi= s changed to owner, and for "addCallSub" to be changed to "addOwnerData" or= "addCallerData" or something like that. I have one nit, and that is to do with the version in the document still be= ing shown as -00 when it should be -01. Cheers James --_000_5A55A45AE77F5941B18E5457ECAC818801210D7D8403SISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have been reading this document closely with an eye to implementi= ng it, and have the following substantial comments:

 

1) Much of the document describes specific XML elements, but withou= t having an up to date schema this becomes very hard follow. I see the schema= as being a critical update required by this document. If you need or want help= in producing the schema please let me know and I will try to help.<= /span>

 

2) Section 3.1.2 in the Note says that this field must be the NENA company ID in the US= . I think that this text needs to be revised to say something along the lines= of “for example in the US this could be the NENA company ID", since this document hasn't been finalized it is not appropriate for the IETF to dictate what NENA must do.<= o:p>

 

3) I have argued against the inclusion of vCard into this data structure countless times in multiple forums, and I know that Brian and I a= re unlikely to agree on its applicability here. Having said that, if we are go= ing to include vCard, then the need for the separate elements in sections 3.1.3= and 3.1.4 is not apparent to me when they can be captured in 3.1.5 and hence ke= ep all of the operator data together.

 

4) The description in 3.1.3 says "If a telephone number is the contact address it should be provided in the form of sip:telephonenumber@serviceprovider:user=3Dphone”. It seems to me tha= t this would more sensibly be provided as a teluri.

 

5) Operators may provide more than one means for providing 24x7 sup= port. Is this allowed here, because it isn't described in section 3.1.3?

 

6) I think that a lot more rigor needs to go into the description a= nd definitions for <SvcDelByProvider>. It seems to conflate the issues o= f the type of access medium and the notional service-type being provided. It would be much cleaner to have two separate fields as this will make the int= ent clearer. For example the first registry item listed and the last registry i= tem listed may be mutually inclusive, for this field to have any real value the= n it needs to be unambiguous. Instead this could be broken up into <AccessType> (WiMAX, LTE, CDMA-2000, GERAN, UTRAN, POTS, ADSL, Cable = ..) and <Service> (VoIP, One way outbound, Pay Phone, MLTS …)

 

7) <DeviceClassification> suffers from the same problem that <SvcDelByProvider> does in that the fields are not mutually exclusive= , and so this will cause confusion. For example, what is the difference betwe= en “Tablet computing device”, and “Internet Tablet”, or “mobil= e handset” and “Smart phone”?  My recommendation here would be to reduce the number of things in this list substantially so that = the general “type” of thing is known (you can provided examples as = to what falls in what category). If more information is required in some circumstances then have a “description” field in the data type = that allows for anything extra to be provided.

 

8) 3.5 the use of the term subscriber is problematic and has partic= ular service model connotations that may not be applicable. I would like to see = this changed to owner, and for “addCallSub” to be changed to “= addOwnerData” or “addCallerData” or something like that.

 

I have one nit, and that is to do with the version in the document still being shown as -00 when it should be -01.

 

Cheers

James

 

  

 

 

 

 

--_000_5A55A45AE77F5941B18E5457ECAC818801210D7D8403SISPE7MB1co_-- From internet-drafts@ietf.org Wed Aug 17 04:40:39 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 C8D7221F8B38; Wed, 17 Aug 2011 04:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 CMlOBp52n3J8; Wed, 17 Aug 2011 04:40:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1107821F8B24; Wed, 17 Aug 2011 04:40:39 -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.58 Message-ID: <20110817114039.10526.52903.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2011 04:40:39 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-lost-sync-12.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: Wed, 17 Aug 2011 11:40:39 -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-12.txt Pages : 28 Date : 2011-08-17 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-12.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-12.txt From hannes.tschofenig@gmx.net Wed Aug 17 04:46:31 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 B4DA121F8B2B for ; Wed, 17 Aug 2011 04:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 DVW8tBHCrBw2 for ; Wed, 17 Aug 2011 04:46:31 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 04B3421F85E3 for ; Wed, 17 Aug 2011 04:46:30 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2011 11:47:20 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp004) with SMTP; 17 Aug 2011 13:47:20 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+4kJt8x2y4uM0v/KIOAvwCEw+IgUC5Atggqpbmzi kOjC3aht/h4/qm From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 17 Aug 2011 14:47:19 +0300 Message-Id: <419FF8FA-0BF7-4ABC-9829-A69AA43B5DFB@gmx.net> To: "ecrit@ietf.org Org" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] LoST Sync -v12 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, 17 Aug 2011 11:46:31 -0000 Hi all, I just submitted version 12 of the LoST sync document: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-12.txt The reason is simple: Karl Heinz found some typos. Thanks Karl Heinz! Ciao Hannes From rjsparks@nostrum.com Thu Aug 18 14:47:38 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 5A70F11E80B9 for ; Thu, 18 Aug 2011 14:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-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 J8XTQC7hku1R for ; Thu, 18 Aug 2011 14:47:37 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C1FD011E80A9 for ; Thu, 18 Aug 2011 14:47:37 -0700 (PDT) Received: from [192.168.2.105] (pool-173-57-89-228.dllstx.fios.verizon.net [173.57.89.228]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p7ILmPWd024879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Aug 2011 16:48:26 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D45BACF@SISPE7MB1.commscope.com> Date: Thu, 18 Aug 2011 16:48:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1220336F-08F3-4B50-A1A8-5AF28944BF8C@nostrum.com> <8B0A9FCBB9832F43971E38010638454F040D45BACF@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 173.57.89.228 is authenticated by a trusted mechanism) Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [Geopriv] Verifying errata 2511 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, 18 Aug 2011 21:47:38 -0000 Ted - with this argument, do you still think the errata is = inappropriate? Your suggestion for an example in local-civic is something we could do = anyhow - does anybody think that would be a bad idea? RjS On Aug 7, 2011, at 7:22 PM, Thomson, Martin wrote: > On 2011-08-06 at 07:56:26, Ted Hardie wrote: >> In the examples used in RFC 5222, there was only one namespace, so=20 >> there was no need for a disambiguation prefix for the elements. Even=20= >> in your example, the disambiguation occurs with a prefix only on one=20= >> of the two namespaces; the erratum appears to suggest it is required=20= >> even when there is a single namespace. I don't think it is. >=20 > The problem isn't that the example is ambiguous to you or I. Machine = interpretation of these elements is unable to make the sorts of = inferences you are describing. >=20 > The type of each of these elements is clear: > qnameList =3D list { xsd:QName* } >=20 > Say that I implement this in Java with JAXB. The type of each of = these elements (based on the schema) is = java.util.List. When I go looking to see if = the "A3" element is valid, I would use something like: >=20 > List valid =3D locationValidation.getValid(); > for (QName n : valid) { > if (n.getNamespaceURI().equals("urn:...:civicAddr") > && n.getLocalPart().equals("A3")) { > return true; > } > } > return false; >=20 > That wouldn't work with the example as it stands, because the value = that my parser reads is {urn:ietf:params:xml:ns:lost1}:A3. >=20 > Another secondary benefit of the schema being as it is: noise is = flagged as being in error. The following would be picked up in parsing = and validation unless the "foo" prefix was bound: >=20 > foo:bar >=20 > --Martin > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From RMarshall@telecomsys.com Fri Aug 19 17:13:48 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 A704221F856B for ; Fri, 19 Aug 2011 17:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=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 r+V1A44H7zk3 for ; Fri, 19 Aug 2011 17:13:48 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by ietfa.amsl.com (Postfix) with ESMTP id D7B9321F855D for ; Fri, 19 Aug 2011 17:13:47 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 19 Aug 2011 17:14:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC5ECE.29BB5FF7" Date: Fri, 19 Aug 2011 17:14:43 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65751B29F5E9@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF81 - ECRIT Summary minutes posted to MMM Thread-Index: AcxezilwHdpFxSD9SuycpCKNptczcg== From: "Roger Marshall" To: Cc: marc.linsner@cisco.com Subject: [Ecrit] IETF81 - ECRIT Summary minutes posted to MMM 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: Sat, 20 Aug 2011 00:13:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC5ECE.29BB5FF7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find the IETF81 ECRIT meeting minutes now posted to the Meeting Materials Manager page at https://datatracker.ietf.org/meeting/81/materials.html. =20 Thanks to John Elwell and Ram Mohan R for taking notes during the meeting. Much appreciated! =20 =20 Regards, =20 =20 =20 -roger marshall. =20 CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. ------_=_NextPart_001_01CC5ECE.29BB5FF7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please find the IETF81 ECRIT meeting minutes now = posted to the Meeting Materials Manager page at https://datatracker.ietf.org/meetin= g/81/materials.html.

 

Thanks to John Elwell and= Ram Mohan R for taking notes during the meeting.  Much appreciated!

 

 

Regards,

 =

<= o:p> 

 

-roger marshall.

 

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

------_=_NextPart_001_01CC5ECE.29BB5FF7-- From hannes.tschofenig@gmx.net Mon Aug 29 10:53:23 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 42CBC21F8C14 for ; Mon, 29 Aug 2011 10:53:23 -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 lqmDJ99vMPSg for ; Mon, 29 Aug 2011 10:53:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D313B21F8B73 for ; Mon, 29 Aug 2011 10:53:21 -0700 (PDT) Received: (qmail invoked by alias); 29 Aug 2011 17:54:45 -0000 Received: from a88-115-210-23.elisa-laajakaista.fi (EHLO [10.0.0.8]) [88.115.210.23] by mail.gmx.net (mp049) with SMTP; 29 Aug 2011 19:54:45 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/DAxhlSBXDt6lfqi/10TqpiE8K3JIdke1aEJ5TjU S0NCHfwlQh7Avi Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: <5A55A45AE77F5941B18E5457ECAC818801210D7D8403@SISPE7MB1.commscope.com> Date: Mon, 29 Aug 2011 20:54:44 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <13946585-11A9-4595-B64C-69AFBE06809C@gmx.net> References: <5A55A45AE77F5941B18E5457ECAC818801210D7D8403@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Review of draft-ietf-ecrit-additional-data-01 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, 29 Aug 2011 17:53:23 -0000 Hey James,=20 thank you for your timely review.=20 On Aug 16, 2011, at 9:15 AM, Winterbottom, James wrote: > Hi All, > =20 > I have been reading this document closely with an eye to implementing = it, and have the following substantial comments: > =20 > 1) Much of the document describes specific XML elements, but without = having an up to date schema this becomes very hard follow. I see the = schema as being a critical update required by this document. If you need = or want help in producing the schema please let me know and I will try = to help. While I fully agree that we need to get this document finished I am not = sure we really need an XML schema at all. Over the time I have gotten = the impression that an XML schema is really a waste of time. It creates = the illusion that there is something that provides help (to implementers = and to those who read the specification) but in reality it doesn't.=20 Working on different specification I later thought that the problem is = with the readability and extensibility of the XML schema and then (as = you may recall) we switched to Relax NG. That turned to be a mistake as = well. When it comes to extensibility a Relax NG schema is equally bad.=20= So, I believe we are doing fine without XML schema but with lots of = examples. Implementers just look at examples. Nobody generates codes = directly from an XML schema.=20 This may sound a bit revolutionary but what do you think? What this work = for us?=20 > =20 > 2) Section 3.1.2 in the Note says that this field must be the NENA = company ID in the US. I think that this text needs to be revised to say = something along the lines of =93for example in the US this could be the = NENA company ID", since this document hasn't been finalized it is not = appropriate for the IETF to dictate what NENA must do. Certainly correct. A mistake when we copied the text from the original = NENA spec.=20 > =20 > 3) I have argued against the inclusion of vCard into this data = structure countless times in multiple forums, and I know that Brian and = I are unlikely to agree on its applicability here. Having said that, if = we are going to include vCard, then the need for the separate elements = in sections 3.1.3 and 3.1.4 is not apparent to me when they can be = captured in 3.1.5 and hence keep all of the operator data together. Given that we have made the mistake already to blindly copy the CAP = structure for the data only emergency calls I think we need to = double-check very carefully what we need from the vCard structure. Additionally, we have to consider that the additional data is an XML = structure at the moment and the vCard encoding is not XML-based, if I = understood that correctly. I don't believe we want to mash different = encodings together in a single structure, right?=20 Only if we use http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-1 = we get the XML encoding of a vCard and I am not sure about the = availability of existing libraries. So, it seems that one really starts = from zero (implementation-wise).=20 Currently, we use the vCard in two places:=20 - 3.1.5. vCARD of Data Provider - 3.5.1. vCARD for Subscriber's Data > =20 > 4) The description in 3.1.3 says "If a telephone number is the contact = address it should be provided in the form of = sip:telephonenumber@serviceprovider:user=3Dphone=94. It seems to me that = this would more sensibly be provided as a teluri. Sounds OK for me.=20 > =20 > 5) Operators may provide more than one means for providing 24x7 = support. Is this allowed here, because it isn't described in section = 3.1.3? I believe we have to support more than one means to contact a data = provider.=20 > =20 > 6) I think that a lot more rigor needs to go into the description and = definitions for . It seems to conflate the issues of = the type of access medium and the notional service-type being provided. = It would be much cleaner to have two separate fields as this will make = the intent clearer. For example the first registry item listed and the = last registry item listed may be mutually inclusive, for this field to = have any real value then it needs to be unambiguous. Instead this could = be broken up into (WiMAX, LTE, CDMA-2000, GERAN, UTRAN, = POTS, ADSL, Cable ..) and (VoIP, One way outbound, Pay Phone, = MLTS =85) > =20 I agree with you > 7) suffers from the same problem that = does in that the fields are not mutually exclusive, = and so this will cause confusion. For example, what is the difference = between =93Tablet computing device=94, and =93Internet Tablet=94, or = =93mobile handset=94 and =93Smart phone=94? My recommendation here = would be to reduce the number of things in this list substantially so = that the general =93type=94 of thing is known (you can provided examples = as to what falls in what category). If more information is required in = some circumstances then have a =93description=94 field in the data type = that allows for anything extra to be provided. Also agree. I don't have an good suggestion for a categorization either = nor do I fully understand what call takers could use that data for. I = will ask within NENA & EENA.=20 > =20 > 8) 3.5 the use of the term subscriber is problematic and has = particular service model connotations that may not be applicable. I = would like to see this changed to owner, and for =93addCallSub=94 to be = changed to =93addOwnerData=94 or =93addCallerData=94 or something like = that. The term "subscriber" fits the text. The term "owner" is a bit funny in = the context of a VoIP services without an actual hardware device.=20 > =20 > I have one nit, and that is to do with the version in the document = still being shown as -00 when it should be -01. Another bug.=20 A question that I had raised recently was whether we should use XML as = an encoding or rather switch to JSON. Of course with all the other XML = stuff we already have the benefits may not entirely be there but I still = want to raise that issue.=20 I wonder whether you have an opinion about this. Ciao Hannes > =20 > Cheers > James > =20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Wed Aug 31 12:20:18 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 E2AB321F8EE4; Wed, 31 Aug 2011 12:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 GhHLkaHb+oYq; Wed, 31 Aug 2011 12:20:17 -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 6CDFF21F8E74; Wed, 31 Aug 2011 12:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=23257; q=dns/txt; s=iport; t=1314818501; x=1316028101; h=date:subject:from:to:cc:message-id:mime-version; bh=khGINQN3EaCMF7Jlxr5jFj65GNJX4PdoRXpC5phV160=; b=AsbmDdYzrQ8XvtClcsKF8uISXkcc6DRIhhzxSUQWClB4BLJr3yWGMH9o 7JHPYuiLft9jow36yKQ/vOO6+iVXZYUGS4dTRjbqIRszIfIykxx3PY030 h5SuKxhjkN+H4SboCsg0iy4KgInAygcUN6gy/NKV+fzn4Y2bNqJDmEjrM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAH6JXk6tJXG+/2dsb2JhbABCgk2dZYcubXeBRxIBKi4OExYELU0DFAENBQkZh1SbHgGfSYZVBJMlhQ6KU4FE X-IronPort-AV: E=Sophos;i="4.68,309,1312156800"; d="scan'208,217";a="18251916" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 31 Aug 2011 19:21:30 +0000 Received: from [10.116.195.116] (rtp-mlinsner-8713.cisco.com [10.116.195.116]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7VJLRqV007506; Wed, 31 Aug 2011 19:21:29 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 31 Aug 2011 15:21:26 -0400 From: Marc Linsner To: Robert Sparks , Message-ID: Thread-Topic: Request to Publish - draft-ietf-ecrit-lost-sync-12 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3397648889_1482420" Cc: IETF - ECRIT Subject: [Ecrit] Request to Publish - draft-ietf-ecrit-lost-sync-12 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, 31 Aug 2011 19:20:19 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3397648889_1482420 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Please publish draft-ietf-ecrit-lost-sync-12. The PROTO write-up is below. Thanks, Marc Linsner (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Marc Linsner (mlinsner@cisco.com ) Yes, this document is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has gone through repeated wg reviews and a review by the XML directorate. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No, the document is ready for publication. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. IPR 1257 was announced to the wg on 2/8/10 (http://www.ietf.org/mail-archive/web/ecrit/current/msg07012.html ) with no ensuing discussion. The protocol in this document is an extension of RFC 5222 where the identical IPR claims were filed (IPR 877 & 880). (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has a solid support base. There were 2 working group last calls (1-24-09 - (http://www.ietf.org/mail-archive/web/ecrit/current/msg05851.html) & 3-11-09 - (http://www.ietf.org/mail-archive/web/ecrit/current/msg06116.html )). All issues with this document were resolved to the consensus of the wg. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/ ). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? As mentioned earlier, this document was reviewed by the XML Directorate and passed the idnits tool. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, this document has references split between normative and informative. All references are completed documents. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations are clear and concise. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? This document has validated correctly. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The Location-to-Service Translation (LoST) protocol (RFC5222) 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 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 elements between two entities. Exchanging cached 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 element is re-used from the LoST specification. Working Group Summary There is consensus in the WG to publish this document. Document Quality The LoST protocol was implemented during the development of RFC5222 specification. This extension has been tested in various company-internal implementations, as reported to the wg chairs. The LoST specification has experienced extensive review, including reviews by other SDOs. The protocol extension is an important building block in the NENA i3 architecture. --B_3397648889_1482420 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Please publish draft-ie= tf-ecrit-lost-sync-12.

The PROTO write-up is below.=

Thanks,

Marc Linsner


 (1.a) = Who is the Document Shepherd for this document? Has the D= ocument Shepherd personally reviewed this version of the document and, in pa= rticular, does he or she believe this version is ready for forwarding to the= IESG for publication?


Marc Linsner (ml= insner@cisco.com)

Yes, this document is ready for publication.


 

(1.b) Has the document had adequate review both= from key WG members and from key non-WG members? Does the Document Shepherd= have any concerns about the depth or breadth of the reviews that have been = performed?


The document has gone through repeated wg reviews = and a review by the XML directorate.


(1.c) Does the Document Shepherd have concerns = that the document needs more review from a particular or broader perspe= ctive, e.g., security, operational complexity, someone familiar with AA= A, internationalization or XML?


No, the document is ready for publication.<= /p>


(1.d) Does the Document Shepherd have any speci= fic concerns or issues with this document that the Responsible Area Dir= ector and/or the IESG should be aware of? For example, perhaps he or she is = uncomfortable with certain parts of the document, or has concerns whether th= ere really is a need for it. In any event, if the WG has discussed those iss= ues and has indicated that it still wishes to advance the document, detail t= hose concerns here. Has an IPR disclosure related to this document been file= d? If so, please include a reference to the disclosure and summarize th= e WG discussion and conclusion on this issue.


IPR 1257 was announced to the wg on 2/8/10 (htt= p://www.ietf.org/mail-archive/web/ecrit/current/msg07012.html) wi= th no ensuing discussion.  The protocol in this document is an extensio= n of RFC 5222 where the identical IPR claims were filed (IPR 877 & 880).=


(1.e) How solid is the WG consensus behind this= document? Does it represent the strong concurrence of a few individuals, wi= th others being silent, or does the WG as a whole understand and agree with = it?


The document has a solid support base.  There= were 2 working group last calls (1-24-09 - (http://www.ietf.org/mail-archiv= e/web/ecrit/current/msg05851.html) & 3-11-09 - (http://www.ietf.org/m= ail-archive/web/ecrit/current/msg06116.html)).  All issues w= ith this document were resolved to the consensus of the wg.


(1.f) Has anyone threatened an appeal or otherw= ise indicated extreme discontent? If so, please summarise the areas of confl= ict in separate email messages to the Responsible Area Director. (It should = be in a separate email because this questionnaire is entered into the ID Tra= cker.)

 

No.


(1.g) Has the Document Shepherd personally veri= fied that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idni= ts/). Boilerplate checks are not enough; this check needs = to be thorough. Has the document met all formal review criteria it needs to,= such as the MIB Doctor, media type and URI type reviews?


As mentioned earlier, this document was reviewed b= y the XML Directorate and passed the idnits tool.


(1.h) Has the document split its references int= o normative and informative? Are there normative references to document= s that are not ready for advancement or are otherwise in an unclear state? I= f such normative references exist, what is the strategy for their compl= etion? Are there normative references that are downward references, as descr= ibed in [RFC3967]? If so, list these downward references to support the Area=         Director in the Last Call procedure for them [R= FC3967].


Yes, this document has references split between no= rmative and informative.  All references are completed documents.

 

(1.i) Has the Document Shepherd verified that t= he document IANA consideration section exists and is consistent with the bod= y of the document? If the document specifies protocol extensions, = are reservations requested in appropriate IANA registries? Are the IANA regi= stries clearly identified? If the document creates a new registry, does it d= efine the proposed initial contents of the registry and an allocation  =       procedure for future registrations? Does it suggest a = reasonable name for the new registry? See [RFC5226]. If the document describ= es an Expert Review process has Shepherd conferred with the Responsible Area= Director so that the IESG can appoint the needed Expert during the IES= G Evaluation?


The IANA considerations are clear and concise.


(1.j) Has the Document Shepherd verified that s= ections of the document that are written in a formal language, such as XML c= ode, BNF rules, MIB definitions, etc., validate correctly in an automated ch= ecker?


This document has validated correctly.


(1.k) The IESG approval announcement includes a= Document Announcement Write-Up. Please provide such a Document Announcement= Write-Up? Recent examples can be found in the "Action" announcements for ap= proved documents. The approval announcement contains the following sections:=


Technical Summary

The Location-to-Service Translation (LoST) protoco= l (RFC5222) is an XML-based protocol for mapping service identifiers and geo= detic or civic location information to service URIs and service boundaries.&= nbsp; In particular, it can be used to determine the location-appropriate Pu= blic Safety Answering Point (PSAP) for emergency services.


The main data structure, the <mapping> eleme= nt, used for encapsulating information about service boundaries is defined i= n the LoST protocol specification and circumscribes the region within which = all locations map to the same service Uniform Resource Identifier (URI) or s= et of URIs for a given service.


This document defines an XML protocol to exchange = these mappings

between two nodes.  This mechanism is designe= d for the exchange of authoritative <mapping> elements between two ent= ities.  Exchanging cached <mapping> elements, i.e. non-authoritat= ive elements, is possible but not envisioned.  In any case, this docume= nt can also be used without the LoST protocol even though the format of the = <mapping> element is re-used from the LoST specification.


Working Group Summary 

There is consensus in the WG to publish this docum= ent.


Document Quality 

The LoST protocol was implemented during the devel= opment of RFC5222 specification.  This extension has been tested in var= ious company-internal implementations, as reported to the wg chairs. The LoS= T specification has experienced extensive review, including revi= ews by other SDOs. The protocol extension is an important building block in = the NENA i3 architecture.

--B_3397648889_1482420-- From James.Winterbottom@commscope.com Wed Aug 31 16:41:37 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 B8DB521F8B24 for ; Wed, 31 Aug 2011 16:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWArTCSNmFDB for ; Wed, 31 Aug 2011 16:41:36 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id A231C21F8B1E for ; Wed, 31 Aug 2011 16:41:36 -0700 (PDT) X-AuditID: 0a0404e9-b7cd4ae000004b3f-48-4e5ec70bfaf7 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 8E.B3.19263.B07CE5E4; Wed, 31 Aug 2011 18:43:07 -0500 (CDT) Received: from CDCE10HC2.commscope.com (10.86.28.22) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 31 Aug 2011 18:43:07 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 31 Aug 2011 18:43:06 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 1 Sep 2011 07:43:03 +0800 From: "Winterbottom, James" To: Hannes Tschofenig Date: Thu, 1 Sep 2011 07:43:01 +0800 Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-additional-data-01 Thread-Index: AcxmdL+YJ2AYEF24Q9Ka6b+iivv1wABv1ltA Message-ID: <5A55A45AE77F5941B18E5457ECAC818801210F8FCE66@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC818801210D7D8403@SISPE7MB1.commscope.com> <13946585-11A9-4595-B64C-69AFBE06809C@gmx.net> In-Reply-To: <13946585-11A9-4595-B64C-69AFBE06809C@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: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Review of draft-ietf-ecrit-additional-data-01 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, 31 Aug 2011 23:41:37 -0000 Hi Hannes, Thanks for the response. Please see comments inline. Cheers James James Winterbottom Global Product Manager CommScope GeoLENs IP Location Product Portfolio Email: james.winterbottom@commscope.com Phone: +61-2-42-212938 Mobile: +61-447-773-560 =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Tuesday, 30 August 2011 3:55 AM > To: Winterbottom, James > Cc: Hannes Tschofenig; ecrit@ietf.org > Subject: Re: [Ecrit] Review of draft-ietf-ecrit-additional-data-01 >=20 > Hey James, >=20 > thank you for your timely review. >=20 > On Aug 16, 2011, at 9:15 AM, Winterbottom, James wrote: >=20 > > Hi All, > > > > I have been reading this document closely with an eye to implementing > it, and have the following substantial comments: > > > > 1) Much of the document describes specific XML elements, but without > having an up to date schema this becomes very hard follow. I see the > schema as being a critical update required by this document. If you need > or want help in producing the schema please let me know and I will try to > help. >=20 > While I fully agree that we need to get this document finished I am not > sure we really need an XML schema at all. Over the time I have gotten the > impression that an XML schema is really a waste of time. It creates the > illusion that there is something that provides help (to implementers and > to those who read the specification) but in reality it doesn't. [AJW] I don't agree with this. I think that this means that we need to comp= ile ALL examples and make sure that they are valid against the provided sch= ema. I also think that developers that are hardcoding this stuff are in for= a likely world of hurt when it comes to interoperability with vendors that= do implement against the schema. For me the schema is the place that I go = to see if things are correctly formatted or not. In most cases, we use XML = parsers that require schema in order to work optimally. Not providing a sch= ema means that there is no definitive place to look when interoperability i= ssues arise. >=20 > Working on different specification I later thought that the problem is > with the readability and extensibility of the XML schema and then (as you > may recall) we switched to Relax NG. That turned to be a mistake as well. > When it comes to extensibility a Relax NG schema is equally bad. [AJW] I don't know that I agree with this either. My main issue with specif= ying schemas in RelaxNG is that there are simply not enough tools and parse= r libraries available to just take the schema and use it. In cases where on= ly a RelaxNG schema is provided we have had to go and write the equivalent = schema in xsd first. For this reason alone I think agreeing on a single sta= ndard is best, and I would prefer that this was xsd. I certainly don't agree that the schema definition language is the problem = when it comes to specifying extension points, this is simply a matter of go= od design and deciding how a schema ought to be extended ahead of time and = perhaps documenting the rationale for this decision. >=20 > So, I believe we are doing fine without XML schema but with lots of > examples. Implementers just look at examples. Nobody generates codes > directly from an XML schema. >=20 > This may sound a bit revolutionary but what do you think? What this work > for us? [AJW] I don't agree and I would like to see a formal set of schemas. I woul= d like to a base schema with the common object definitions, and then a sche= ma for each of the 3 provider types, owner, access and voice. >=20 > > > > 2) Section 3.1.2 in the Note says that this field must be the NENA > company ID in the US. I think that this text needs to be revised to say > something along the lines of "for example in the US this could be the NEN= A > company ID", since this document hasn't been finalized it is not > appropriate for the IETF to dictate what NENA must do. >=20 > Certainly correct. A mistake when we copied the text from the original > NENA spec. >=20 > > > > 3) I have argued against the inclusion of vCard into this data structur= e > countless times in multiple forums, and I know that Brian and I are > unlikely to agree on its applicability here. Having said that, if we are > going to include vCard, then the need for the separate elements in > sections 3.1.3 and 3.1.4 is not apparent to me when they can be captured > in 3.1.5 and hence keep all of the operator data together. >=20 > Given that we have made the mistake already to blindly copy the CAP > structure for the data only emergency calls I think we need to double- > check very carefully what we need from the vCard structure. >=20 > Additionally, we have to consider that the additional data is an XML > structure at the moment and the vCard encoding is not XML-based, if I > understood that correctly. I don't believe we want to mash different > encodings together in a single structure, right? > Only if we use http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-1 > we get the XML encoding of a vCard and I am not sure about the > availability of existing libraries. So, it seems that one really starts > from zero (implementation-wise). [AJW] My suggestion would be that you simply import the vcardxml schema (ye= s, it is RelaxNG and that is unfortunate), but the defined XML object comin= g out the other end should then at least be correct.=20 >=20 > Currently, we use the vCard in two places: > - 3.1.5. vCARD of Data Provider > - 3.5.1. vCARD for Subscriber's Data >=20 >=20 > > > > 4) The description in 3.1.3 says "If a telephone number is the contact > address it should be provided in the form of > sip:telephonenumber@serviceprovider:user=3Dphone". It seems to me that th= is > would more sensibly be provided as a teluri. > Sounds OK for me. >=20 [AJW] Okay > > > > 5) Operators may provide more than one means for providing 24x7 support= . > Is this allowed here, because it isn't described in section 3.1.3? > I believe we have to support more than one means to contact a data > provider. >=20 [AJW] Okay > > > > 6) I think that a lot more rigor needs to go into the description and > definitions for . It seems to conflate the issues of th= e > type of access medium and the notional service-type being provided. It > would be much cleaner to have two separate fields as this will make the > intent clearer. For example the first registry item listed and the last > registry item listed may be mutually inclusive, for this field to have an= y > real value then it needs to be unambiguous. Instead this could be broken > up into (WiMAX, LTE, CDMA-2000, GERAN, UTRAN, POTS, ADSL, > Cable ..) and (VoIP, One way outbound, Pay Phone, MLTS ...) > > > I agree with you >=20 > > 7) suffers from the same problem that > does in that the fields are not mutually exclusive, an= d > so this will cause confusion. For example, what is the difference between > "Tablet computing device", and "Internet Tablet", or "mobile handset" and > "Smart phone"? My recommendation here would be to reduce the number of > things in this list substantially so that the general "type" of thing is > known (you can provided examples as to what falls in what category). If > more information is required in some circumstances then have a > "description" field in the data type that allows for anything extra to be > provided. >=20 > Also agree. I don't have an good suggestion for a categorization either > nor do I fully understand what call takers could use that data for. I wil= l > ask within NENA & EENA. > [AJW] Okay this looks like it is an area for further research and investiga= tion then. =20 > > > > 8) 3.5 the use of the term subscriber is problematic and has particular > service model connotations that may not be applicable. I would like to se= e > this changed to owner, and for "addCallSub" to be changed to > "addOwnerData" or "addCallerData" or something like that. >=20 > The term "subscriber" fits the text. The term "owner" is a bit funny in > the context of a VoIP services without an actual hardware device. >=20 [AJW] My concern with the use of the word "subscriber" is its connotations = with voice subscription services, and a voice subscription service is not r= equired in this calling environment, it is only one option. I guess if we i= nclude subscription to include Internet access subscription then it is okay= , but I would prefer a different term if possible. > > > > I have one nit, and that is to do with the version in the document stil= l > being shown as -00 when it should be -01. > Another bug. >=20 > A question that I had raised recently was whether we should use XML as an > encoding or rather switch to JSON. Of course with all the other XML stuff > we already have the benefits may not entirely be there but I still want t= o > raise that issue. > I wonder whether you have an opinion about this. [AJW] I don't really have an opinion either way, if JSON lets us define sch= emas with adequate constraint mechanisms then I am okay with it. What I wou= ld like to see some a consistent approach across future IETF documents thou= gh, with one schema definition being the preferred one, and use of an alter= native requiring demonstration that the preferred mechanism doesn't fit. >=20 > Ciao > Hannes >=20 > > > > Cheers > > James > > > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit