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

From: William Mills <[email-masked]>
Date: Sun, 1 Jul 2012 08:38:31 -0700 (PDT)

As susquepedalian as I frequently am, I would change 'discussants' in section 2 to "working group".

section 3 para 3 "It is not assumed that an entity will necessarily be able to interact with a user's account using any particular application protocol, such as email...", I understand this but email isn't a protocol, SMTP is for example.  Maybe change "email" to SMTP there?  

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.

Regards,

-bill

----- Original Message -----
> From: Peter Saint-Andre <[email-masked]>
> To: Graham Klyne <[email-masked]>
> Cc: [email-masked]; Murray S. Kucherawy <[email-masked]>
> Sent: Saturday, June 30, 2012 8:09 PM
> Subject: Re: [apps-discuss] The acct: scheme question
> 
> On 6/28/12 10:53 AM, Peter Saint-Andre wrote:
>>  On 6/28/12 5:09 AM, Graham Klyne wrote:
>>>  On 28/06/2012 08:28, Melvin Carvalho wrote:
>>>>  Should acct: be rejected, we can simply use mailto: as per SWD. 
>>>>  Similarly
>>>>  you could simply use ?acct=user@host as has been suggested.
>>> 
>>>  Since my comments with reviewer hat on have been cited, I feel I should
>>>  summarize my personal feelings about the specification of the acct: 
> scheme.
>>> 
>>>  *Reviewer hat OFF*
>>> 
>>>  Roughly, I think the acct: scheme does provide a useful, possibly 
> minor,
>>>  purpose that is not served by other URI schemes, and as such it has
>>>  reasonable claim to meet the bar for registering a new scheme.  But I
>>>  think the description of the acct: scheme in the WebFinger document 
> does
>>>  a poor job of explaining this; i.e. I think there is a document quality
>>>  issue here around the acct: scheme registration/specification.
>>> 
>>>  I've had private exchanges with one of the document editors, but I 
> don't
>>>  think my suggestions have been reflected in the current draft.  In
>>>  summary, what I think is not as clear as it should be in the scheme
>>>  registration includes:
>>>  * what does an acct URI identify
>>>  * how are acct URIs allocated; what's the assignment delegation 
> structure?
>>>  * how should an acct: URI be dereferenced?  (e.g. if one were used as a
>>>  link in a web page, how should it be handled?).
>>> 
>>>  I suspect that most of this information can be inferred if one has a
>>>  detailed knowledge of WebFinger protocol, but for an average Joe web
>>>  developer I don't think that's really helpful.
>>> 
>>>  I don't think this is a sufficiently important issue for me to 
> engage
>>>  more actively with the discussion.
>> 
>>  Graham, I think you're right about the fact that these matters are
>>  underspecified. I hereby offer to propose some text, and will do that in
>>  the next few days.
> 
> I went beyond proposing text and decided to write a standalone I-D:
> 
> http://datatracker.ietf.org/doc/draft-saintandre-acct-uri/
> 
> Graham, I think that text answers the questions you posed, hopefully in
> an accurate way.
> 
> Feedback is welcome.
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 01 Jul 2012 16:02:53 -0600

> section 2 to "working group".

Those discussions far predated any consideration at the IETF.

> section 3 para 3 "It is not assumed that an entity will necessarily
> be able to interact with a user's account using any particular
> application protocol, such as email...", I understand this but email
> isn't a protocol, SMTP is for example.  Maybe change "email" to SMTP
> there?

Sure.

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

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: William Mills <[email-masked]>
Date: Sun, 1 Jul 2012 17:44:29 -0700 (PDT)

----- Original Message -----
> To: William Mills <[email-masked]>
> Cc: Graham Klyne <[email-masked]>; "[email-masked]" <[email-masked]>; Murray S. Kucherawy <[email-masked]>
> Sent: Sunday, July 1, 2012 3:02 PM
>>  As susquepedalian as I frequently am, I would change 'discussants' 
> in
>>  section 2 to "working group".
> 

I just think it's something that won't be needed in some cases.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 01 Jul 2012 21:31:44 -0600

On 7/1/12 6:44 PM, William Mills wrote:
>> Cc: Graham Klyne <[email-masked]>; "[email-masked]"
> <[email-masked]>; Murray S. Kucherawy <[email-masked]>

With all due respect, I think your suggestion is nonsensical. If I work
at example.com and I want to send an email message to my co-worker Bill,
is the URI for me mailto:bill instead of mailto:[email-masked] (as it
would be for someone working at example.net)?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: John Bradley <[email-masked]>
Date: Sun, 1 Jul 2012 23:56:05 -0400

WF resolution won't work without a domain to provide the root of discovery.  

While it might be inferred from contact to create the URI.  

Also the WF target server may be supporting multiple domains so a user name on its own would not be a good pattern.

If we are doing acct: it should have a mandatory domainpart.

John B.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 02 Jul 2012 15:28:15 +0900

On 2012/07/02 7:02, Peter Saint-Andre wrote:
> ill-advised to me.

Very much so indeed. While for an URI/IRI scheme with generic syntax 
(e.g. http, ftp), the lack of domain name can be recovered by relative 
resolution, there is no such concept as a relative URI/IRI (except just 
for lacking the scheme name) for scheme with a syntax similar to mailto:.

Regards,    Martin.

---

From: Graham Klyne <[email-masked]>
Date: Mon, 02 Jul 2012 12:53:00 +0100

Pater,

(comments below)

On 01/07/2012 04:09, Peter Saint-Andre wrote:
>>> summarize my personal feelings about the specification of the acct: scheme.
>>>
>>> *Reviewer hat OFF*
>>>
>>> Roughly, I think the acct: scheme does provide a useful, possibly minor,
>>> think the description of the acct: scheme in the WebFinger document does
>>> I've had private exchanges with one of the document editors, but I don't
>>> * how are acct URIs allocated; what's the assignment delegation structure?
>>> I don't think this is a sufficiently important issue for me to engage

Generally, this is in line with my understanding of the intent of acct: scheme. 
  Paul and/or the WebFinger folks will be better placed to judge.

Some comments:

== Section 3 ==

[[
For example, if a user has an account name of
    "foobar" on a microblogging service "status.example.net", it can be
    inferred that the user's 'acct' URI at that provider is
    acct:[email-masked] even if the provider has not
    explicitly assigned such a URI.
]]

I might say thus:
[[
For example, if a user has an account name of
    "foobar" on a microblogging service "status.example.net", it
    is taken as convention that the string "[email-masked]"
    designates that account.  This is expressed as a URI using the
    acct: scheme as "acct:[email-masked]".
]]

(The phrasing is intended to take account of the fact that WebFinger clients are 
expected to accept the "[email-masked]" without the acct: prefix.)

== Section 4.4 ==

My understanding is that an acct: URI is intended to be dereferenced using the 
WebFinger protocol.  I'm not sure about associated MIME types: does WebFinger 
define any such?

== Section 4.6 ==

I'm a little unsure about the phrasing "only the WebFinger protocol uses the 
'acct' URI scheme", but I can't put my finger on any problem or offer better 
phrasing at this time.

== Section 5 ==

Maybe add:
[[
Dereferencing an acct: URI could reveal information about a user's account.  As 
such, care should be taken that personally identifying information is not 
released without appropriate permissions and/or credentials.
]]

?

...

HTH,

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Mon, 02 Jul 2012 12:55:28 +0100

> ill-advised to me. What's the harm of including the domainpart?

+1

(URIs are intended to be a global namespace.)

#g
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Jul 2012 09:31:09 -0400

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.

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

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 2 Jul 2012 15:42:14 +0200

> problems then added it back in because there is more to NNTP than

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.

---

From: Graham Klyne <[email-masked]>
Date: Mon, 02 Jul 2012 14:49:50 +0100

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

> On Mon, Jul 2, 2012 at 7:55 AM, Graham Klyne<[email-masked]>  wrote:

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Jul 2012 11:42:19 -0400

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
<[email-masked]> wrote:
> 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.
>
>>
>>
>>
>>

---

From: Mike Jones <[email-masked]>
Date: Mon, 2 Jul 2012 15:44:58 +0000

+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: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Monday, July 02, 2012 8:42 AM
To: Melvin Carvalho
Cc: Graham Klyne; [email-masked]; 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 <[email-masked]> wrote:
>> is a name, some happen to be resolvable via a default protocol, 
>> others not, thats all.
>>
>>
>> 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 
> 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.
>
>>
>>
>>
>>
>> >>> 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.
>> >>
>> >>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 02 Jul 2012 09:46:11 -0600

Graham, thank you for the review. Comments inline.

On 7/2/12 5:53 AM, Graham Klyne wrote:
> Generally, this is in line with my understanding of the intent of acct:
> scheme.  Paul and/or the WebFinger folks will be better placed to judge.

Indeed. I expect a bit of back-and-forth to harmonize the two documents.

> (The phrasing is intended to take account of the fact that WebFinger
> clients are expected to accept the "[email-masked]" without
> the acct: prefix.)

Yes, I prefer your phrasing. Thank you for proposing text.

> == Section 4.4 ==
> 
> My understanding is that an acct: URI is intended to be dereferenced
> using the WebFinger protocol. 

My understanding is that the WebFinger protocol defines one way for
'acct' URIs to be dereferenced, but that other protocols might also
define such ways in the future. If I am wrong about that and 'acct' is
tightly coupled with WebFinger, then we need to make that clear in the
'acct' URI spec.

> I'm not sure about associated MIME types:
> does WebFinger define any such?

WebFinger reuses the document formats for Extensible Resource Descriptor
(XRD) and JSON Resource Descriptor (JRD). Is it the place of the 'acct'
URI spec to define the media types associated with WebFinger, or only to
say that protocols using 'acct' URIs need to specify if they have
associated media types?

> == Section 4.6 ==
> 
> I'm a little unsure about the phrasing "only the WebFinger protocol uses
> the 'acct' URI scheme", but I can't put my finger on any problem or
> offer better phrasing at this time.

OK.

> == Section 5 ==
> 
> Maybe add:
> [[
> Dereferencing an acct: URI could reveal information about a user's
> account.  As such, care should be taken that personally identifying
> information is not released without appropriate permissions and/or
> credentials.
> ]]

Makes sense. Thanks.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Jul 2012 11:49:31 -0400

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 <[email-masked]> wrote:
> 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
> --
>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 02 Jul 2012 09:52:21 -0600

On 7/2/12 9:44 AM, Mike Jones wrote:
> +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.

Be that as it may, do you expect to use URIs to identify systems that
are not connected to the Internet?

---

From: Mike Jones <[email-masked]>
Date: Mon, 2 Jul 2012 15:54:57 +0000

It's done a lot - it's one of the primary applications of the "localhost" name.  I suppose we could define acct:user@localhost, but that seems like more of a hack than just allowing acct:user.

				-- Mike

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: Monday, July 02, 2012 8:52 AM
To: Mike Jones
Cc: Phillip Hallam-Baker; Melvin Carvalho; Graham Klyne; [email-masked]; Murray S. Kucherawy
Subject: Re: [apps-discuss] The acct: scheme question

> strictly local.  The domain portion of the acct: identifier should be 

Be that as it may, do you expect to use URIs to identify systems that are not connected to the Internet?

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 02 Jul 2012 10:20:24 -0600

On 7/2/12 9:54 AM, Mike Jones wrote:
> It's done a lot - it's one of the primary applications of the
> "localhost" name.  I suppose we could define acct:user@localhost, but
> that seems like more of a hack than just allowing acct:user.

So if you want to access one of these non-Internet-connected hosts using
HTTP, you would specify a URI of "http:///"? That's crazy talk. :)

I really don't see a good reason to make the hostname optional -- it
just introduces unnecessary complexity.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: John Bradley <[email-masked]>
Date: Mon, 2 Jul 2012 12:44:32 -0400

Relative URI need to be relative to a base context.

They don't contain scheme or host information.

I could see having a relative acct: URI of:

<HEAD>
   <BASE href="acct://example.com">
 </HEAD>
<BODY>
<A href="bob">bob's account</A>
</BODY>
That would be assembled by some user agent to "acct:[email-masked]" as a URI for dereferencing.

That is different from throwing around "acct:bob"  which is like saying "http:///bob.html" and not a valid URI as I understand it.

This is the good thing about trying to document acct: separately,  it brings out issues that WF might not address.

John B.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 2 Jul 2012 10:43:41 -0700

+1

There is always a domain.  Relying on implicit contexts just makes the
scheme more fragile.

If you really don't know the domain, but expect clients to have this
information, how about:
acct:[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 02 Jul 2012 11:45:41 -0600

> There is always a domain.  Relying on implicit contexts just makes the

Well put. I don't trust this implicit stuff in protocols. :)

/psa

---

From: Bob Wyman <[email-masked]>
Date: Mon, 2 Jul 2012 13:57:36 -0400

On Mon, Jul 2, 2012 at 11:42 AM, Phillip Hallam-Baker <[email-masked]>wrote:

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

---

From: William Mills <[email-masked]>
Date: Mon, 2 Jul 2012 14:45:50 -0700 (PDT)

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

>________________________________
> From: Bob Wyman <[email-masked]>
>To: Phillip Hallam-Baker <[email-masked]> 
>Sent: Monday, July 2, 2012 10:57 AM
>On Mon, Jul 2, 2012 at 11:42 AM, Phillip Hallam-Baker <[email-masked]> wrote:
>
>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.
>
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Jul 2012 18:53:24 -0400

> think, a matter which need concern anyone while wearing an IETF standards

That is not the case at all. IETF protocols have always been designed
to support local use in addition to Internet use where that makes
sense.

In this case accounts are currently a locally defined resource and the
objective is to make them an Internet resource. The transition from
one to the other requires a spec that can work equally well in both
circumstances.

Deployment is something that should always concern us. Scope arguments
are only ever relevant to the question of whether the IETF should
consider a problem in the first place. Once the problem is accepted
the design must address all the use cases and requirements that
reasonably apply whether they are deemed to be in IETF scope or not.

And in any case I think that you are completely wrong on the question
of scope in the first place. Please provide a citation for your claim
if you want to continue the argument.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 03 Jul 2012 12:50:02 +0900

> using the WebFinger protocol. I'm not sure about associated MIME types:

How's that relevant to the acct: scheme? It will be defined in the 
WebFinger spec, and that's good enough, isn't it?

> offer better phrasing at this time.

The main problem is that it may be totally wrong in a month, or in 10 
years. At the minimum, change it to "at the time of writing of this 
specification, only ...".

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 03 Jul 2012 12:53:24 +0900

After reading Phillip's mails, I agree with him that it makes sense to 
allow an account id without a domain name. The document should be clear 
that such use won't work internet-wide, and should be avoided wherever 
possible. It should also be clear that relative resolution won't work, 
because it's the wrong syntax.

Regards,    Martin.

On 2012/07/03 7:53, Phillip Hallam-Baker wrote:
> On Mon, Jul 2, 2012 at 1:57 PM, Bob Wyman<[email-masked]>  wrote:
>>
>>
>> On Mon, Jul 2, 2012 at 11:42 AM, Phillip Hallam-Baker<[email-masked]>
>> wrote:
>>>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 03 Jul 2012 12:55:59 +0900

> That would be assembled by some user agent to "acct:[email-masked]" as a URI for dereferencing.

It would be assembled into "acct://example.com/bob". See RFC 3986, 
Section 5 (http://tools.ietf.org/html/rfc3986#section-5).

Regards,   Martin.

---

From: William Mills <[email-masked]>
Date: Mon, 2 Jul 2012 21:02:08 -0700 (PDT)

Peter's point about complexity for parsing is significant if we don't have a good reason to need it.  The logic for optional is something like:

-    is there an @ sign?
    -    no: the whole thing is a local user identifier
    -    yes: does the domain part parse correctly as a domain?
        -    no: the whole thing is a local user id
        -    yes: this is a proper compound identifier

Which is kind of a PITA if you don't need it.  If we do feel like we want purely local identifiers we could let the domainpart be empty, with an @ at the end.  That would fix the parsing, but probably make people cringe.

> From: ""Martin J. Dürst"" <[email-masked]>
>Sent: Monday, July 2, 2012 8:53 PM

---

From: Graham Klyne <[email-masked]>
Date: Tue, 03 Jul 2012 10:15:12 +0100

> tightly coupled with WebFinger, then we need to make that clear in the

If it's not the case, then I think a key reason for acct: being useful as a 
distinct URI scheme is scuppered.

#g
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 03 Jul 2012 09:19:28 -0600

On 7/3/12 3:15 AM, Graham Klyne wrote:
> If it's not the case, then I think a key reason for acct: being useful
> as a distinct URI scheme is scuppered.

Precisely why I asked the question. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/