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

That particular description comes six years after the argument I was
referring to. But note the following:

-----
In this case, the links between these documents are "relative URIs".

What happens then is that the relative URI, which only has the locally
different part of the URI in it, is handed back to what in the diagram
I have called the "application", to be turned into an absolute URI by
being combined with the absolute URI of the resource, which the
application has remembered.

Note that the application is aware of the absolute URI but still the
resource does not have to.
------

Of course an application has to be able to be aware of the full
context of a partial acct: URI just as a web browser has to know how
to resolve a hypertext fragment. But the point is that these do not
need to be fully specified in resources.

This comes in very handy when testing Web content out before release
of a version of the site to the public. I expect that all the
practicalities that relate to content in test environments relate to
accounts as well. Even more so because a tester will frequently have
rather more access in a test environment than they would be allowed in
a production one.

On Mon, Jul 2, 2012 at 9:49 AM, Graham Klyne <GK@ninebynine.org> wrote:
> 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
>>
>>
>>
>>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

-- 
Website: http://hallambaker.com/