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

On 02/07/2012 14:31, Phillip Hallam-Baker wrote:
> Relative URIs have existed from the start. That is one of the reasons
> they had to be renamed 'uniform' rather than universal.

Strictly, there are no relative URIs.  There are, however, relative URI 
*references* that are resolved to URIs following rules set out in RFC 3986 
(http://tools.ietf.org/html/rfc3986#section-5.2).

The distinction here traces all the way back to Tim's original proposals (or as 
near as I have seen); cf. http://www.w3.org/DesignIssues/Model.html (the section 
of document sets and relative addressing, *not* the section on fragment 
identifiers, which is a completely different issue).  The terminological 
clarification came later.

#g
--

> 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.
>
>
>
> 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
>
>
>