From nobody Fri May 15 07:55:11 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C670C1A1A3E for ; Fri, 15 May 2015 07:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.741 X-Spam-Level: X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 eWYPaYFU9XUJ for ; Fri, 15 May 2015 07:55:07 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 D7A431A008A for ; Fri, 15 May 2015 07:55:06 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Fri, 15 May 2015 16:55:00 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Fri, 15 May 2015 16:54:56 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: "Substrate Protocol" instead of "Transport Protocol" Thread-Index: AdCPHicMj7vAewJlS6W44FhadFoixw== Date: Fri, 15 May 2015 14:54:55 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075467EA137@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: Subject: [drinks] "Substrate Protocol" instead of "Transport Protocol" X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 14:55:08 -0000 All, I'm currently working through the remaining COMMENTs and "near-DISCUSSes" o= n our documents, specifically the Framework document: https://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/ballot/ There was some significant concern about the use of the term "Transport" fo= r an above-layer-4-protocol, sepcifically by Spencer and Martin. Spencer pr= ovided a compromise text, while Martin strongly leans towards changing our = terminology. As Spencer wrote, the term "Substrate" could be used instead = of "Transport".=20 The SOAP document contains 24 instances of the word "transport", while the = framework document contains 54 instances. Therefore, i think it would be re= asonable effort to switch to "Substrate", and that would adress both Spence= r's as well as Martin's comments. Thoughts? Alex From nobody Fri May 15 08:03:08 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602B61A00E4 for ; Fri, 15 May 2015 08:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 34WB7daveMrr for ; Fri, 15 May 2015 08:03:05 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989C61A0010 for ; Fri, 15 May 2015 08:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnsi.com; i=@tnsi.com; q=dns/txt; s=tnsi; t=1431705929; x=1463241929; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ghGdqVi6WnNShvFT1938/v/6VBfybvpiFooCMnhwKHU=; b=TZ+8lm6DMzC9DAxcQ1IxbJBAD73SFMZoVG5xTma9VpZxGb+pVNjNOME7 a3ZfY2TbY0VI9wgJmfUFskcBrKt4E+RRx1G6MFS1a4Kx4DvXIOQpnE5ha CkjIpPOA3Jf4VrlLJ+Mt5RtR3YsXMkZVfa+QOUwYhLW5Et9ZOIQt1LE7J P3b2Mw47qbbf2Bs/WDSEe6bzzK56UShFBkd+HchZ57lXY4g8h75jfjp1d tCO5t+8i5W8WQ6pZ+PGX/fTzEBVaeN+S+EbLv+jD81ooJw87De+URw7Pb IfTXJghe4JEvQ4OpZPs0V8Nzz0me1U7MNjn3zVqjYcrBhDNyLze+qzf6E w==; Authentication-Results: relayus.tnsi.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CsBAAJClZV/xYIEaxcg2NeBsY3DIUqSgKCBQEBAQEBAYELhCIBAQEEAQEBNzQXBAIBCA0EBAEBHwkHJx8JCAEBBAESCBOIFgjXDgEBAQEBAQEBAgEBAQEBAQEBARUEizqFDAaEJwWSYYQph3GDZYJxjwKEG2+BRYEBAQEB X-IPAS-Result: A2CsBAAJClZV/xYIEaxcg2NeBsY3DIUqSgKCBQEBAQEBAYELhCIBAQEEAQEBNzQXBAIBCA0EBAEBHwkHJx8JCAEBBAESCBOIFgjXDgEBAQEBAQEBAgEBAQEBAQEBARUEizqFDAaEJwWSYYQph3GDZYJxjwKEG2+BRYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,434,1427756400"; d="scan'208";a="4669088" Received: from unknown (HELO asbwcexcmbx02.win2k.corp.tnsi.com) ([172.17.8.22]) by relayus.tnsi.com with ESMTP/TLS/AES256-SHA; 15 May 2015 17:05:28 +0100 Received: from asbwcexcmbx01.win2k.corp.tnsi.com (172.17.8.21) by asbwcexcmbx02.win2k.corp.tnsi.com (172.17.8.22) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 15 May 2015 16:03:03 +0100 Received: from asbwcexcmbx01.win2k.corp.tnsi.com ([fe80::f1b8:5d9c:79d4:7f09]) by asbwcexcmbx01.win2k.corp.tnsi.com ([fe80::f1b8:5d9c:79d4:7f09%16]) with mapi id 15.00.1044.021; Fri, 15 May 2015 16:03:03 +0100 From: "Cartwright, Ken" To: Alexander Mayrhofer , "drinks@ietf.org" Thread-Topic: "Substrate Protocol" instead of "Transport Protocol" Thread-Index: AdCPHicMj7vAewJlS6W44FhadFoixwAAgPNQ Date: Fri, 15 May 2015 15:03:02 +0000 Message-ID: <840742d1e8264c9dbc9f71efbb97d0e4@asbwcexcmbx01.win2k.corp.tnsi.com> References: <19F54F2956911544A32543B8A9BDE075467EA137@NICS-EXCH2.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE075467EA137@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.17.100.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [drinks] "Substrate Protocol" instead of "Transport Protocol" X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 15:03:08 -0000 Sound like a good point and a good solution. +1 from me. -----Original Message----- From: drinks [mailto:drinks-bounces@ietf.org] On Behalf Of Alexander Mayrho= fer Sent: Friday, May 15, 2015 10:55 AM To: drinks@ietf.org Subject: [drinks] "Substrate Protocol" instead of "Transport Protocol" All, I'm currently working through the remaining COMMENTs and "near-DISCUSSes" o= n our documents, specifically the Framework document: https://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/ballot/ There was some significant concern about the use of the term "Transport" fo= r an above-layer-4-protocol, sepcifically by Spencer and Martin. Spencer pr= ovided a compromise text, while Martin strongly leans towards changing our = terminology. As Spencer wrote, the term "Substrate" could be used instead = of "Transport". The SOAP document contains 24 instances of the word "transport", while the = framework document contains 54 instances. Therefore, i think it would be re= asonable effort to switch to "Substrate", and that would adress both Spence= r's as well as Martin's comments. Thoughts? Alex _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorized review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From nobody Sun May 17 06:31:13 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68AD1A0263 for ; Sun, 17 May 2015 06:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.433 X-Spam-Level: X-Spam-Status: No, score=0.433 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Z5XIv-jP9n6E for ; Sun, 17 May 2015 06:31:09 -0700 (PDT) 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 305F41A00F3 for ; Sun, 17 May 2015 06:31:09 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t4HDP67I018167; Sun, 17 May 2015 09:31:08 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1udqc31u9n-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 17 May 2015 09:31:08 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.129]) by stntexhc10.cis.neustar.com ([169.254.4.32]) with mapi id 14.03.0158.001; Sun, 17 May 2015 09:31:06 -0400 From: "Ali, Syed Wasim" To: "Cartwright, Ken" Thread-Topic: [drinks] "Substrate Protocol" instead of "Transport Protocol" Thread-Index: AQHQkKW6DczOpLXHnUCqToKKgjy1RQ== Date: Sun, 17 May 2015 13:31:06 +0000 Message-ID: References: <19F54F2956911544A32543B8A9BDE075467EA137@NICS-EXCH2.sbg.nic.at>, <840742d1e8264c9dbc9f71efbb97d0e4@asbwcexcmbx01.win2k.corp.tnsi.com> In-Reply-To: <840742d1e8264c9dbc9f71efbb97d0e4@asbwcexcmbx01.win2k.corp.tnsi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-17_02:2015-05-15,2015-05-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=1.08038578083836e-11 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.999510175003986 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.999510175003986 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.999510175003986 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505170182 Archived-At: Cc: "drinks@ietf.org" Subject: Re: [drinks] "Substrate Protocol" instead of "Transport Protocol" X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 13:31:11 -0000 +1 Sent from my iPhone > On May 15, 2015, at 11:03 AM, Cartwright, Ken wrot= e: >=20 > Sound like a good point and a good solution. >=20 > +1 from me. >=20 > -----Original Message----- > From: drinks [mailto:drinks-bounces@ietf.org] On Behalf Of Alexander Mayr= hofer > Sent: Friday, May 15, 2015 10:55 AM > To: drinks@ietf.org > Subject: [drinks] "Substrate Protocol" instead of "Transport Protocol" >=20 > All, >=20 > I'm currently working through the remaining COMMENTs and "near-DISCUSSes"= on our documents, specifically the Framework document: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_draft-2Dietf-2Ddrinks-2Dspp-2Dframework_ballot_&d=3DAwICAg&c=3DMOptN= lVtIETeDALC_lULrw&r=3Dc982q_qKNPIfj0UrZrP9W283QeLoOWyxJ2JOyD72wXw&m=3DBdHD3= cWWs5RZ_GN-OmlQgLYZ04AhvDJ6goMJophvLdU&s=3DjFwRyhPvmhHyRYHA-EBf5U15y0V5jc-1= oiBxBV1Vhpc&e=3D=20 >=20 > There was some significant concern about the use of the term "Transport" = for an above-layer-4-protocol, sepcifically by Spencer and Martin. Spencer = provided a compromise text, while Martin strongly leans towards changing ou= r terminology. As Spencer wrote, the term "Substrate" could be used instea= d of "Transport". >=20 > The SOAP document contains 24 instances of the word "transport", while th= e framework document contains 54 instances. Therefore, i think it would be = reasonable effort to switch to "Substrate", and that would adress both Spen= cer's as well as Martin's comments. >=20 > Thoughts? >=20 > Alex >=20 > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_drinks&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3Dc982q_qKNPIfj0= UrZrP9W283QeLoOWyxJ2JOyD72wXw&m=3DBdHD3cWWs5RZ_GN-OmlQgLYZ04AhvDJ6goMJophvL= dU&s=3DaRItPurjJs8R5s-tVOPNRsGCv58g8bYfE-f-x8feuVM&e=3D=20 >=20 > ________________________________ >=20 > This e-mail message is for the sole use of the intended recipient(s)and m= ay > contain confidential and privileged information of Transaction Network Se= rvices. > Any unauthorized review, use, disclosure or distribution is prohibited. I= f you > are not the intended recipient, please contact the sender by reply e-mail= and destroy all copies of the original message. >=20 > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_drinks&d=3DAwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3Dc982q_qKNPIfj0= UrZrP9W283QeLoOWyxJ2JOyD72wXw&m=3DBdHD3cWWs5RZ_GN-OmlQgLYZ04AhvDJ6goMJophvL= dU&s=3DaRItPurjJs8R5s-tVOPNRsGCv58g8bYfE-f-x8feuVM&e=3D=20 From nobody Mon May 18 08:24:46 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC94E1A923B for ; Mon, 18 May 2015 08:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.041 X-Spam-Level: X-Spam-Status: No, score=-3.041 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 U_P0kkTQ7sTA for ; Mon, 18 May 2015 08:24:38 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 497851A92B3 for ; Mon, 18 May 2015 08:24:33 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Mon, 18 May 2015 17:24:26 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Mon, 18 May 2015 17:24:21 +0200 From: Alexander Mayrhofer To: "Pete Resnick (presnick@qti.qualcomm.com)" Thread-Topic: Your COMMENTS on draft-ietf-drinks-framework (Pete Resnick) Thread-Index: AdCRYlfHv21SU0a2R+KX26zjta7vnA== Date: Mon, 18 May 2015 15:24:20 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075467F650E@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: Cc: "drinks@ietf.org" Subject: [drinks] Your COMMENTS on draft-ietf-drinks-framework (Pete Resnick) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 15:24:45 -0000 Hello Pete, You submitted the following COMMENTs during the IESG evaluation of draft-ie= tf-drinks-framework - our responses inline marked with "->": 3.2: s/is not approved for use/MUST NOT be used -> changed accordingly. 3.3: s/MUST/need to s/SHOULD/is expected to -> changed accordingly, thanks. 4.1/4.2: s/MUST/will (These are both definitional, not requirements; how co= uld you possibly do otherwise?) -> changed as well. 4.5: Refer to the Security Considerations section for further guidance. -> done. Please use an xref in here in order to refer to the section number. There a= re several of these named references throughout the document. Please fix also 5.2.2, 6.1 (two occurrences), 6.3 (two occurrences), 6.4, 6.5 (two occurrences), 6.6 (two occurrences), 7.1, 7.2, 7.4 (two occurrences), 7.5 (= two occurrences), 7.6, 9.1 (two occurrences) -> I just noted this while going through the document (again), and I have c= hanged The references accordingly. 4.11: As written, this needs a (normative) reference to -spp-protocol-over-soap. You can't have a MUST requirement without a normat= ive reference. -> Yep, you're right, thanks for spotting this. I've added the respective r= eference in section 4. 5.1: I think it's really awful practice to include protocol requirements an= d syntax definitions inside IANA Considerations. IANA Considerations are for *IANA*, not for the implementer and not for the folks entering items in the registry. I strongly suggest moving the syntax requirements and the ABNF fr= om 11.2 into 5.1 and simply reverse the pointer so that 11.2 points to 5.1. -> I have changed the draft accordingly. 5.2: (I'm still trying to figure out how to non-normatively define somethin= g. :-) ) Can name attributes really be non-ASCII? Aren't these all protocol elements, not user-interface items? I am icked-out by having to use toCasef= old, and having to have a reference to specific Unicode version. -> Well.. We had a discussion in the WG Design team long ago, and the gist = was=20 That those "name" elements are very likely also going to be used to label o= bjects=20 e.g. in user interfaces. We then had a hallway discussion in Taipei (yes!) = with a guy called Pete ;) , and he advised us that if those elements are really user-visible,= then they should=20 be internationalized, otherwise we'd get trouble during the IESG evaluation= ;) - I agree that the reference to a specific Unicode version is ... icky, But I would propose "Unicode 6.1 or a newer version of Unicode"? 5.2.1/5.2.2/5.3: I always find this construction bizzarre: "Any conforming specification MUST define...". They're all MUSTs (save a few MAYs in 5.3), = and those MUSTs seem pretty unnecessary. For 5.3, you should simply make the opening paragraph: The following table contains the list of response types that a transport protocol specification needs to provide. An SPPF server MUST implement all of the following at minimum. And then strike "Any conforming specification MUST define a response to indicate that" from all of the entries. Move the MAY bits out of the table,= as those aren't part of the description of each of those response types. It'll shorten things up significantly. -> I have restructured the table. 5.3: o The value for Attribute Value MUST be the value of the data element to which the preceding Attribute Name refers. o Response type "Attribute value invalid" MUST be used whenever an element value does not adhere to data validation rules. What other choice could an implementation make? In other words, if I were t= o violate the first MUST, what do you think I'm going to put in to the attrib= ute value that I need to be instructed that I MUST NOT do? 6.4: hostName: Root-relative host name of the name server. The additional term "root-relative" confused me. Are you somehow trying to = say that these names MUST NOT have a terminating "." (i.e., they must be relati= ve domain names)? If that's the point, then you should probably say that. Otherwise, I would strike "root-relative". An absolute name (with a termina= ting ".") should be OK in this context, yes? -> I *think* that term was created by Ted Hardie because he didn't like tha= t "fully qualified" does=20 Usually not include the trailing dot. What we wanted to say is that "full h= ostnames" are required=20 (not just labels relative to some zone cut), but we didn't want the termina= ting dot to be included.=20 I'll research what RFCs are typically saying - EPP says "... contains the f= ully qualified name of the=20 host object to be created...", I'll probably go for that. 10: OLD Where human-readable languages are used in the protocol, those messages SHOULD be tagged according to [RFC5646]... I think you mean that human-readable *messages* that might be displayed to = the user are to get language tags, but I don't see anywhere in the spec where y= ou produce human-readable messages. Can you point me to an example. If so, you should probably say: NEW Where human-readable messages that are presented to an end user are used in the protocol, those messages SHOULD be tagged with their language according to [RFC5646]... -> The actual "transport" protocol (draft-ietf-drinks-spp-protocol-over-soa= p) contains=20 Messages which could be internationalized. The provisions in the framework = document=20 were intended for those messages. I will change the text according to your = proposal -> The original idea behind "human-readable languages" was that one wouldn'= t need to Tag the languages of eg. the elements in the XML itself (even though they d= efinitely are In a human-readable language, so I guess that was a bad idea in the first p= lace).=20 Also: If tags are absent, the language of the message defaults to "en" (English). That seems like a bad plan. If all of the characters are out of the Arabic script, I'm pretty darn sure that an implicit default language tag of "en" = is unlikely to be helpful to an implementation. I would strike that sentence. -> it's gone. 11.2: See comment on section 5.1 above. -> Moved the formal syntax to section 5.1, created a cross reference. Many thanks for the thorough review! Alex From nobody Mon May 18 08:43:28 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43EB1AC3DC for ; Mon, 18 May 2015 08:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.741 X-Spam-Level: X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 zl2Fvk0GCZf5 for ; Mon, 18 May 2015 08:43:25 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 1E4CF1AC3E1 for ; Mon, 18 May 2015 08:43:24 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Mon, 18 May 2015 17:43:22 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Mon, 18 May 2015 17:43:17 +0200 From: Alexander Mayrhofer To: "mls.ietf@gmail.com" Thread-Topic: Your COMMENTs on draft-ietf-drinks-framework (Martin Stiemerling) Thread-Index: AdCRf4xWvGcnQaTOSkmE2BrZvTVt3w== Date: Mon, 18 May 2015 15:43:16 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075467F753A@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: Cc: "drinks@ietf.org" Subject: [drinks] Your COMMENTs on draft-ietf-drinks-framework (Martin Stiemerling) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 15:43:26 -0000 Hello Martin, Thanks for your IESG evaluation COMMENTs on draft-ietf-drinks-framework. Pl= ease find our responses inline, marked with "->": ---- I have a number of comments and one big near DISCUSS point: The definition of your meaning of " transport protocols" is stated just in Section 4.11 and you mean for instance SOAP. However, SOAP is not a transpo= rt protocol in the sense as the rest of the world AFAIK is using the term transport protocol. A transport protocol is a layer 4 protocol and not something that is running on top. Can you please change your terminology? Otherwise, all my points below become a DISCUSS, as your requirements basic= ally rule out transport protocols to run over. -> We have changed the terminology to "Substrate Protocol", as suggested by= Spencer. - Section "4.4. Authentication" authenticated SPP Client is a Registrar. Therefore, the SPPF transport protocol MUST provide means for an SPPF server to authenticate an SPPF Client. This MUST requirement basically lets you without any transport protocol cho= ice left. None to me known transport protocol is supporting the authentication between client and server. Unless you will wait for TCPINC. Perhaps you mean this: "Therefore, SPPF MUST leverage appropriate mechanisms provided by underlyin= g protocol layers for an SPPF server to authenticate an SPPF Client". -> Ah, well, we've taken a few years to create these drafts (seriously!), s= o, we'd rather not=20 Wait for TCPINC. I can see that this is due to the unclear terminology rega= rding "transport".=20 -> The sentence now reads: " the SPPF substrate protocol MUST provide means for an SPPF server to authenticate an SPPF Client." This will allow to use TLS which is not a transport protocol, but running o= n top of it. In case you have a different defintion of transport protocol, it would be good to state this. - Section "4.6. Confidentiality and Integrity" Therefore, the transport protocol MUST provide means for data integrity protection. -> now reads " Therefore, the substrate protocol MUST provide means for data integrity protection." Similar discuss to the point above: None of the IETF transport protocols is providing means for data integrity protection. So you won't ge too far. - Section "4.9. Request and Response Correlation": Same as the ones before: A transport protocol suitable for SPPF MUST allow responses to be correlated with requests. TCP, UDP and SCTP will not offer this. -> Changed to "substrate protocol" again. In Section "4.2. Request and Response Model" Therefore, a transport protocol for SPPF MUST follow the request- response model by allowing a response to be sent to the request initiator. The last part is worded a bit strange: "allowing a response to be sent..". = How about saying "my ensuring a response to be sent to the..."? -> changed to "substrate" and "ensuring". In Section "4.3. Connection Lifetime": What is in a quantity short and long-lived? This sentence does not make any sense, unless it is state what a short time period for such a protocol and = what a long time period is. -> I've added text that clarifies "short-lived" means sub-seconds to a few = seconds,=20 And that the other extreme of "long-lived" would mean several hours or even= days. I know it's still vague - would that work? In Section "Near Real Time" I am not sure how good or bad one can determine if any protocol is reacting= in near real-time. And what is realtime anyhow? Measured in nano seconds, milliseconds, etc? -> I've added text that "near-real-time" would mean "in the range of a few = multiples of round-trip-times=20 Between client and server". Again, vague - does that work? Thanks, Alex From nobody Tue May 19 00:14:49 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01D41AC436 for ; Tue, 19 May 2015 00:14:47 -0700 (PDT) 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 JdPPONjUbsO4 for ; Tue, 19 May 2015 00:14:45 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FE21ACD37 for ; Tue, 19 May 2015 00:14:45 -0700 (PDT) Received: by wicmc15 with SMTP id mc15so106127107wic.1 for ; Tue, 19 May 2015 00:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dY2u/87MuHOjBa/UJND9hgkp6Zvl9VYU7YsWFM5eX5Q=; b=hgrjszv7PQQUf5aersEFSmqUI/dAWpUnAwNV1mPNpfDIAwYurQtLJW/73VNX4kqwSE gCRw70ysLtJP4jBKvgFNec3wzKSGjd/n+kbmiujs9570Nm8lT0TloxdVgVZyJjwKQkVf FzEb9fCsVtLGJDOEwSX+ZBAYelZVAUH3yTdPq9t5YZIfZKBIH06lXITuhw2ecR820r1E wjk+2JLLGQDpIcVoGnhWk1wxwcNHyYqHhq6wYeSZDz+PO146m6IVO2w4k0ZqdYp1nPEb JmaJJjP7NW9r/EjPjoENxkbkV0mcLuy0Cwjv5KrW6Px9gQy4EEtBBVDDl+cWDn6Izss+ ydLg== X-Received: by 10.181.6.37 with SMTP id cr5mr28669412wid.18.1432019683878; Tue, 19 May 2015 00:14:43 -0700 (PDT) Received: from Martins-MacBook-Pro.local (ip-109-42-1-46.web.vodafone.de. [109.42.1.46]) by mx.google.com with ESMTPSA id w5sm15883588wiz.11.2015.05.19.00.14.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 00:14:43 -0700 (PDT) Message-ID: <555AE289.9020603@gmail.com> Date: Tue, 19 May 2015 09:13:13 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alexander Mayrhofer References: <19F54F2956911544A32543B8A9BDE075467F753A@NICS-EXCH2.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE075467F753A@NICS-EXCH2.sbg.nic.at> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "drinks@ietf.org" Subject: Re: [drinks] Your COMMENTs on draft-ietf-drinks-framework (Martin Stiemerling) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 07:14:47 -0000 Hi Alexander, Thanks for considering my comments and all your proposed changes are addressing my concerns. Thanks, Martin Am 18.05.15 um 17:43 schrieb Alexander Mayrhofer: > Hello Martin, > > Thanks for your IESG evaluation COMMENTs on > draft-ietf-drinks-framework. Please find our responses inline, marked > with "->": > > ---- I have a number of comments and one big near DISCUSS point: > > The definition of your meaning of " transport protocols" is stated > just in Section 4.11 and you mean for instance SOAP. However, SOAP is > not a transport protocol in the sense as the rest of the world AFAIK > is using the term transport protocol. A transport protocol is a layer > 4 protocol and not something that is running on top. > > Can you please change your terminology? Otherwise, all my points > below become a DISCUSS, as your requirements basically rule out > transport protocols to run over. > > -> We have changed the terminology to "Substrate Protocol", as > suggested by Spencer. > > - Section "4.4. Authentication" > > authenticated SPP Client is a Registrar. Therefore, the SPPF > transport protocol MUST provide means for an SPPF server to > authenticate an SPPF Client. > > This MUST requirement basically lets you without any transport > protocol choice left. None to me known transport protocol is > supporting the authentication between client and server. Unless you > will wait for TCPINC. > > Perhaps you mean this: "Therefore, SPPF MUST leverage appropriate > mechanisms provided by underlying protocol layers for an SPPF server > to authenticate an SPPF Client". > > -> Ah, well, we've taken a few years to create these drafts > (seriously!), so, we'd rather not Wait for TCPINC. I can see that > this is due to the unclear terminology regarding "transport". > > -> The sentence now reads: " the SPPF substrate protocol MUST provide > means for an SPPF server to authenticate an SPPF Client." > > This will allow to use TLS which is not a transport protocol, but > running on top of it. In case you have a different defintion of > transport protocol, it would be good to state this. > > - Section "4.6. Confidentiality and Integrity" Therefore, the > transport protocol MUST provide means for data integrity protection. > > -> now reads " Therefore, the substrate protocol MUST provide means > for data integrity protection." > > Similar discuss to the point above: None of the IETF transport > protocols is providing means for data integrity protection. So you > won't ge too far. > > - Section "4.9. Request and Response Correlation": > > Same as the ones before: A transport protocol suitable for SPPF MUST > allow responses to be correlated with requests. > > TCP, UDP and SCTP will not offer this. > > -> Changed to "substrate protocol" again. > > In Section "4.2. Request and Response Model" > > Therefore, a transport protocol for SPPF MUST follow the request- > response model by allowing a response to be sent to the request > initiator. > > The last part is worded a bit strange: "allowing a response to be > sent..". How about saying "my ensuring a response to be sent to > the..."? > > -> changed to "substrate" and "ensuring". > > In Section "4.3. Connection Lifetime": > > What is in a quantity short and long-lived? This sentence does not > make any sense, unless it is state what a short time period for such > a protocol and what a long time period is. > > -> I've added text that clarifies "short-lived" means sub-seconds to > a few seconds, And that the other extreme of "long-lived" would mean > several hours or even days. I know it's still vague - would that > work? > > In Section "Near Real Time" I am not sure how good or bad one can > determine if any protocol is reacting in near real-time. And what is > realtime anyhow? Measured in nano seconds, milliseconds, etc? > > -> I've added text that "near-real-time" would mean "in the range of > a few multiples of round-trip-times Between client and server". > Again, vague - does that work? > > Thanks, Alex > From nobody Wed May 20 05:05:24 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F9C1A0007 for ; Wed, 20 May 2015 05:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 830-JZoWBELX for ; Wed, 20 May 2015 05:05:19 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 85B601A0006 for ; Wed, 20 May 2015 05:05:17 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Wed, 20 May 2015 14:05:16 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Wed, 20 May 2015 14:05:13 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: SOAP document - Gen-ART comment regarding minorVer.. Thread-Index: AdCS9TaLxxvH2qKeS6C5SJLIuf6+7w== Date: Wed, 20 May 2015 12:05:13 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075467F86BE@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: Subject: [drinks] SOAP document - Gen-ART comment regarding minorVer.. X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 12:05:23 -0000 Hello, Roni Even performed the Gen-ART review of draft-ietf-drinks-spp-protocol-ov= er-soap (see https://www.ietf.org/mail-archive/web/ietf/current/msg91403.ht= ml). Specifically, he asked about the definition of the minorVer element: "There are two schemas used, the sppf:base and sppf:soap each have a versio= n number. When talking about supported version and about response codes on = supported version, is it referring to the base or soap version? There is so= me text in the minorVer section but it is not clear enough." Our definition in the document is: minorVer: Zero or one minor version identifier, indicating the= minor =20 version of the SPPF API that the client is attempting to use.= This is used in conjunction with the major version identifier in the XML namespace to identify the version of SPPF that the cl= ient=20 is using. If the element is not present, the server assumes = that=20 the client is using the latest minor version supported by the= SPPF server for the given major version. The versions supported by= a=20 given SPPF server can be retrieved by the client using the=20 Get Server Details Operation described in . I have to admit, I can't remember what the intention was. Could someone hel= p me creating updated text that fixes Roni's feedback? Also, the definition is repeated in the text several times. I would move th= e definition to a dedicated section, and then only refer to that section in= the individual objects - I guess that would be fine with the other authors= ? Thanks, Alex From nobody Wed May 20 06:00:08 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166461A036E for ; Wed, 20 May 2015 06:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.741 X-Spam-Level: X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 ArQbiK5PHkWR for ; Wed, 20 May 2015 06:00:04 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 DF28F1A0368 for ; Wed, 20 May 2015 06:00:03 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Wed, 20 May 2015 15:00:02 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Wed, 20 May 2015 14:59:57 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: Gen-ART of draft-ietf-drinks-spp-protocol-over-soap: ResultCodeType namespace issues? Thread-Index: AdCS/MH7tMcy08AETneynqYl4lOW0g== Date: Wed, 20 May 2015 12:59:56 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075467F8773@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: Subject: [drinks] Gen-ART of draft-ietf-drinks-spp-protocol-over-soap: ResultCodeType namespace issues? X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 13:00:06 -0000 I'm working on Roni Even's second comment on the draft, which is: "The "complexType name=3D"ResultCodeType" is defined in multiple subsection= s (7.2.1.2 , 7.2.2.2 , ...) but not in all places, should be specified only= once or in all. Also the definitions in section 7 are not consistent with = the ones in section 9 which is the formal definition." Looking closer at the references of ResultCodeType, I noticed that the Type= is included as elements in the following way: Besides the point that Roni makes (repetitive definition of the type, and l= ack of consistency with the formal definition), I think that we also are us= ing the wrong namespace to refer to that type? The type is actually defined= in the SOAP document's XML, which has the following namespace definitions: Therefore, I think the reference should rather use the *"sppfs"* namespace.= . Could please someone doublecheck this and either confirm my suspicion (or= explain why I'm wrong)? Thanks, Alex