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

Bob's argument makes sense to me.  I withdraw my own argument for making domain optional.

>________________________________
> From: Bob Wyman <bob@wyman.us>
>To: Phillip Hallam-Baker <hallam@gmail.com> 
>Cc: Graham Klyne <GK@ninebynine.org>; "apps-discuss@ietf.org" <apps-discuss@ietf.org>; Murray S. Kucherawy <msk@cloudmark.com> 
>Sent: Monday, July 2, 2012 10:57 AM
>Subject: Re: [apps-discuss] The acct: scheme question
> 
>
>
>
>
>On Mon, Jul 2, 2012 at 11:42 AM, Phillip Hallam-Baker <hallam@gmail.com> 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.
>
>
> 
>I expect that practice to go down over time. I
>>expect that deployment of technology that uses acct: will encourage
>>that. But trying to force the issue by excluding unbound accounts is
>>only going to hurt that transition by making acct: a special case of
>>account objects rather than a technology that can ease the transition.
>>
>>
>>
>>
>>On Mon, Jul 2, 2012 at 9:42 AM, Melvin Carvalho
>><melvincarvalho@gmail.com> wrote:
>>>
>>>
>>> On 2 July 2012 15:31, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>>>>
>>>> Relative URIs have existed from the start. That is one of the reasons
>>>> they had to be renamed 'uniform' rather than universal.
>>>>
>>>> The idea is to have a uniform means of representing a name. If that
>>>> name is ambiguous, then the URI form needs to be able to capture that.
>>>>
>>>> I don't think it helps in the slightest to argue over whether
>>>> /fred.html is a URI or a URI fragment. Tim's original proposal is in
>>>> my view rather better thought out than what others have proposed as
>>>> 'improvements'. A name is merely a label for a concept and every URI
>>>> is a name, some happen to be resolvable via a default protocol, others
>>>> not, thats all.
>>>>
>>>>
>>>> Incompletely specified account names are inevitable. If you want to
>>>> use SAML or the like in a Windows environment then the Windows domain
>>>> is not bound to a unique DNS address and picking a random one is only
>>>> going to confuse matters.
>>>>
>>>> An acct: name that does not have a domain name part is going to have
>>>> to be resolved in the same fashion as relative URIs are - by reference
>>>> to context and local state. I don't see anything wrong in that. In the
>>>> context of accounts, a domain name is not completely unambiguous
>>>> unless you also have time.
>>>>
>>>>
>>>> The real world is a fuzzy place. Trying to cope with the fuzzyness and
>>>> ambiguity by wishing it away only leads to broken specs. Accounts have
>>>> only recently come to be understood to have an intrinsic domain
>>>> component. It is better to accept that fact and to build
>>>> infrastructure that addresses the need than to pretend that the need
>>>> can be magicked away.
>>>>
>>>> People who don't have a domain are going to drop it in any case. We
>>>> saw the same thing happen with the news: and nntp: URL. Tim thought
>>>> that the USENET space was uniform and tried to establish a URL that
>>>> didn't have the domain name. Engineers trying to solve real world
>>>> problems then added it back in because there is more to NNTP than
>>>> USENET.
>>>
>>>
>>> I enjoyed reading this.  Just a remark regarding universal vs uniform.
>>>
>>> FWIW, Tim is on record saying that he regrets not insisting to the IETF,
>>> that the original 'Universal' should be used in URI, instead of changed form
>>> 'Uniform'.  Depending on which circles you're in, I think informally, the
>>> two terms are used pretty interchangeably, these days.
>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jul 2, 2012 at 7:55 AM, Graham Klyne <GK@ninebynine.org> wrote:
>>>> > On 01/07/2012 23:02, Peter Saint-Andre wrote:
>>>> >>
>>>> >> On 7/1/12 9:38 AM, William Mills wrote:
>>>> >>>
>>>> >>> Section 4.3:  '"@" domainpart' should be optional.  It's reasonable
>>>> >>> to think this might be used with local account identifiers that
>>>> >>> don/t/need have a domain.
>>>> >>
>>>> >>
>>>> >> Making the domain name of the service provider implicit seems
>>>> >> ill-advised to me. What's the harm of including the domainpart?
>>>> >
>>>> >
>>>> > +1
>>>> >
>>>> > (URIs are intended to be a global namespace.)
>>>> >
>>>> > #g
>>>> > --
>>>> >
>>>> > _______________________________________________
>>>> > apps-discuss mailing list
>>>> > apps-discuss@ietf.org
>>>> > https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>
>>>>
>>>>
>>>> --
>>>> Website: http://hallambaker.com/
>>>> _______________________________________________
>>>> apps-discuss mailing list
>>>> apps-discuss@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>
>>>
>>
>>
>>
>>--
>>Website: http://hallambaker.com/
>>_______________________________________________
>>apps-discuss mailing list
>>apps-discuss@ietf.org
>>https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>
>_______________________________________________
>apps-discuss mailing list
>apps-discuss@ietf.org
>https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>