Re: [apps-discuss] Appsdir review of draft-ietf-geopriv-relative-location

ht@inf.ed.ac.uk (Henry S. Thompson) Tue, 28 May 2013 09:10 UTC

Return-Path: <ht@inf.ed.ac.uk>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967E421F9345; Tue, 28 May 2013 02:10:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3VB7guoTZxH; Tue, 28 May 2013 02:10:11 -0700 (PDT)
Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCAD21F92E8; Tue, 28 May 2013 02:10:09 -0700 (PDT)
Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r4S99p0X014278; Tue, 28 May 2013 10:09:56 +0100 (BST)
Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r4S99m3n016478; Tue, 28 May 2013 10:09:48 +0100
Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r4S99oqM004679; Tue, 28 May 2013 10:09:50 +0100
Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r4S99nH4004675; Tue, 28 May 2013 10:09:49 +0100
X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: Martin Thomson <martin.thomson@skype.net>
References: <f5bmwsxnqsr.fsf@calexico.inf.ed.ac.uk> <88EA7D224AA4F24F9D7628368F7572A911BE62E0@TK5EX14MBXC254.redmond.corp.microsoft.com>
From: ht@inf.ed.ac.uk
Date: Tue, 28 May 2013 10:09:49 +0100
In-Reply-To: <88EA7D224AA4F24F9D7628368F7572A911BE62E0@TK5EX14MBXC254.redmond.corp.microsoft.com> (Martin Thomson's message of "Wed\, 8 May 2013 21\:05\:39 +0000")
Message-ID: <f5bbo7vv5b6.fsf@calexico.inf.ed.ac.uk>
User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102
Cc: "draft-ietf-geopriv-relative-location.all@tools.ietf.org" <draft-ietf-geopriv-relative-location.all@tools.ietf.org>, "appsdir@ietf.org" <appsdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, Brian Rosen <br@brianrosen.net>
Subject: Re: [apps-discuss] Appsdir review of draft-ietf-geopriv-relative-location
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 May 2013 09:10:16 -0000

Martin Thomson writes:

> HST wrote:
>>    Ah, repeated re-readings have uncovered the origin of the problem,
>>    further back:
>> 
>>      "A client that does understand this extension will interpret the
>>       location within the relative element as a refinement of the
>>       baseline location, which gives the reference location for the
>>       relative offset."
>> 
>>    I read that the first five times as if it were bracketed like this:
>> 
>>       [a refinement of [the baseline location, which gives the
>>        reference location for the relative offset]].
>> 
>>    But you mean it as if it were bracketed like this:
>> 
>>     [a refinement of the baseline location], [which gives the
>>        reference location for the relative offset].
>> 
>>    So, I suggest you rephrase the whole sentence along the following
>>    lines:
>> 
>>      "A client that does understand this extension will interpret the
>>       location within the relative element as a refinement of the
>>       baseline location.  The resulting refined location then gives
>>       the reference location for the relative offset."
>> 
>>   With that change, the paragraph containing the first quote above
>>   (the para beginning "The baseline location SHOULD be general
>>   enough") is comprehensible, but still very dense.  I know
>>   illustrations are hard when one is restricted to ASCII-art, but a
>>   pair of examples would be a great help here, where one obeys the
>>   rules, and is not understood wrongly by a non-extension-supporting
>>   app, but the other breaks the rules, and therefore liable to be
>>   interpreted wrongly by such an app.
>> 
>>   And, finally, perhaps just _after_ the example now at the end of
>>   this section, just a brief gloss along the lines of
>> 
>>     The baseline location, given by the first ca:civicAddress element,
>>     the first child of the gp:location-info, is a street address, to
>>     the level of detail of the house number (123).  The reference
>>     location is [now the front door, something else if you fix the 5.1
>>     issue below].  The actual location, which is still within the
>>     baseline building, is a point 100m east and 50m north [?] of the
>>     front door.
>
> Oh.  That's a bigger issue than you make out.  Baseline != reference.

Indeed.  As I tried to explain above, I _finally_ figured that out,
but the text doesn't make it easy.  That's why I suggested a diagram.

>>   4.11.1
>> 
>>     "An 'http:' or 'https:' URL MUST be used unless . . ."
>> 
>>   Wouldn't it be more in the spirit of 2119 to say "A URI with scheme
>>   other than 'http:' or 'https:' SHOULD NOT be used unless" ?
>
> "SHOULD" is a weasel-word that SHOULD be avoided.  I like to reserve SHOULD for cases where I am not providing a clear description of the exception cases.  Most times, MUST works perfectly well if properly qualified.  As I believe this is.

Your call.

>>   6. Schema Definition
>> 
>>   The repeated pattern used for complex type definition in this schema
>>   doc is[[MT]]  ...
>>   This is overly . . . complex and invites confusion, [[MT]] ...
>>   Please simplify all your complex type definitions along these lines.
>
> I'm going to hold the line on this point.  XML Schema defines two
> ways to do the same thing and this draft consistently uses the form
> that permits other uses than complex type restrictions of the
> ur-type.  I see no good reason to switch to the syntactic sugar
> variant.

Your gun, your foot, your bullet.  You will just cause people to
scratch their heads and waste time trying to understand why you used
10 words where one would do.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]