Re: [secdir] Secdir review of draft-ietf-6man-uri-zoneid-05

Brian E Carpenter <> Wed, 28 November 2012 07:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7758121F845B; Tue, 27 Nov 2012 23:50:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.691
X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KYd8o0Z3eExv; Tue, 27 Nov 2012 23:50:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4B56021F8458; Tue, 27 Nov 2012 23:50:49 -0800 (PST)
Received: by with SMTP id dr13so2539934wgb.13 for <multiple recipients>; Tue, 27 Nov 2012 23:50:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Q9pUHFw6YmXrn9N8JnmY2t9NulPWLHRMXrJC3cpNh98=; b=W8isUYeECr5MIAgkKqQwUerFV3+m6K6KuMQw6mOgFE7eu6FHHjo7kfqNIr/fa1d4d8 zzyC5howkNJ0UMOgX2qBIXj3TZXn925eq6ZbmiPAdBLBPB0R1pG2FowXCZPXIqrht5UT twzoqj7a31W4xipe4YLt3V6jsx6eo2qPxjc5+qg2q/697oacitGJcueIcsaIiGCr/o5r YBEMZxAPj1CVzkz8iw2KY+uLBWGlK2W0Lt7hQNUalvRCOKVLm5BMcB9k9BqyPFuaRCJu gYAuWbMbY5faaK/m6/8FOoI2XDNo4IZp8E4yK8tQU0Gt+lJ1ZH3FV8cYHxCbrch4U4/G JRVg==
Received: by with SMTP id hs4mr27649425wib.1.1354089048074; Tue, 27 Nov 2012 23:50:48 -0800 (PST)
Received: from [] ( []) by with ESMTPS id hv4sm5847925wib.0.2012. (version=SSLv3 cipher=OTHER); Tue, 27 Nov 2012 23:50:47 -0800 (PST)
Message-ID: <>
Date: Wed, 28 Nov 2012 07:50:50 +0000
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Radia Perlman <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "" <>, Barry Leiba <>, The IESG <>, "" <>
Subject: Re: [secdir] Secdir review of draft-ietf-6man-uri-zoneid-05
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Nov 2012 07:50:50 -0000

On 28/11/2012 00:14, Radia Perlman wrote:
> On Fri, Nov 23, 2012 at 6:50 AM, Brian E Carpenter <
>> wrote:
>> On 23/11/2012 14:26, Barry Leiba wrote:
>>>> The WG reached consensus on a SHOULD-based version. The whole issue
>>>> of browser behaviour is contentious, so changing to MUST would be
>>>> a WG issue, above my pay grade as a document editor. I will wait
>>>> for instructions.
>>> Could you
>>> 1: give us some background on the discussion that resulted in SHOULD
>>> instead of MUST, and
>> I don't recall it being explicitly discussed - what I meant is that
>> this is the text that got through WG last call and post-last-call
>> discussion, without dissent.
> Often, in my observation, lack of discussion doesn't necessarily mean
> people are happy with the idea.  It often (usually?) means they haven't
> read it.
> I think it would be good to have an explicit discussion in the WG, not on
> the entire draft, but on specifically, whether the syntax should be
> standardized so that the same syntax works the same on all implementations,
> or whether there is some reason why it's important for implementers to have
> flexibility in how they interpret the string, and it's not so important
> that URIs work differently with different implementations.  I'd be more
> convinced that people want it this way if there was discussion on the
> mailing list, focusing people exactly on this issue.  (and I'm also curious
> about why the flexibility is important).

I honestly think that discussing that in 6man is pointless. The issue is
the one I already raised on the IETF list: the user input box on a browser
is one thing, the URI on the wire is another, and in between there is
a heuristic. I don't see what a single IETF WG can do about this other
than bemoaning it, because each browser implementer comes up with their
own heuristic. (I certainly didn't realise how annoying this is before
working on this draft.)


> Radia
>>> 2: consider adding explanations of when it would be appropriate to not
>> do a
>> Yes, this is one of the things I look for when reviewing documents, too ;-)
>>> For 2, above, there's a great difference between "SHOULD do x unless
>>> there's some reason that it's impossible in this implementation" and
>>> "SHOULD do x unless you don't happen to agree with it."  I'd like to try
>> to
>>> tease those apart.
>> I'm not a browser implementor, but as far as I can tell, there is a strong
>> tendency in that community to respect the law of least user astonishment,
>> so my very personal interpretation is "you SHOULD do this unless experience
>> shows that it will confuse the user." However, I think the real
>> interpretation
>> in this case is closer to your first one - do this, because it helps the
>> user, unless your implementation makes this unreasonable.
>> Very much IMHO.
>>     Brian