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

[Bob Wyman <[e-mail]>]

On Mon, Jul 2, 2012 at 11:42 AM, Phillip Hallam-Baker <[e-mail]>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
> <[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
>