Re: [apps-discuss] The acct: scheme question

William Mills <> Tue, 03 July 2012 04:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE45B11E811C for <>; Mon, 2 Jul 2012 21:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.398
X-Spam-Status: No, score=-17.398 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_DEF_WHITELIST=-15]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8p6a7MXXSzsO for <>; Mon, 2 Jul 2012 21:02:03 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 6982611E80EC for <>; Mon, 2 Jul 2012 21:02:03 -0700 (PDT)
Received: from [] by with NNFMP; 03 Jul 2012 04:02:09 -0000
Received: from [] by with NNFMP; 03 Jul 2012 04:02:09 -0000
Received: from [] by with NNFMP; 03 Jul 2012 04:02:09 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 58357 invoked by uid 60001); 3 Jul 2012 04:02:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ginc1024; t=1341288128; bh=z8I+nIVxoYcQkH8EhijHtjVWvh2AT+JIrGBhuZYDunE=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=V6ny+FjHKZ7YgMlVQmNohK2xNqIC4g6tbr3l2PY5dyo0JgYBy4xBPoK5xe6h1qg0gVA3Yv0jdy2JQjyiSU9MFDi0FTmTGNBxPy0OuRj2NWfUF763jZmc2Q/JcpRK+kF7BeIYeq9PqeXp7A2Y9qgtg94wSUN+1KGrFYz5sBrnacQ=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024;; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dUslfSS/kfh5envH8AZVoY5oDWjAMIkArlQnlAIKxTsS8JUQPFI9xYbDiY8tpwc6wxZytHMvjlTwKSDCFM9U5Cc51rLsOMlIfIGXqnSpoDdCw/x9HsBgkiMIH3o6YS2DA0b1cR0WYcGSXksrEnydHVYL/AIbdWZ/5y4gm66cVo8=;
X-YMail-OSG: z6z2L0oVM1mFBJhvjm8G4uMP9tKf.q3WYKbhZ_63vjwhZiL DHtr.NNTAEJnsOvlgFp4O6w6CZvsmtRX5ZsNGHZrxUmmGcudkChswqDFPcVJ isPJBvCV5SDbVkgBCdTnZRE_dj.i6sriIa3mpxWTVcDDnERIp9dbMyykeQms TIJAaBoIy9Z8AimtW5pUdrTZvy2wDtMuYGY_wHhGD1G3c22Y2a6DJVVdY4RL pkwFLC6R0qCQBHIDLiQrheeEAjRfxQ_mTtw353C8EbEljsykJWsu6RlMbmLb gTWGpSYDORRAsXMoA5xQ0X2LiosLh_GwhamKXXEr0gu8JKQDdAu4YovfjRi. T1_1VZ6dohQBTMHaw6.Zxcm2FYRXgIApfzUbEHpmL.g9.clVrqwbjIaRRk4g w8c7Gm0Kbz.APjsit5RE_4CNM8kbRhyulh7yq4RiPagy275o6lpoSd6by
Received: from [] by via HTTP; Mon, 02 Jul 2012 21:02:08 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/
References: <> <> <> <> <043201cd54a5$79f2e170$6dd8a450$> <> <> <> <> <> <> <> <> <> <> <> <! om> <>
Message-ID: <>
Date: Mon, 02 Jul 2012 21:02:08 -0700
From: William Mills <>
To: "\"Martin J. Dürst\"" <>, Phillip Hallam-Baker <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1036955950-1144451342-1341288128=:53630"
Cc: Graham Klyne <>, "" <>, "Murray S. Kucherawy" <>
Subject: Re: [apps-discuss] The acct: scheme question
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <>
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Jul 2012 04:02:04 -0000

Peter's point about complexity for parsing is significant if we don't have a good reason to need it.  The logic for optional is something like:

-    is there an @ sign?
    -    no: the whole thing is a local user identifier
    -    yes: does the domain part parse correctly as a domain?
        -    no: the whole thing is a local user id
        -    yes: this is a proper compound identifier

Which is kind of a PITA if you don't need it.  If we do feel like we want purely local identifiers we could let the domainpart be empty, with an @ at the end.  That would fix the parsing, but probably make people cringe.

> From: ""Martin J. Dürst"" <>
>To: Phillip Hallam-Baker <> 
>Cc: Graham Klyne <>; "" <>; Murray S. Kucherawy <> 
>Sent: Monday, July 2, 2012 8:53 PM
>Subject: Re: [apps-discuss] The acct: scheme question
>After reading Phillip's mails, I agree with him that it makes sense to 
>allow an account id without a domain name. The document should be clear 
>that such use won't work internet-wide, and should be avoided wherever 
>possible. It should also be clear that relative resolution won't work, 
>because it's the wrong syntax.
>Regards,    Martin.
>On 2012/07/03 7:53, Phillip Hallam-Baker wrote:
>> On Mon, Jul 2, 2012 at 1:57 PM, Bob Wyman<>  wrote:
>>> On Mon, Jul 2, 2012 at 11:42 AM, Phillip Hallam-Baker<>
>>> wrote:
>>>> I think Tim regrets having been argued out of a lot of positions
>>>> relating to naming that he was subsequently proved right on.
>>>> Naming issues are an area where a lot of people have strong opinions
>>>> that really turn out to be a matter of taste rather than grounded in
>>>> semiotics.
>>>> The whole business of differentiating URLs and URNs as distinct
>>>> classes was bogus. Once the locator scheme has caching, a URL becomes
>>>> a name. Once an application provides a default action for a name (e.g.
>>>> look it up on Amazon) then a name becomes a locator.
>>>> A URI scheme should simply provide people with a well defined syntax
>>>> that allows them to express the concepts that applications that need
>>>> to interoperate need to exchange references to. Trying to decide how
>>>> people should use the identifiers is counterproductive. Trying to
>>>> enforce particular approaches is destructive.
>>>> The vast majority of computer systems that use accounts do not bind
>>>> them to domain names. So there is a place in the acct: scheme for
>>>> unbound references.
>>> It seems to me that an unbound acct: name would be useful only in a "local"
>>> case, not generally useful between otherwise inter-working machines. As I
>>> understand it, the IETF normally limits its scope to those issues that
>>> relate to interworking between systems. Thus, it seems to me that a feature
>>> that is purely local and does not, in fact, facilitate inter-working is one
>>> that should not appear in an IETF document. This, of course, would not
>>> prevent anyone from building a system, or even set of systems, that made
>>> private agreements or used private conventions concerning the use of acct:
>>> names which were unbound or contained no domain part. But, that is not, I
>>> think, a matter which need concern anyone while wearing an IETF standards
>>> hat.
>> That is not the case at all. IETF protocols have always been designed
>> to support local use in addition to Internet use where that makes
>> sense.
>> In this case accounts are currently a locally defined resource and the
>> objective is to make them an Internet resource. The transition from
>> one to the other requires a spec that can work equally well in both
>> circumstances.
>> Deployment is something that should always concern us. Scope arguments
>> are only ever relevant to the question of whether the IETF should
>> consider a problem in the first place. Once the problem is accepted
>> the design must address all the use cases and requirements that
>> reasonably apply whether they are deemed to be in IETF scope or not.
>> And in any case I think that you are completely wrong on the question
>> of scope in the first place. Please provide a citation for your claim
>> if you want to continue the argument.
>apps-discuss mailing list