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

[Mike Jones <[e-mail]>]

+1

There are plenty of contexts, especially for non-Internet connect systems (yes, these still exist :-) ) where account identifiers are strictly local.  The domain portion of the acct: identifier should be optional.

				-- Mike

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Phillip Hallam-Baker
Sent: Monday, July 02, 2012 8:42 AM
To: Melvin Carvalho
Cc: Graham Klyne; [e-mail]; Murray S. Kucherawy
Subject: Re: [apps-discuss] The acct: scheme question

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. 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 <[e-mail]> wrote:
>
>
> On 2 July 2012 15:31, Phillip Hallam-Baker <[e-mail]> 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 <[e-mail]> 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>> _______________________________________________
>> apps-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>



--
Website: http://hallambaker.com/
_______________________________________________
apps-discuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/apps-discuss