From nobody Mon Nov 3 06:43:35 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3936D1A02F1 for ; Mon, 3 Nov 2014 06:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzkyC99OR8tF for ; Mon, 3 Nov 2014 06:43:26 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AABD1A006C for ; Mon, 3 Nov 2014 06:43:25 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-a2-5457948b22f2 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0C.25.24955.B8497545; Mon, 3 Nov 2014 15:43:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Mon, 3 Nov 2014 15:43:22 +0100 From: Christer Holmberg To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: WGLC Announce: draft-ietf-ecrit-data-only-ea - WGLC comments from Christer Thread-Index: Ac/3dHSUN4f+H/Z3TXmNrkq4Yc668w== Date: Mon, 3 Nov 2014 14:43:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4E03FD@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4E03FDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+JvjW73lPAQgx335C2mnbzMbNG46Cmr xeGrS5kcmD2WLPnJ5LGj4Tmzx4atp5gDmKO4bFJSczLLUov07RK4Mv49ncZU0PSQqeLt4fmM DYxTtzF1MXJySAiYSLxefZQVwhaTuHBvPVsXIxeHkMARRonN5x4xQziLGSVmfz7C3sXIwcEm YCHR/U8bxBQRCJI4d9MGxGQWcJNYdzQBZIywQKTExK5WNhBbRCBKYt60S0wQtp7Egp2TwGwW ARWJy1M7wWxeAV+JGZ8fsoPYjEAnfD+1BizOLCAucevJfKgzBSSW7DnPDGGLSrx8/I8VZK2E gJLEtK1pEOX5EgfeL2OFGCkocXLmE5YJjMKzkEyahaRsFpIyiLiOxILdn9ggbG2JZQtfM8PY Zw48ZkIWX8DIvopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMKIObvmtuoPx8hvHQ4wCHIxK PLwF28NChFgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY2xK E3vl1wlXf933jT70Y8ZtK13/7LNsPJOWnZ3OZNGit12t+tZuh+mK53PNF+RfD9rxzmE5042g 4pISSdMigZdVCxV+fw2MCjwS7XTwTUBDHq9HQqRXkgx/xn6ePZEuPB6xZ/ZpKfez+k5+4yXD +8/v0gXul32JDmVfZQ9f2DR15vxNHbXblFiKMxINtZiLihMBJWSneYkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/WrCzOwL1xmKOmYH_7YIhZFFJ5t8 Cc: "Rosen, Brian \(Brian.Rosen@neustar.biz\)" Subject: Re: [Ecrit] WGLC Announce: draft-ietf-ecrit-data-only-ea - WGLC comments from Christer X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 14:43:32 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4E03FDESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Some comments from me, to get the discussions going :) Regards, Christer General ----------- Q1: Title & Scope I think this was already discussed before, but I think we should make it mo= re clear that the document describes a "session-free" mechanism. The text does say that a MESSAGE doesn't create a session, but I think we n= eed some additional stuff: 1) I think it should be seen in the title. E.g. "Non-Session Data-Only= Emergency Calls" or "One-Shot Data-Only Emergency Calls". 2) It should be more clear that the mechanism is aimed at "single shot= " cases only, because there is no guarantee that additional MESSAGE request= s would end up at the same location - nor does the draft define any mechani= sm on how to associated multiple MESSAGE requests with the same "call". The= re is some text about it in section 4.1, but below I will suggest some text= also for the Introduction section. Q2: SIP Terminology Throughout the document, please s/header/header field <- When you ta= lk about SIP header fields, that is Q3: Terminology alignment The terminology needs to be consistent regarding SIP responses. Sometimes t= he text says "425 response", sometimes "425", and sometimes "500 (Server In= ternal Error)". I suggest to use the "500 (Server Internal Error)" format - both when talki= ng about responses and when talking about response codes. Abstract: ------------ Q4: s/ "and its transmission using the SIP MESSAGE"/ "and its trans= mission using SIP MESSAGE requests" Introduction: ----------------- Q5: I suggest to modify: This document also describes how a SIP MESSAGE [RFC3428] transaction can be used to send a data-only call. ...to: This document also describes how a SIP MESSAGE [RFC3428] request can be used to send a one-shot data-only call, meaning that all data associated with the call is sent in a single request. NOTE: SIP MESSAGE is not suitable for data-only Calls which require the sending of multiple requests. There is no guarantee that each SIP MESSAGE request will reach traverse the same path and reach the same destination. Nor is there a SIP-layer mechanism to associate multiple SIP MESSAGE requests with a given call. Section 4.1: --------------- Q6: The first sentence says: "A CAP message may be sent on the initial message of any SIP tr= ansaction." I don't understand what "initial message of a SIP transaction" = means. Q7: The text says: "However, this document only describes specific behavior when used with a SIP INVITE that would accompany a normal emerg= ency call and a SIP MESSAGE transaction for a one-shot, data-only emergency call. Behavior with other transactions is not define= d." I suggest the following modified text: "However, this document only describes the transport of CAP mes= sages within SIP INVITE requests, when an emergency SIP session is es= tablished, and within SIP MESSAGE requests, for one-shot data-only emergen= cy calls. The transport of CAP messages within other type of SIP messages= is outside the scope of this specification." Q8: Related to that, throughout the document, I think it would be g= ood to talk about "SIP requests" rather than "SIP messages". Section 4.3: --------------- Q9: I suggest to change the title to "Sending of an one-shot data e= mergency call". Q10: Related to Q9, the wording "sending a call" sounds a little str= ange. Couldn't we simply talk about "sending of a message"? Q11: I suggest to add some text which states that a SIP MESSAGE may = fork, but that the sender will only receive one 200 OK response (according = to the 3261 rules for non-INVITE requests). I.e. the sender will not know h= ow many recipients received the MESSAGE. Section 4.x: --------------- Q12: As you have a section for the one-shot call, I think you should= also have a section which describes INVITE specific aspects. Section 5.1. ----------------- Q13: The text says: "The 425 response code is a rejection of the request du= e to its included alert content, indicating that it was malformed or not satisfactory for the recipient's purpose." I suggest the following modified text: "The recipient sends a 425 response if it considers the= alerting content to be malformed or not satisfactory for the recipient's purpo= se." Q14: The text says: "A SIP intermediary can also reject an alert it receives from a UA when it understands that the provided alert is malformed." I suggest the following modified text: "A SIP intermediary can also reject a request, if it considers the Included alert content malformed." Q15: The text says: "It is only appropriate to generate a 425 response when the res= ponding entity has no other information in the request that are usable = by the responder." I don't understand this. Above it is said that 425 is used if t= he alerting content is not usable, and now you say that the recipient should also check other information. Perhaps you could REMOVE this sentence, and enhance the sentenc= e in Q11: "The recipient sends a 425 response if it considers the= alerting content to be malformed or not satisfactory for the recipient's purpo= se, and if the request does not contain other information sufficient for emerg= ency purpose." ...or something like that. Q16: The text says: "A 425 response is a final response within a transaction, and MUST = NOT terminate an existing dialog." What does that mean??? A 4xx response DOES terminate a dialog. Section 5.2 -------------- Q17: I have never seen a SIP header field name before, where a capit= al letter is used within a word. Keep in mind that SIP header fields are ca= se-insensitive. Regards, Christer From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: 1. marraskuuta 2014 0:26 To: ecrit@ietf.org Cc: Rosen, Brian (Brian.Rosen@neustar.biz) Subject: [Ecrit] WGLC Announce: draft-ietf-ecrit-data-only-ea This starts WGLC for draft-ietf-ecrit-data-only-ea, Data-Only Emergency Cal= ls. The draft can be found at: http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Please review the draft and provide comments to the list before our ECRIT m= eeting in Honolulu, in just about 2 weeks. Thanks, Marc & Roger 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. --_000_7594FB04B1934943A5C02806D1A2204B1D4E03FDESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Some comments from me, to get t= he discussions going :)

 

Regards,

 

Christer

 

 
 
 

General

-----------

 

Q1: Title & Scope

 

I = think this was already discussed before, but I think we should make it more= clear that the document describes a “session-free” mechanism.<= o:p>

 

Th= e text does say that a MESSAGE doesn’t create a session, but I think = we need some additional stuff:

 

1= )   &= nbsp;  I think it should be se= en in the title. E.g. “Non-Session Data-Only Emergency Calls” o= r “One-Shot Data-Only Emergency Calls”.

2= )   &= nbsp;  It should be more clear= that the mechanism is aimed at “single shot” cases only, becau= se there is no guarantee that additional MESSAGE requests would end up at t= he same location – nor does the draft define any mechanism on how to associated multiple MESSAGE requests with the same = 220;call”. There is some text about it in section 4.1, but below I wi= ll suggest some text also for the Introduction section.

 

 

 

Q2: SIP Terminology<= /span>

 

Th= roughout the document, please s/header/header field     = ;   <- When you talk about SIP header fields, that is

 

 

 

Q3: Terminology alignment<= /o:p>

 

Th= e terminology needs to be consistent regarding SIP responses. Sometimes the= text says “425 response”, sometimes “425”, and som= etimes “500 (Server Internal Error)”.

 

I = suggest to use the “500 (Server Internal Error)” format –= both when talking about responses and when talking about response codes.

 

 

Abstract:

------------<= /p>

 

Q4:

 

     &= nbsp;      s/ “and its transmission using th= e SIP MESSAGE”/ “and its transmission using SIP MESSAGE request= s”

 

 

Introduction:=

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

 

 

Q5:

 

I suggest to modify:=

 

  &nbs= p;     This document also describes how a SIP MESSAGE

   &nb= sp;    [RFC3428] transaction can be used to send a data-only= call.

 =

…to:

 

        This d=
ocument also describes how a SIP MESSAGE
        [RFC3428] r=
equest can be used to send a one-shot
        data-o=
nly call, meaning that all data associated
        with t=
he call is sent in a single request.
 
        NOTE: =
SIP MESSAGE is not suitable for data-only
        Calls =
which require the sending of multiple requests.
        There =
is no guarantee that each SIP MESSAGE request
        will r=
each traverse the same path and reach the same
        destin=
ation. Nor is there a SIP-layer mechanism to
        associ=
ate multiple SIP MESSAGE requests with a given
        call.<=
o:p>

 

 

Section 4.1:<= /p>

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

 

Q6:

 

     &= nbsp;      The first sentence says:

 

     &= nbsp;      “A CAP message may be sent on the= initial message of any SIP transaction.”

 

     &= nbsp;      I don’t understand what “in= itial message of a SIP transaction” means.

 

Q7:

 

     &= nbsp;      The text says:

 

     &= nbsp;      “However, this document only desc= ribes specific behavior

      =       when used with a SIP INVITE that would accom= pany a normal emergency

      =       call and a SIP MESSAGE transaction for a one= -shot, data-only

      =       emergency call.  Behavior with other tr= ansactions is not defined.”

 

     &= nbsp;      I suggest the following modified text:<= o:p>

 

     &= nbsp;      “However, this document only desc= ribes the transport of CAP messages

     &= nbsp;      within SIP INVITE requests, when an eme= rgency SIP session is established,

     &= nbsp;      and within SIP MESSAGE requests, for on= e-shot data-only emergency calls.

 

     &= nbsp;      The transport of CAP messages within ot= her type of SIP messages is outside

     &= nbsp;      the scope of this specification.”=

 

 

Q8:

 

     &= nbsp;      Related to that, throughout the documen= t, I think it would be good to talk

     &= nbsp;      about “SIP requests” rather= than “SIP messages”.

 

 

Section 4.3:<= /p>

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

 

 

Q9:

 

        &nbs= p;   I suggest to change the title to “Sending of an one-sh= ot data emergency call”.

 

 

 

Q10:

 

        &nbs= p;   Related to Q9, the wording “sending a call” soun= ds a little strange. Couldn’t we simply

        &nbs= p;   talk about “sending of a message”?

 

 

Q11:

 

        &nbs= p;   I suggest to add some text which states that a SIP MESSAGE m= ay fork, but that the sender will only receive one 200 OK response (according to the 3261 rules for non-INVITE requ= ests). I.e. the sender will not know how many recipients received the MESSA= GE.

 

 

 

Section 4.x:<= /p>

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

 

Q12:

 

     &= nbsp;      As you have a section for the one-shot = call, I think you should also have a section which describes

     &= nbsp;      INVITE specific aspects.

 

 

 

 

 

Section 5.1.<= /p>

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

 

Q13:

 

     &= nbsp;      The text says:

 
       =
             &#=
8220;The 425 response code is a rejection of the request due to its<=
o:p>

        included alert conte= nt, indicating that it was malformed or not

        satisfactory for the= recipient's purpose.”

 

     &= nbsp;      I suggest the following modified text:<= o:p>

 
       =
             &#=
8220;The recipient sends a 425 response if it considers the alerting conten=
t to be
       =
             ma=
lformed or not satisfactory for the recipient’s purpose.”<=
/o:p>
 

Q14:

 

        &nbs= p;   The text says:

 

        “A SIP intermediary c=
an also reject an alert it receives from a UA

        when it understands = that the provided alert is malformed.”

 

        &nbs= p;   I suggest the following modified text:

 

        “A SIP intermediary c=
an also reject a request, if it considers the
        Included alert content malf=
ormed.”

 

 

Q15:

 

     &= nbsp;      The text says:

 

     &= nbsp;      “It is only appropriate to genera= te a 425 response when the responding

      =       entity has no other information in the reque= st that are usable by the

      =       responder.”

 

     &= nbsp;      I don’t understand this. Above it= is said that 425 is used if the alerting content is not usable, and now

     &= nbsp;      you say that the recipient should also = check other information.

 

     &= nbsp;      Perhaps you could REMOVE this sentence,= and enhance the sentence in Q11:

 

       =
             &#=
8220;The recipient sends a 425 response if it considers the alerting conten=
t to be
       =
             ma=
lformed or not satisfactory for the recipient’s purpose, and if the r=
equest
       =
             do=
es not contain other information sufficient for emergency purpose.”
 
       =
             &#=
8230;or something like that.

 

 

 

Q16:

 

Th= e text says:

 

        “=
;A 425 response is a final response within a transaction, and MUST NOT=

        terminate a=
n existing dialog.”

 

Wh= at does that mean??? A 4xx response DOES terminate a dialog.

 

 

Section 5.2

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

 

Q17:

 

     &= nbsp;      I have never seen a SIP header field na= me before, where a capital letter is used within a word. Keep in mind that = SIP header fields are case-insensitive.

 

 

Regards,

 

Christer

 

 

 

 
 
 
 

 

 

 

 

 <= /p>

 <= /p>

From: Ecrit [m= ailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: 1. marraskuuta 2014 0:26
To: ecrit@ietf.org
Cc: Rosen, Brian (Brian.Rosen@neustar.biz)
Subject: [Ecrit] WGLC Announce: draft-ietf-ecrit-data-only-ea

 

This starts WGLC for draf= t-ietf-ecrit-data-only-ea, Data-Only Emergency Calls.

 <= /p>

The draft can be found at= :

http://datatracker.ietf.o= rg/doc/draft-ietf-ecrit-data-only-ea/

 <= /p>

Please review the draft a= nd provide comments to the list before our ECRIT meeting in Honolulu, in ju= st about 2 weeks.

 <= /p>

Thanks,=

 <= /p>

 <= /p>

Marc & Roger

CONFIDENTIALITY NOTICE: The information contained in this mess= age may be privileged and/or confidential. If you are not the intended reci= pient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or= copying of this communication or any attachment(s) is strictly prohibited.= If you have received this message in error, please notify the sender immed= iately, and delete it and all attachments from your computer and network.

--_000_7594FB04B1934943A5C02806D1A2204B1D4E03FDESESSMB209erics_-- From nobody Fri Nov 7 10:01:20 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898841AD3C2 for ; Fri, 7 Nov 2014 10:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztm4NloBZE_x for ; Fri, 7 Nov 2014 10:01:14 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0097.outbound.protection.outlook.com [207.46.100.97]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7115B1AD3C1 for ; Fri, 7 Nov 2014 10:01:14 -0800 (PST) Received: from BLUPR07MB020.namprd07.prod.outlook.com (10.255.209.42) by BLUPR07MB019.namprd07.prod.outlook.com (10.255.209.41) with Microsoft SMTP Server (TLS) id 15.1.11.14; Fri, 7 Nov 2014 18:01:12 +0000 Received: from BLUPR07MB020.namprd07.prod.outlook.com ([169.254.11.170]) by BLUPR07MB020.namprd07.prod.outlook.com ([169.254.11.170]) with mapi id 15.01.0011.000; Fri, 7 Nov 2014 18:01:12 +0000 From: Chris Santer To: "ecrit@ietf.org" Thread-Topic: Additional Data 24 Comments Thread-Index: Ac/6tHj6+ho+z828Q2ijU/oOroBF+Q== Date: Fri, 7 Nov 2014 18:01:11 +0000 Message-ID: <4206625251104d9b956ef0a5519b086a@BLUPR07MB020.namprd07.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [4.53.197.18] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR07MB019; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(164054003)(2656002)(87936001)(122556002)(92566001)(86362001)(40100003)(229853001)(76576001)(15975445006)(19300405004)(16236675004)(2501002)(97736003)(120916001)(106356001)(105586002)(107046002)(101416001)(19625215002)(95666004)(108616004)(2351001)(107886001)(99396003)(4396001)(99286002)(33646002)(21056001)(54356999)(74316001)(20776003)(66066001)(110136001)(19580395003)(64706001)(31966008)(50986999)(450100001)(15202345003)(46102003)(62966003)(77156002)(77096003)(24736002)(80792004); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR07MB019; H:BLUPR07MB020.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_4206625251104d9b956ef0a5519b086aBLUPR07MB020namprd07pro_" MIME-Version: 1.0 X-OriginatorOrg: ddti.net Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/HH1WS04A4uDeqIzK793aNh6QuK4 Subject: [Ecrit] Additional Data 24 Comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 18:01:17 -0000 --_000_4206625251104d9b956ef0a5519b086aBLUPR07MB020namprd07pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After reviewing version 24, our team came up with some new comments: * The draft should probably make 'provided-by' all lower case; in 5= .3 it is 'Provided-By'. Xml tags are case sensitive, and RFC 4119 shows it= in all lower case when quoting in text (see section 2.2.4). * The example in draft 24 section 5.3 now shows the 'EmergencyCallD= ataValue' element in the geopriv10 namespace, which seems incorrect. * There is a 'DataProviderReference' element defined in the Emergen= cyCallData:ProviderInfo namespace - however it doesn't actually fall within= the ProviderInfoType definition like it does in other info types, and like= it is used in the examples. This does seem like a problem in the schema. * Also not sure if the 'DataProviderReference' element that is show= n directly in the PIDF-LO 'provided-by' is really supposed to be there. * The DataProviderContact element is declared in the schema as an "= xc:vcardType"; instead, it should be declared as a type within the Emergenc= yCallData:ProviderInfo namespace that contains a 'vcards' element from the = vcard-4.0 namespace. Specifically note the use of 'vcards' plural. This i= s because RFC 6351 explicitly states The element MUST be present e= ven when only a single vCard is present in an XML document. The schema in = 24 points to the single vCard definition, and most (but not all) of the exa= mples also show a single vCard, and this appears to be a violation of the R= FC. * The SubscriberData element in EmergencyCallData:SubscriberInfo ha= s the same problem as DataProviderContact above. * The schema shows an 'id' element as mandatory, but not all exampl= es show this element and I don't see any explanation what it's for. Sectio= n 4.1.2 states that a 'ProviderID' element is required, but the schema has = minOccurs=3D"0". Several other elements are in the same boat. Thanks, Chris Santer --_000_4206625251104d9b956ef0a5519b086aBLUPR07MB020namprd07pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After reviewing version 24, our team came up with s= ome new comments:

 

·         The draft should probably make ‘provided-by’ all lower = case; in 5.3 it is ‘Provided-By’.  Xml tags are case sensi= tive, and RFC 4119 shows it in all lower case when quoting in text (see sec= tion 2.2.4).

·         The example in draft 24 section 5.3 now shows the ‘EmergencyC= allDataValue’ element in the geopriv10 namespace, which seems incorre= ct.

·         There is a ‘DataProviderReference’ element defined in t= he EmergencyCallData:ProviderInfo namespace – however it doesn’= t actually fall within the ProviderInfoType definition like it does in other info types, and like it is used in the examples.  This does = seem like a problem in the schema.

·         Also not sure if the ‘DataProviderReference’ element th= at is shown directly in the PIDF-LO ‘provided-by’ is really sup= posed to be there.

·         The DataProviderContact element is declared= in the schema as an “xc:vcardType”; instead, it should be decl= ared as a type within the EmergencyCallData:ProviderInfo namespace that contains a ‘vcards’ element from the vcard-4.0 = namespace.  Specifically note the use of ‘vcards’ plural.&= nbsp; This is because RFC 6351 explicitly states The <vcards> element= MUST be present even when only a single vCard is present in an XML documen= t.  The schema in 24 points to the single vCard definition, and most (but not = all) of the examples also show a single vCard, and this appears to be a vio= lation of the RFC.

·         The SubscriberData element in EmergencyCall= Data:SubscriberInfo has the same problem as DataProviderContact above.=

·         The schema shows an ‘id’ element as mandatory, but not = all examples show this element and I don’t see any explanation what i= t’s for.  Section 4.1.2 states that a ‘ProviderID’ e= lement is required, but the schema has minOccurs=3D”0”.  Several ot= her elements are in the same boat.

 

Thanks,

 

Chris Santer

--_000_4206625251104d9b956ef0a5519b086aBLUPR07MB020namprd07pro_-- From nobody Sat Nov 8 00:16:40 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABF41A1B86 for ; Sat, 8 Nov 2014 00:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.303 X-Spam-Level: X-Spam-Status: No, score=-3.303 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfdC6UNAE6sM for ; Sat, 8 Nov 2014 00:16:36 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38DD91A1B61 for ; Sat, 8 Nov 2014 00:16:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1415434596; x=1446970596; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=8k59ga4tYIQZAc1WzVFk76fTtiVXrq5ZapiKBQHPb7Q=; b=bHuIpJnhYFMicWpiPyHkmheS/IQGRXLI6krxmVq1Yt4J3yfgqrIhigbA bypAqKpMhWc9fA9BZLy2zsl4eb0ZZHFShMIgCGW8orbR96RZs3f1xx4Y8 03TS8mk38JjS/ogZ/00TAhtfVbR/1gSkXgdsU8uNWz5fRIOwl13h6x/1s I=; X-IronPort-AV: E=McAfee;i="5600,1067,7615"; a="82652082" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 08 Nov 2014 00:16:34 -0800 X-IronPort-AV: E=Sophos;i="5.07,338,1413270000"; d="scan'208";a="31718261" Received: from nasanexm01a.na.qualcomm.com ([129.46.53.228]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Nov 2014 00:16:33 -0800 Received: from [99.111.97.136] (10.80.80.8) by nasanexm01a.na.qualcomm.com (129.46.53.228) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sat, 8 Nov 2014 00:16:33 -0800 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Fri, 7 Nov 2014 20:38:02 -0800 To: Roger Marshall , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.46.200.111) To nasanexm01a.na.qualcomm.com (129.46.53.228) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/SW1x30I8PKtwZftDq1v8GAfZ12E Cc: "Rosen, Brian \(Brian.Rosen@neustar.biz\)" Subject: Re: [Ecrit] WGLC Announce: draft-ietf-ecrit-data-only-ea X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 08:16:38 -0000 Some comments: 1: The title is not clear enough that this mechanism does establish an interactive session. I've made this suggestion before, and thought it had been agreed to. We need to change the title to something more clear. For example, "non-interactive emergency call", "non human-associated emergency call". This also occurs in the Abstract, second paragraph, fifth line, in the titles of some sections, etc. 2: Abstract, second paragraph, third line: please replace "or vehicles sending crash data" with another example. Vehicle AACN systems establish an interactive session, this is considered more critical than transmitting the data. Further, vehicle data is not sent using CAP. How about using a burglar or fire alarm? 3: Introduction, second paragraph, third and fourth line: same as (2). 4: Introduction, fifth paragraph: this should be mentioned in the Abstract. 5: Multiple locations: the 'purpose' and MIME type should use 'emergencyCallData' rather than 'emergencyCall'. 6: The document suffers from poor grammar in multiple locations, e.g., sentences omitting "is" or "the", word sequences such as "the it is", "will depends", "in case that", etc. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- In this world of sin and sorrow there is always something to be thankful for; as for me, I rejoice that I am not a Republican. --H. L. Mencken From nobody Fri Nov 14 09:33:31 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F421A1B35 for ; Fri, 14 Nov 2014 09:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omHLSMJUoJXz for ; Fri, 14 Nov 2014 09:33:26 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C69D1A1B15 for ; Fri, 14 Nov 2014 09:33:26 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id hz20so5330871lab.31 for ; Fri, 14 Nov 2014 09:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=y+Iw+0kOVrkZEo232eb8zTinXWbi5XZJLrjHF/rHwIU=; b=m2xmGYSiLcVQ9IWSymSN+KskGPxxW8fBvAVLDONEvsUo5ydA0wb824HznKI5CWqJNx 9O3ADG1y7/qeBH/LViHh7vmddNA/qzohah2NMI7Vct3pQ3MZ/Re/uZY3/gjsM23FI5tT MaCoOjIrPmggizqqG2e8Lcl3eSr+evMIDWpqafyvkjfU3mxd8yXJMTPFPVPZ57okMlDZ NuFspYlplQ9XoUSHxIZEjHanRCYiASX8ZWjQRgkUxGlbSXJXXhK80eJbkTd700AxjREK icyDG0sHR6HDrKSAxiw8Ygez+6CpNoXGMgnROl4Afzk3uyctyLIskNeloXk50vz/LITq yOOw== X-Received: by 10.112.150.102 with SMTP id uh6mr9612784lbb.50.1415986404627; Fri, 14 Nov 2014 09:33:24 -0800 (PST) MIME-Version: 1.0 Sender: archie.cobbs@gmail.com Received: by 10.25.28.73 with HTTP; Fri, 14 Nov 2014 09:33:03 -0800 (PST) From: Archie Cobbs Date: Fri, 14 Nov 2014 11:33:03 -0600 X-Google-Sender-Auth: EVuVYsSTfWgZoHzEjwc48hGQ4AQ Message-ID: To: ECRIT mailing list Content-Type: multipart/alternative; boundary=047d7b34318aa7994f0507d5066c Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/u59xQxT0LITLCx-LlI0Crig4kTU Subject: [Ecrit] Additional Data: vs. X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 17:33:28 -0000 --047d7b34318aa7994f0507d5066c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As Chris Santer pointed out in this email : The DataProviderContact element is declared in the schema as an > =E2=80=9Cxc:vcardType=E2=80=9D; instead, it should ... [contain] a =E2=80= =98vcards=E2=80=99 element from > the vcard-4.0 namespace. Specifically note the use of =E2=80=98vcards=E2= =80=99 plural. > This is because RFC 6351 explicitly states The element MUST be > present even when only a single vCard is present in an XML document. The > schema in 24 points to the single vCard definition, and most (but not all= ) > of the examples also show a single vCard, and this appears to be a > violation of the RFC. > Would it be possible to get an informal spot ruling here on the mailing list on whether the intent here is to use (singluar, as currently specified) or (plural, as required by RFC 6351)? Thanks, -Archie --047d7b34318aa7994f0507d5066c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As Chris Santer pointed out in this email:=

The DataProviderContact element is declared in the schema as an=20 =E2=80=9Cxc:vcardType=E2=80=9D; instead, it should ... [contain] a =E2=80= =98vcards=E2=80=99 element from the vcard-4.0=20 namespace.=C2=A0 Specifically note the use of =E2=80=98vcards=E2=80=99 plur= al.=C2=A0 This is=20 because RFC 6351 explicitly states The <vcards> element MUST be=20 present even when only a single vCard is present in an XML document.=C2=A0 The schema in 24 points to the single vCard definition, and most (but=20 not all) of the examples also show a single vCard, and this appears to=20 be a violation of the RFC.

Would it be po= ssible to get an informal spot ruling here on the mailing list on whether t= he intent here is to use <vcard>= ; (singluar, as currently specified) or <vcards> (plural, as required by RFC 6351)?

<= /div>Thanks,
-Archie

--047d7b34318aa7994f0507d5066c-- From nobody Fri Nov 14 14:40:01 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD9A1AD0AA for ; Fri, 14 Nov 2014 14:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UakJiKlyd5d1 for ; Fri, 14 Nov 2014 14:39:58 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C503E1AD0A7 for ; Fri, 14 Nov 2014 14:39:58 -0800 (PST) Received: from pps.filterd (m0049367.ppops.net [127.0.0.1]) by m0049367.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id sAEMZpDo025049; Fri, 14 Nov 2014 17:39:57 -0500 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049367.ppops.net-0018ba01. with ESMTP id 1qn6sysyw7-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 14 Nov 2014 17:39:57 -0500 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.204]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 14 Nov 2014 17:39:56 -0500 From: "Rosen, Brian" To: Archie Cobbs Thread-Topic: [Ecrit] Additional Data: vs. Thread-Index: AQHQAFvpKWyfK+0Ou02m++YBplE3JA== Date: Fri, 14 Nov 2014 22:39:55 +0000 Message-ID: <02033DE9-DCA6-468A-A6A2-6C148717DB12@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [156.154.7.207] Content-Type: multipart/alternative; boundary="_000_02033DE9DCA6468AA6A26C148717DB12neustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7622 signatures=670581 X-Proofpoint-Spam-Reason: safe Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/kAWAmAKJgI-2bkFbBB3BOZDROaI Cc: ECRIT mailing list Subject: Re: [Ecrit] Additional Data: vs. X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 22:40:00 -0000 --_000_02033DE9DCA6468AA6A26C148717DB12neustarbiz_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IGlzIHJpZ2h0LCBhbHRob3VnaCB3ZSBjb3VsZCBoYXZlIGEgYnVzaW5lc3Mg cnVsZSB0aGF0IHNhaWQgb25seSBvbmUuDQoNCkJyaWFuDQoNCk9uIE5vdiAxNCwgMjAxNCwgYXQg NzozMyBBTSwgQXJjaGllIENvYmJzIDxhcmNoaWVAZW1lcmdlbmN5Y2FsbHdvcmtzLmNvbTxtYWls dG86YXJjaGllQGVtZXJnZW5jeWNhbGx3b3Jrcy5jb20+PiB3cm90ZToNCg0KQXMgQ2hyaXMgU2Fu dGVyIHBvaW50ZWQgb3V0IGluIHRoaXMgZW1haWw8aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL2Vjcml0L2N1cnJlbnQvbXNnMDg5MjcuaHRtbD46DQoNClRoZSBEYXRhUHJvdmlk ZXJDb250YWN0IGVsZW1lbnQgaXMgZGVjbGFyZWQgaW4gdGhlIHNjaGVtYSBhcyBhbiDigJx4Yzp2 Y2FyZFR5cGXigJ07IGluc3RlYWQsIGl0IHNob3VsZCAuLi4gW2NvbnRhaW5dIGEg4oCYdmNhcmRz 4oCZIGVsZW1lbnQgZnJvbSB0aGUgdmNhcmQtNC4wIG5hbWVzcGFjZS4gIFNwZWNpZmljYWxseSBu b3RlIHRoZSB1c2Ugb2Yg4oCYdmNhcmRz4oCZIHBsdXJhbC4gIFRoaXMgaXMgYmVjYXVzZSBSRkMg NjM1MSBleHBsaWNpdGx5IHN0YXRlcyBUaGUgPHZjYXJkcz4gZWxlbWVudCBNVVNUIGJlIHByZXNl bnQgZXZlbiB3aGVuIG9ubHkgYSBzaW5nbGUgdkNhcmQgaXMgcHJlc2VudCBpbiBhbiBYTUwgZG9j dW1lbnQuICBUaGUgc2NoZW1hIGluIDI0IHBvaW50cyB0byB0aGUgc2luZ2xlIHZDYXJkIGRlZmlu aXRpb24sIGFuZCBtb3N0IChidXQgbm90IGFsbCkgb2YgdGhlIGV4YW1wbGVzIGFsc28gc2hvdyBh IHNpbmdsZSB2Q2FyZCwgYW5kIHRoaXMgYXBwZWFycyB0byBiZSBhIHZpb2xhdGlvbiBvZiB0aGUg UkZDLg0KDQpXb3VsZCBpdCBiZSBwb3NzaWJsZSB0byBnZXQgYW4gaW5mb3JtYWwgc3BvdCBydWxp bmcgaGVyZSBvbiB0aGUgbWFpbGluZyBsaXN0IG9uIHdoZXRoZXIgdGhlIGludGVudCBoZXJlIGlz IHRvIHVzZSA8dmNhcmQ+IChzaW5nbHVhciwgYXMgY3VycmVudGx5IHNwZWNpZmllZCkgb3IgPHZj YXJkcz4gKHBsdXJhbCwgYXMgcmVxdWlyZWQgYnkgUkZDIDYzNTEpPw0KDQpUaGFua3MsDQotQXJj aGllDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpF Y3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnPG1haWx0bzpFY3JpdEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0K --_000_02033DE9DCA6468AA6A26C148717DB12neustarbiz_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSSB0aGluayB0aGF0IGlzIHJpZ2h0 LCBhbHRob3VnaCB3ZSBjb3VsZCBoYXZlIGEgYnVzaW5lc3MgcnVsZSB0aGF0IHNhaWQgb25seSBv bmUuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5C cmlhbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE5vdiAxNCwgMjAxNCwg YXQgNzozMyBBTSwgQXJjaGllIENvYmJzICZsdDs8YSBocmVmPSJtYWlsdG86YXJjaGllQGVtZXJn ZW5jeWNhbGx3b3Jrcy5jb20iIGNsYXNzPSIiPmFyY2hpZUBlbWVyZ2VuY3ljYWxsd29ya3MuY29t PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+QXMgQ2hyaXMgU2FudGVyIHBvaW50ZWQgb3V0IGluIDxhIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9lY3JpdC9jdXJyZW50L21z ZzA4OTI3Lmh0bWwiIGNsYXNzPSIiPg0KdGhpcyBlbWFpbDwvYT46PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDti b3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4IiBj bGFzcz0iZ21haWxfcXVvdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIgY2xhc3M9IiI+VGhlIERhdGFQcm92 aWRlckNvbnRhY3QgZWxlbWVudCBpcyBkZWNsYXJlZCBpbiB0aGUgc2NoZW1hIGFzIGFuIOKAnHhj OnZjYXJkVHlwZeKAnTsgaW5zdGVhZCwgaXQgc2hvdWxkIC4uLiBbY29udGFpbl0gYSDigJh2Y2Fy ZHPigJkgZWxlbWVudCBmcm9tIHRoZSB2Y2FyZC00LjAgbmFtZXNwYWNlLiZuYnNwOyBTcGVjaWZp Y2FsbHkgbm90ZSB0aGUgdXNlDQogb2Yg4oCYdmNhcmRz4oCZIHBsdXJhbC4mbmJzcDsgVGhpcyBp cyBiZWNhdXNlIFJGQyA2MzUxIGV4cGxpY2l0bHkgc3RhdGVzIFRoZSAmbHQ7dmNhcmRzJmd0OyBl bGVtZW50IE1VU1QgYmUgcHJlc2VudCBldmVuIHdoZW4gb25seSBhIHNpbmdsZSB2Q2FyZCBpcyBw cmVzZW50IGluIGFuIFhNTCBkb2N1bWVudC4mbmJzcDsgVGhlIHNjaGVtYSBpbiAyNCBwb2ludHMg dG8gdGhlIHNpbmdsZSB2Q2FyZCBkZWZpbml0aW9uLCBhbmQgbW9zdCAoYnV0IG5vdCBhbGwpIG9m IHRoZSBleGFtcGxlcw0KIGFsc28gc2hvdyBhIHNpbmdsZSB2Q2FyZCwgYW5kIHRoaXMgYXBwZWFy cyB0byBiZSBhIHZpb2xhdGlvbiBvZiB0aGUgUkZDLjwvc3Bhbj4gPGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpXb3VsZCBpdCBiZSBwb3NzaWJsZSB0 byBnZXQgYW4gaW5mb3JtYWwgc3BvdCBydWxpbmcgaGVyZSBvbiB0aGUgbWFpbGluZyBsaXN0IG9u IHdoZXRoZXIgdGhlIGludGVudCBoZXJlIGlzIHRvIHVzZQ0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5Om1vbm9zcGFjZSIgY2xhc3M9IiI+Jmx0O3ZjYXJkJmd0Ozwvc3Bhbj4gKHNpbmdsdWFyLCBh cyBjdXJyZW50bHkgc3BlY2lmaWVkKSBvcg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Om1vbm9z cGFjZSIgY2xhc3M9IiI+Jmx0O3ZjYXJkcyZndDs8L3NwYW4+IChwbHVyYWwsIGFzIHJlcXVpcmVk IGJ5IFJGQyA2MzUxKT88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClRoYW5r cyw8YnIgY2xhc3M9IiI+DQotQXJjaGllPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBj bGFzcz0iIj4NCkVjcml0IG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0 bzpFY3JpdEBpZXRmLm9yZyIgY2xhc3M9IiI+RWNyaXRAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIi Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_02033DE9DCA6468AA6A26C148717DB12neustarbiz_-- From nobody Fri Nov 14 16:25:22 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4771A1B4D for ; Fri, 14 Nov 2014 10:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLSVQPzKQ0Ww for ; Fri, 14 Nov 2014 10:11:11 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617AA1A1A86 for ; Fri, 14 Nov 2014 10:11:11 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id rd18so18581467iec.35 for ; Fri, 14 Nov 2014 10:11:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YJCTWWtAHpCECtQ4k7mMyyCDCOibuE57ZVXmMxrqKXU=; b=a8SYEmU8I7ylkCSYV79xBRFhyvsdzJcfrO1oMNG2MpUFoeorq45quYvYSQYnibkI94 D6a5XQW/RyuL/zwz5Qzcj5gla7mDYgfc+mno0pa4oruqbJIQCvf6Dqe9s1ragA101kj9 n9bYOdTMqRrCp0CdaTIFYP5KmdRdcXN16WYK4r/Mi1c4DcOiFDsxjfIg6Rt3DsXFv76h KTZ0Izzc0VNSWAhsR2Sq0SrKMVFsFTKZBt7LXV/7p9vxl6PcxFvYjYZUfidDEl1J+DN/ 14qFsP4AiQD4EMUIEHWjQ2mWZQIV/USjUhXwnO4qV//q4m+qy19EbRqssCg3OSiIsVj5 vPKA== MIME-Version: 1.0 X-Received: by 10.50.138.76 with SMTP id qo12mr7906662igb.13.1415988670094; Fri, 14 Nov 2014 10:11:10 -0800 (PST) Received: by 10.43.3.4 with HTTP; Fri, 14 Nov 2014 10:11:10 -0800 (PST) Date: Fri, 14 Nov 2014 08:11:10 -1000 Message-ID: From: Ted Hardie To: "ecrit@ietf.org" , Andrew Newton Content-Type: multipart/alternative; boundary=001a1134b964afe3360507d58d70 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/UAYMT30TF5uqEk5qbgdsKuNLggs X-Mailman-Approved-At: Fri, 14 Nov 2014 16:25:08 -0800 Subject: [Ecrit] Erratum 4175 for RFC 5222 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 18:11:13 -0000 --001a1134b964afe3360507d58d70 Content-Type: text/plain; charset=UTF-8 Andy and I reviewed this erratum and believe it is correct and should be accepted as an editorial issue. Ted --001a1134b964afe3360507d58d70 Content-Type: text/html; charset=UTF-8
Andy and I reviewed this erratum and believe it is correct and should be accepted as an editorial issue.

Ted
--001a1134b964afe3360507d58d70-- From nobody Fri Nov 14 16:25:23 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244B81A00D4 for ; Wed, 12 Nov 2014 14:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.896 X-Spam-Level: X-Spam-Status: No, score=-106.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iaiz_dsjHYMT for ; Wed, 12 Nov 2014 14:46:29 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0749F1A00CF for ; Wed, 12 Nov 2014 14:46:29 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 970DF181C93; Wed, 12 Nov 2014 14:45:56 -0800 (PST) To: hardie@qualcomm.com, andy@hxr.us, hgs+ecrit@cs.columbia.edu, Hannes.Tschofenig@nsn.com, rlb@ipv.sx, alissa@cooperw.in, marc.linsner@cisco.com, rmarshall@telecomsys.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141112224556.970DF181C93@rfc-editor.org> Date: Wed, 12 Nov 2014 14:45:56 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/nX3Ph52w5MB0yM3Lhyj9b810gI4 X-Mailman-Approved-At: Fri, 14 Nov 2014 16:25:09 -0800 Cc: dbanks@ddti.net, ecrit@ietf.org, rfc-editor@rfc-editor.org Subject: [Ecrit] [Technical Errata Reported] RFC5222 (4174) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 22:46:31 -0000 The following errata report has been submitted for RFC5222, "LoST: A Location-to-Service Translation Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5222&eid=4174 -------------------------------------- Type: Technical Reported by: Dan Banks Section: 15 & Apdx A Original Text ------------- In section 15, the Exception pattern says (in part): locationProfileUnrecognized = element locationProfileUnrecognized { attribute unsupportedProfiles { xsd:NMTOKENS }, basicException } The corresponding section in Appendix A says: Corrected Text -------------- Section 15 should say: locationProfileUnrecognized = element locationProfileUnrecognized { basicException } Appendix A should say: Notes ----- The ‘unsupportedProfiles’ attribute is not referenced anywhere else in the text of the document; no instruction is given describing the use of this attribute. This, by itself, is problematic. However, based on the type, it seems reasonable that the intent may have been to list the location profiles which the server is unable to understand. Consider the condition under which the ‘locationProfileUnrecognized’ error is returned (section 12.1): 8. If a server receives a request that only contains location information using profiles it does not understand, the server responds with a If none of the locations include the optional ‘profile’ attribute, the server may not be able to identify any of the profiles and therefore would be incapable of returning a list of profile names. This is especially problematic considering that the ‘unsupportedProfiles’ attribute is required by the schema. Even in cases where one or more locations include the profile attribute, the client already knows what profiles were used in the request, so returning a list of these profiles does not provide new information to the client. At best, use of the ‘unsupportedProfiles’ attribute appears to be redundant; at worst, it is impossible. Therefore, the suggested course of action is to remove the attribute from the schema. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5222 (draft-ietf-ecrit-lost-10) -------------------------------------- Title : LoST: A Location-to-Service Translation Protocol Publication Date : August 2008 Author(s) : T. Hardie, A. Newton, H. Schulzrinne, H. Tschofenig Category : PROPOSED STANDARD Source : Emergency Context Resolution with Internet Technologies Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Fri Nov 14 16:25:25 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D801A0149 for ; Wed, 12 Nov 2014 14:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XH4Y4h4ImrxR for ; Wed, 12 Nov 2014 14:54:36 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 137D41A00F7 for ; Wed, 12 Nov 2014 14:54:36 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A1BE4181C93; Wed, 12 Nov 2014 14:54:03 -0800 (PST) To: hardie@qualcomm.com, andy@hxr.us, hgs+ecrit@cs.columbia.edu, Hannes.Tschofenig@nsn.com, rlb@ipv.sx, alissa@cooperw.in, marc.linsner@cisco.com, rmarshall@telecomsys.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141112225403.A1BE4181C93@rfc-editor.org> Date: Wed, 12 Nov 2014 14:54:03 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/ZeCWlHO_PEwRgSNFxVAGDXCUhJ4 X-Mailman-Approved-At: Fri, 14 Nov 2014 16:25:10 -0800 Cc: dbanks@ddti.net, ecrit@ietf.org, rfc-editor@rfc-editor.org Subject: [Ecrit] [Editorial Errata Reported] RFC5222 (4175) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 22:54:37 -0000 The following errata report has been submitted for RFC5222, "LoST: A Location-to-Service Translation Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5222&eid=4175 -------------------------------------- Type: Editorial Reported by: Dan Banks Section: 12.1 Fig 15 Original Text ------------- 42.656844 -73.348157 Corrected Text -------------- 42.656844 -73.348157 Notes ----- The 'srsName' in the location provided as part of example in Figure 15 is missing a required ':' between 'EPSG' and '4326'. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5222 (draft-ietf-ecrit-lost-10) -------------------------------------- Title : LoST: A Location-to-Service Translation Protocol Publication Date : August 2008 Author(s) : T. Hardie, A. Newton, H. Schulzrinne, H. Tschofenig Category : PROPOSED STANDARD Source : Emergency Context Resolution with Internet Technologies Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Fri Nov 14 16:25:26 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D5D1A8990 for ; Thu, 13 Nov 2014 07:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7j_BgcnbcYFH for ; Thu, 13 Nov 2014 07:47:21 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 42CA21A8996 for ; Thu, 13 Nov 2014 07:47:20 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A0475182544; Thu, 13 Nov 2014 07:46:45 -0800 (PST) To: hardie@qualcomm.com, andy@hxr.us, hgs+ecrit@cs.columbia.edu, Hannes.Tschofenig@nsn.com, rlb@ipv.sx, alissa@cooperw.in, marc.linsner@cisco.com, rmarshall@telecomsys.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141113154645.A0475182544@rfc-editor.org> Date: Thu, 13 Nov 2014 07:46:45 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/XtEYUyEFSY4fH0nNhwOoUGe-TjY X-Mailman-Approved-At: Fri, 14 Nov 2014 16:25:10 -0800 Cc: dbanks@ddti.net, ecrit@ietf.org, rfc-editor@rfc-editor.org Subject: [Ecrit] [Technical Errata Reported] RFC5222 (4176) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 15:47:28 -0000 The following errata report has been submitted for RFC5222, "LoST: A Location-to-Service Translation Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5222&eid=4176 -------------------------------------- Type: Technical Reported by: Dan Banks Section: 15 & Apdx A Original Text ------------- Section 15: exceptionContainer = (badRequest? & internalError? & serviceSubstitution? & defaultMappingReturned? & forbidden? & notFound? & loop? & serviceNotImplemented? & serverTimeout? & serverError? & locationInvalid? & locationProfileUnrecognized?), extensionPoint, source And: serverError = element serverError { basicException } locationInvalid = element locationInvalid { basicException } Appendix A: And: Corrected Text -------------- Section 15: exceptionContainer = (badRequest? & internalError? & serviceSubstitution? & defaultMappingReturned? & forbidden? & notFound? & loop? & serviceNotImplemented? & serverTimeout? & serverError? & SRSInvalid? & locationInvalid? & locationProfileUnrecognized?), extensionPoint, source And: serverError = element serverError { basicException } SRSInvalid = element SRSInvalid { basicException } locationInvalid = element locationInvalid { basicException } Appendix A: And: Notes ----- The SRSInvalid error is defined in section 13.1, but was omitted from the schemas. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5222 (draft-ietf-ecrit-lost-10) -------------------------------------- Title : LoST: A Location-to-Service Translation Protocol Publication Date : August 2008 Author(s) : T. Hardie, A. Newton, H. Schulzrinne, H. Tschofenig Category : PROPOSED STANDARD Source : Emergency Context Resolution with Internet Technologies Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Fri Nov 14 16:25:28 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9E71A1B59 for ; Fri, 14 Nov 2014 10:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lz2naJCDijd0 for ; Fri, 14 Nov 2014 10:16:02 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7AC1A1BFE for ; Fri, 14 Nov 2014 10:15:38 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id hn18so138842igb.13 for ; Fri, 14 Nov 2014 10:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YmWsG7W7BHLJ9U8AMcop8Txk2sr0uifeayZny+qmA5g=; b=tkDAeZO+DKVXStwzB16Y7KwREal/+Vw/fdMv94FuLePsYp2O7iuNI8k5HZGuXFYeBH UO852M2+r5J6dBNidKZp/pxWagqQ3+Wriy7FTLeHk9hg1rBO1Mham1sj+P7eTWyM8lgc d/vM8mnwjIXyBX3HoS9mrKoa1RutsFDasIsxpITCBAFn/j5FIbHHsU/1hFe0SxETqZRg vZLLqaipBB4SKt+cW1O/tl/jxIH9r8aX5ij6sMjIeFR4LHSaw0z8cp8B1gXGKKyJ7ngG qxo+UUxf8VW7Vvr4wG8JwrR89uNRa5tPYSuNkV2wlTBfcF8onXK//b8pfVvQ15irv8nr G0SQ== MIME-Version: 1.0 X-Received: by 10.50.110.65 with SMTP id hy1mr7889001igb.13.1415988937753; Fri, 14 Nov 2014 10:15:37 -0800 (PST) Received: by 10.43.3.4 with HTTP; Fri, 14 Nov 2014 10:15:37 -0800 (PST) Date: Fri, 14 Nov 2014 08:15:37 -1000 Message-ID: From: Ted Hardie To: "ecrit@ietf.org" , Andrew Newton Content-Type: multipart/alternative; boundary=089e0111d1dea40b220507d59de2 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/UnqtQggKHbFi7puQIPNLpkSLkL4 X-Mailman-Approved-At: Fri, 14 Nov 2014 16:25:09 -0800 Subject: [Ecrit] Errata 4174 for RFC 5222 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 18:16:05 -0000 --089e0111d1dea40b220507d59de2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Andy and I reviewed this report and agree that =E2=80=98unsupportedProfiles= =E2=80=99 is not described in the text of RFC 5222. We do not agree, however, with the proposal that it be removed, as this may invalidate schema parsers which based their schema validation on the schema provided. We propose instead that this schema element be marked as unused by the erratum. Ted --089e0111d1dea40b220507d59de2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andy and I reviewed this report and agree that = =E2=80=98unsupportedProfiles=E2=80=99 is not described in the text of RFC 5= 222.=C2=A0 We do not agree, however, with the proposal that it be removed, = as this may invalidate schema parsers which based their schema validation o= n the schema provided.=C2=A0 We propose instead that this schema element be= marked as unused by the erratum.

Ted
--089e0111d1dea40b220507d59de2-- From nobody Fri Nov 14 16:25:30 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE46E1A6EFF for ; Fri, 14 Nov 2014 10:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14PODRoKuhrq for ; Fri, 14 Nov 2014 10:20:39 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868C21A1B61 for ; Fri, 14 Nov 2014 10:20:39 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id rd18so18599173iec.35 for ; Fri, 14 Nov 2014 10:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=23YT3YQL1yh/Vzs2feRiCoYSY6YkMSxiBcWHAuJKJq8=; b=P5MABEZzb7fnE38zFCiOwHc1+okp7HNS5IeV5OND3EvmNDBnb2GC5LQ/EP2jSasiFD Zz+jm0AtiHLfSn5iIuFD5ip29aXsMtYexLtvtwAhgZPOYjvbAQCT3smdux4rqEGo2z92 izlwOGv0pRwr19bjdVt8gvai25TcMUyZ3Z/DJ3BKYpMJBMwVnCCl+JhwBJvlarugJaOO 4bIV1xy55iQazvAdq2NT0l5t+L15MquvLsOPnbd1z8ebPTlpqQgcxI/9/YfAlKi3xU6q t/08uabZAG4CS3r2bfPeWTcY8wohcH74ZoDL3mN+vSLFrabXH5/AJpUSgoYfQBKwr6YM EJdw== MIME-Version: 1.0 X-Received: by 10.50.110.65 with SMTP id hy1mr7926105igb.13.1415989238657; Fri, 14 Nov 2014 10:20:38 -0800 (PST) Received: by 10.43.3.4 with HTTP; Fri, 14 Nov 2014 10:20:38 -0800 (PST) Date: Fri, 14 Nov 2014 08:20:38 -1000 Message-ID: From: Ted Hardie To: "ecrit@ietf.org" , Andrew Newton Content-Type: multipart/alternative; boundary=089e0111d1de937a2e0507d5afa5 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/lnMmKOs6ubrz1Th3eJqhOd9KoZs X-Mailman-Approved-At: Fri, 14 Nov 2014 16:25:09 -0800 Subject: [Ecrit] Errata 4176 for RFC 5222 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 18:20:41 -0000 --089e0111d1de937a2e0507d5afa5 Content-Type: text/plain; charset=UTF-8 Andy and I have reviewed the schema and agree that the SRSInvalid error is described in the text but not present in the schema. If this schema element is in use in the community or required by the working group, a new version of the schema is needed to insert the element and would need to be documented in a revised RFC. regards, Ted --089e0111d1de937a2e0507d5afa5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andy and I have reviewed the schema and agree th= at the SRSInvalid error is described in the text but not present in the sch= ema.=C2=A0 If this schema element is in use in the community or required by= the working group, a new version of the schema is needed to insert the ele= ment and would need to be documented in a revised RFC.

regards,

Ted
--089e0111d1de937a2e0507d5afa5-- From nobody Sat Nov 15 01:41:51 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521E41A6FE1 for ; Sat, 15 Nov 2014 01:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.595 X-Spam-Level: X-Spam-Status: No, score=-7.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwrpkoreFu_q for ; Sat, 15 Nov 2014 01:41:46 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A743F1A1B0C for ; Sat, 15 Nov 2014 01:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1416044506; x=1447580506; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=NjwgaD9chqz7anznNE8RaFOPmwxoaZtC0aewSEBdgRE=; b=BMCCBn59Qo8kyZ5l4uACeBzTiPq3ACNz+DWtPsdCTZzKR5SxccDkT/ZQ CkoT9wsycZK1YRjxkbdaFatS7wDOvhR1UGWzDgmxFRwVQ1QXbxyAe3OFi f7H8x/JNeuFzYGPQp+mSptBuSoB1E2PSSmr+FMQA209Po7LH0doBllm82 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7622"; a="78241312" Received: from unknown (HELO Ironmsg03-R.qualcomm.com) ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2014 01:41:44 -0800 X-IronPort-AV: E=Sophos;i="5.07,390,1413270000"; d="scan'208";a="791283310" Received: from nasanexm01a.na.qualcomm.com ([129.46.53.228]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Nov 2014 01:41:45 -0800 Received: from dhcp-b1ed.meeting.ietf.org (10.80.80.8) by nasanexm01a.na.qualcomm.com (129.46.53.228) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sat, 15 Nov 2014 01:41:43 -0800 Message-ID: In-Reply-To: <02033DE9-DCA6-468A-A6A2-6C148717DB12@neustar.biz> References: <02033DE9-DCA6-468A-A6A2-6C148717DB12@neustar.biz> X-Mailer: Eudora for Mac OS X Date: Sat, 15 Nov 2014 01:41:38 -0800 To: "Rosen, Brian" , Archie Cobbs From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.46.200.111) To nasanexm01a.na.qualcomm.com (129.46.53.228) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/Ch-vYAHCMyDyNS1P8g7imR12kzI Cc: ECRIT mailing list Subject: Re: [Ecrit] Additional Data: vs. X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 09:41:49 -0000 At 10:39 PM +0000 11/14/14, Brian Rosen wrote: > I think that is right, although we could have a business rule that > said only one. The intent all along has been to have one vcard, so I can update the document to use but specify that only one vcard SHOULD be provided. > >> On Nov 14, 2014, at 7:33 AM, Archie Cobbs >> <archie@emergencycallworks.com> >> wrote: >> >> As Chris Santer pointed out in >> >> this email: >> >> The DataProviderContact element is declared in the schema as an >> "xc:vcardType"; instead, it should ... [contain] a 'vcards' >> element from the vcard-4.0 namespace. Specifically note the use >> of 'vcards' plural. This is because RFC 6351 explicitly states >> The element MUST be present even when only a single vCard >> is present in an XML document. The schema in 24 points to the >> single vCard definition, and most (but not all) of the examples >> also show a single vCard, and this appears to be a violation of >> the RFC. >> >> >> Would it be possible to get an informal spot ruling here on the >> mailing list on whether the intent here is to use >> (singluar, as currently specified) or (plural, as >> required by RFC 6351)? >> >> Thanks, >> -Archie >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- If A = B and B = C, then A = C, except where void or prohibited by law. From nobody Sat Nov 15 02:13:24 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27C51A7D85 for ; Sat, 15 Nov 2014 02:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKnYkYeCbFyx for ; Sat, 15 Nov 2014 02:13:21 -0800 (PST) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE2F1A6F90 for ; Sat, 15 Nov 2014 02:13:20 -0800 (PST) Received: by mail-pd0-f180.google.com with SMTP id ft15so18245681pdb.11 for ; Sat, 15 Nov 2014 02:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=ahLmTyQRRfzkxqBsgFg0F2WcgCK34MoFwy6s0SPSBxk=; b=cGJp9HPokySYfHRLLF4oRMmzBOoSSRuLydklVpWWTxZ3boZTpFGpHfF0nLNvJjdzjO Zu/cn3e46/VNC5ny5HfKA9KLx7Mopd9Jjv8mkOHrrsmdyYZhNmhZrSjm60N5ssf1Otlz Ss8RkpWpD1r4DHABOjodwBi58aAdJZZQaZ8WTCvSlvrXEEvtMzaB6Bcuzui9chgk18uc oH6uzEiLMZ4jnzyKRzB1FmPmqxFtyPUm/5hcxuF8iyg5ua25T47xvm6yZLKYreOpdedB TVIeGkHfLkg2lAqy05YW0PyHs+GIzbit6hCpWCeIWo5glZ79XXpUi1UdUHPcNXtIzDiA Aj7A== X-Received: by 10.66.161.3 with SMTP id xo3mr530460pab.131.1416046400074; Sat, 15 Nov 2014 02:13:20 -0800 (PST) Received: from [192.168.1.11] (124-171-32-20.dyn.iinet.net.au. [124.171.32.20]) by mx.google.com with ESMTPSA id tv4sm29962171pab.28.2014.11.15.02.13.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Nov 2014 02:13:19 -0800 (PST) References: <02033DE9-DCA6-468A-A6A2-6C148717DB12@neustar.biz> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <36F24447-E2AF-41B8-8A8D-BFEF8020A8FE@gmail.com> X-Mailer: iPhone Mail (11D201) From: James Winterbottom Date: Sat, 15 Nov 2014 21:13:17 +1100 To: Randall Gellens Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/LSWd7LabdVh0x924ay0z-GDJG4o Cc: "Rosen, Brian" , ECRIT mailing list Subject: Re: [Ecrit] Additional Data: vs. X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 10:13:23 -0000 And if more than one is provided only the first shall be used. Sent from my iPhone > On 15 Nov 2014, at 8:41 pm, Randall Gellens wrote= : >=20 > At 10:39 PM +0000 11/14/14, Brian Rosen wrote: >=20 >> I think that is right, although we could have a business rule that said o= nly one. >=20 > The intent all along has been to have one vcard, so I can update the docum= ent to use but specify that only one vcard SHOULD be provided. >=20 >>=20 >>> On Nov 14, 2014, at 7:33 AM, Archie Cobbs <archie@emergencycallworks.com> wrote: >>>=20 >>> As Chris Santer pointed out in this email: >>>=20 >>> The DataProviderContact element is declared in the schema as an "xc:vcar= dType"; instead, it should ... [contain] a 'vcards' element from the vcard-4= .0 namespace. Specifically note the use of 'vcards' plural. This is becaus= e RFC 6351 explicitly states The element MUST be present even when o= nly a single vCard is present in an XML document. The schema in 24 points t= o the single vCard definition, and most (but not all) of the examples also s= how a single vCard, and this appears to be a violation of the RFC. >>>=20 >>>=20 >>> Would it be possible to get an informal spot ruling here on the mailing l= ist on whether the intent here is to use (singluar, as currently spe= cified) or (plural, as required by RFC 6351)? >>>=20 >>> Thanks, >>> -Archie >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > If A =3D B and B =3D C, then A =3D C, except where void or prohibited by l= aw. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit