[drinks] SOAP document - Gen-ART comment regarding minorVer..

Alexander Mayrhofer <alexander.mayrhofer@nic.at> Wed, 20 May 2015 12:05 UTC

Return-Path: <alexander.mayrhofer@nic.at>
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 <drinks@ietfa.amsl.com>; 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 <drinks@ietfa.amsl.com>; 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 <drinks@ietf.org>; 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 <alexander.mayrhofer@nic.at>
To: "drinks@ietf.org" <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: <http://mailarchive.ietf.org/arch/msg/drinks/XZs57KjaPaHnW40utDZuQbyZGc8>
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 <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks/>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=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-over-soap (see https://www.ietf.org/mail-archive/web/ietf/current/msg91403.html).

Specifically, he asked about the definition of the minorVer element:

"There are two schemas used, the sppf:base and sppf:soap each have a version number. When talking about supported version and about response codes on supported version, is it referring to the base or soap version? There is some 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  
              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 client 
              is using.  If the element is not present, the server assumes that 
              the client is using the latest minor version supported by the SPPF
              server for the given major version. The versions supported by a 
              given SPPF server can be retrieved by the client using the 
              Get Server Details Operation described in <xref target="servermenuopn"/>.

I have to admit, I can't remember what the intention was. Could someone help me creating updated text that fixes Roni's feedback?

Also, the definition is repeated in the text several times. I would move the 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