Etan Wexler | 6 Oct 07:46 2005

Re: RFC 2822 email addresses in tag URIs


Tim Kindberg wrote to the URI Interest Group’s mailing list 
(<mailto:uri <at> w3.org>) on 23 September 2005 in “RFC 2822 email addresses 
in tag URIs” (<mid:43340C98.8020404 <at> hpl.hp.com>, 
<http://www.w3.org/2002/02/mid/43340C98.8020404 <at> hpl.hp.com>):

> I'm inclined to go for [the] simpler approach: take a subset of 
> RFC 2822 email addresses that users could be expected to read & 
> manipulate by hand and brain (following the 'tag' philosophy), and 
> simply %-encode certain of their characters.

Percent-encoding strikes me as a complication that moves “tag” URIs 
outside of the target range of ease of use. Reconsider the employment of 
percent-encoding or reconsider the target range of ease of use.

> Principle 1: only allow relatively simple, human-legible/tractable email 
> address to be embedded in tags. So only allow printing characters (%20 - 
> %7E). NB only whitespace character is " " (which has to be quoted in 
> RFC2822-land).  No folding, no control characters.
>
> Principle 2: disallow obsolete constructs. 
>
> Principle 3: disallow comments -- no value in a tag but lots of 
> potential for confusion.

All the principles are agreeable.

> In addition, the following characters should not appear literally as 
> part of an email address in a tag; they must be %-encoded (ONCE) from 
> the original email address:
(Continue reading)

Weibel,Stu | 7 Oct 15:49 2005
Picon

Status of Hansen draft on URI registration?

Apologies if I’m asking a question for which the answer is well known, but can anyone provide an update on the status of the Hansen draft for URI registrations?

 

Is there a projection concerning the timeline for approval?

 

Thanks

 

stu

Dan Connolly | 7 Oct 17:21 2005
Picon

Re: Status of Hansen draft on URI registration?


On Fri, 2005-10-07 at 09:49 -0400, Weibel,Stu wrote:
> Apologies if I’m asking a question for which the answer is well known,
> but can anyone provide an update on the status of the Hansen draft for
> URI registrations?

I don't know the answer, but I know where to look it up.
I'm not surprised you don't know where to look it up;
the IETF vastly undersells this service... I guess
it's partly an ISOC service.

The ISOC keeps a persistent URI for each Internet Draft;
in this case:

http://ietfreport.isoc.org/idref/draft-hansen-2717bis-2718bis-uri-guidelines/

and it has a link to the IETF "datatracker" entry, where we see:

In State: Waiting for AD Go-Ahead :: Revised ID Needed
as of2005-09-07

> 

> Is there a projection concerning the timeline for approval?

The critical path seems to be down to the IESG and the editors.
Based on experience, I expect they'll finish somewhere between
two weeks and 4 months from now, but I'm not aware of any
upper bound on how long the process can take from here to
Proposed Standard.

The tracker entry has links to various "state explanations" and such...
I think I once found a page showing the IESG queue, i.e. a list
of all the things pending before the IESG, what state they were
in, and how long they had been in that state. From that you
could project when draft-hansen will be done, if you can find it.

> 
--

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Weibel,Stu | 7 Oct 18:56 2005
Picon

RE: Status of Hansen draft on URI registration?


Thanks Dan... this is helpful, though the ID tracker requires an intimate understanding of the state
diagram that I was hoping to achieve "by reference" rather than "by value". 

Is there anyone in the loop who might be willing to refine Dan's estimate on timelines?

Thanks

stu

-----Original Message-----
From: Dan Connolly [mailto:connolly <at> w3.org] 
Sent: Friday, October 07, 2005 11:22 AM
To: Weibel,Stu
Cc: uri <at> w3.org
Subject: Re: Status of Hansen draft on URI registration?

On Fri, 2005-10-07 at 09:49 -0400, Weibel,Stu wrote:
> Apologies if I’m asking a question for which the answer is well known,
> but can anyone provide an update on the status of the Hansen draft for
> URI registrations?

I don't know the answer, but I know where to look it up.
I'm not surprised you don't know where to look it up;
the IETF vastly undersells this service... I guess
it's partly an ISOC service.

The ISOC keeps a persistent URI for each Internet Draft;
in this case:

http://ietfreport.isoc.org/idref/draft-hansen-2717bis-2718bis-uri-guidelines/

and it has a link to the IETF "datatracker" entry, where we see:

In State: Waiting for AD Go-Ahead :: Revised ID Needed
as of2005-09-07

> 

> Is there a projection concerning the timeline for approval?

The critical path seems to be down to the IESG and the editors.
Based on experience, I expect they'll finish somewhere between
two weeks and 4 months from now, but I'm not aware of any
upper bound on how long the process can take from here to
Proposed Standard.

The tracker entry has links to various "state explanations" and such...
I think I once found a page showing the IESG queue, i.e. a list
of all the things pending before the IESG, what state they were
in, and how long they had been in that state. From that you
could project when draft-hansen will be done, if you can find it.

> 
--

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Larry Masinter | 7 Oct 20:02 2005
Picon

RE: Status of Hansen draft on URI registration?


There were last call comments. I prepared a new version
http://larry.masinter.net/draft-hansen-2717bis-2718bis-uri-guidelines-06.htm
l
and .txt, trying to address last call comments, but I am waiting for
IANA review. On 9/16, Michelle said that IANA would review the
document, but I haven't seen any comments back yet.

There was  still a question about how the registry was updated when
the original internet-draft was updated or became an RFC, and whether
we needed to say anything more explicit in the process document.

Larry

Weibel,Stu | 7 Oct 20:10 2005
Picon

RE: Status of Hansen draft on URI registration?


Thanks, Larry

I think a lot of people feel, as I do, that this is an important step
forward and that it should happen sooner rather than later

Best
stu

-----Original Message-----
From: Larry Masinter [mailto:LMM <at> acm.org] 
Sent: Friday, October 07, 2005 2:02 PM
To: 'Dan Connolly'; Weibel,Stu
Cc: uri <at> w3.org; 'IANA'
Subject: RE: Status of Hansen draft on URI registration?

There were last call comments. I prepared a new version
http://larry.masinter.net/draft-hansen-2717bis-2718bis-uri-guidelines-06
.htm
l
and .txt, trying to address last call comments, but I am waiting for
IANA review. On 9/16, Michelle said that IANA would review the
document, but I haven't seen any comments back yet.

There was  still a question about how the registry was updated when
the original internet-draft was updated or became an RFC, and whether
we needed to say anything more explicit in the process document.

Larry

noah_mendelsohn | 7 Oct 20:35 2005
Picon

Re: W3C TAG Last Call Comment on RFC2717bis/RFC2718bis


In late August the TAG provided a last call comment [1] on then-proposed 
RFC2717bis/RFC2718bis [2].  In a recent note [3] to uri <at> w3.org, Larry 
Masinter points out that in response to (unspecified) last call comments, 
a new draft has been prepared [4], and I note at least one set of changes 
that appear to be responsive to the TAG's concerns:

<original 
href="http://ietfreport.isoc.org/all-ids/draft-hansen-2717bis-2718bis-uri-guidelines-05.txt">
2.1 Demonstratable, new, long-lived utility

Because URI schemes constitute a single, global namespace, the unbounded 
registration of new schemes is harmful to the Internet community. For this 
reason, new URI schemes SHOULD have clear utility to the broad Internet 
community, beyond that available with already registered URI schemes. 
</original>

<revised 
href="http://ietfreport.isoc.org/all-ids/draft-hansen-2717bis-2718bis-uri-guidelines-06.txt">
2.1. Demonstratable, new, long-lived utility

The use and deployment of new URI schemes in the Internet infrastructure 
is costly; some parts of URI processing may be scheme-dependent, and 
deployed software already processes URIs of well-known schemes. 
Introducing a new URI scheme may require additional software, not only for 
client software and user agents but also in additional parts of the 
network infrastructure (gateways, proxies, caches).[13] (W3C Technical 
Architecture Group, "Architecture of the World Wide Web, Volume One," 
December 2004.). URI schemes constitute a single, global namespace; it is 
desirable to avoid contention over use of short, mneumonic scheme names. 
For these reasons, the unbounded registration of new schemes is harmful. 
New URI schemes SHOULD have clear utility to the broad Internet community, 
beyond that available with already registered URI schemes.
</revised>

Speaking for myself as opposed to for the TAG as a whole, I find this to 
be exactly what I was hoping we'd see.  This seems to me a completely 
satisfactory response to the TAG's request.  Thank you to Larry and the 
other authors for the prompt and careful attention to these concerns.

Noah

[1] http://lists.w3.org/Archives/Public/www-tag/2005Aug/0014.html 
[2] 
http://ietfreport.isoc.org/all-ids/draft-hansen-2717bis-2718bis-uri-guidelines-05.txt
[3] http://lists.w3.org/Archives/Public/uri/2005Oct/0004.html
[4] 
http://ietfreport.isoc.org/all-ids/draft-hansen-2717bis-2718bis-uri-guidelines-05.txt

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Larry Masinter | 10 Oct 19:57 2005
Picon

draft-hansen-2717bis-2718bis-uri-guidelines-06.txt now actual internet draft


I had been waiting for IANA review, but went ahead and submitted
the update with responses (to most, I believe) last call comments:

http://www.ietf.org/internet-drafts/draft-hansen-2717bis-2718bis-uri-guidelines-06.txt

Tim Kindberg | 11 Oct 15:32 2005
Picon

Re: RFC 2822 email addresses in tag URIs


Thanks Etan.

In a nutshell, there are two poitions:

The position I began with ("simplicity") allows in tag URIs a few 
special characters allowed by RFC 2822, but no %-encoding and hence no 
quotes or "quoted pairs", among other things.  This position implies 
that e.g. "Fred Smith's uncle!" <at> example.com can't be used to mint tags, 
whereas Fred_Smith's_uncle! <at> example.com can -- without transformation.

The position I tried following feedback ("inclusivity") allows 
%-encoding.  So "Fred Smith's uncle!" <at> example.com could be used for tags 
but it becomes something that 99% of humans wouldn't be able to 
formulate correctly unaided: tag:%22Fred%20...

Maybe my experience is unusual but I never encounter email addresses 
using the new freedoms allowed by RFC 2822 -- which has been around 
since 2001.  So it's hard to argue strongly for "inclusivity" -- which, 
in addition, (a) turned out to add significant complexity to what is 
otherwise simple syntax, and (b) is only "inclusive" if you can (operate 
a program to) correctly transform your email address.

On balance, I'm inclined to follow my original advice -- and now Etan's 
-- and go for "simplicity".

Sandro, what do you think of all this?

Cheers,

Tim.

Etan Wexler wrote:

> 
> Tim Kindberg wrote to the URI Interest Group’s mailing list 
> (<mailto:uri <at> w3.org>) on 23 September 2005 in “RFC 2822 email addresses 
> in tag URIs” (<mid:43340C98.8020404 <at> hpl.hp.com>, 
> <http://www.w3.org/2002/02/mid/43340C98.8020404 <at> hpl.hp.com>):
> 
>> I'm inclined to go for [the] simpler approach: take a subset of RFC 
>> 2822 email addresses that users could be expected to read & manipulate 
>> by hand and brain (following the 'tag' philosophy), and simply 
>> %-encode certain of their characters.
> 
> 
> Percent-encoding strikes me as a complication that moves “tag” URIs 
> outside of the target range of ease of use. Reconsider the employment of 
> percent-encoding or reconsider the target range of ease of use.
> 
>> Principle 1: only allow relatively simple, human-legible/tractable 
>> email address to be embedded in tags. So only allow printing 
>> characters (%20 - %7E). NB only whitespace character is " " (which has 
>> to be quoted in RFC2822-land).  No folding, no control characters.
>>
>> Principle 2: disallow obsolete constructs.
>> Principle 3: disallow comments -- no value in a tag but lots of 
>> potential for confusion.
> 
> 
> All the principles are agreeable.
> 
>> In addition, the following characters should not appear literally as 
>> part of an email address in a tag; they must be %-encoded (ONCE) from 
>> the original email address:
> 
> 
> In the “tag” specification, that word “should” will want to be the word 
> “must”.
> 
> The characters in the list must undergo percent-encoding only if said 
> characters appear in the <local-part> of the e-mail address.
> 
>>        gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / " <at> "
> 
> 
> Every e-mail address has a “commercial at” (U+0040) that separates the 
> <local-part> from the <domain>. Processors must transcribe this 
> “commercial at” literally when embedding an e-mail address in a “tag” URI.
> 
>> emailAddress      = tag-local-part " <at> " DNSname
>> tag-local-part    = tag-dot-atom-text / tag-no-fold-quote
>> tag-dot-atom-text = 1*tag-atext *("." 1*tag-atext)
>> tag-atext         = ALPHA / DIGIT  /
>>                       "!"   / "%23" /
>>                       "$"   / "%25" /
>>                       "&"   / "'"   /
>>                       "*"   / "+"   /
>>                       "-"   / "%2F" /
>>                       "="   / "%3F" /
>>                       "%5E" / "_"   /
>>                       "%60" / "%7B" /
>>                       "%7C" / "%7D" /
>>                       "~"
>> tag-no-fold-quote = "%22" *(tag-qtext / tag-quoted-pair) "%22"
>> tag-quoted-pair   = "%5C"  tag-qptext
>> tag-qtext         = tag-atext / "(" /
>>                       ")"   /  "%2C" /
>>                       "."   /  "%3A" /
>>                       ";"   /  "%3C" /
>>                       "%3E" /  "%40" /
>>                       "%5B" /  "%5D" /
>> tag-qptext        = tag-qtext / "%20" / "%5C" / "%22"
> 
> 
> I argue for something even simpler. I would eliminate percent-encoding 
> and quoted strings, leaving only e-mail addresses that transcribe 
> literally.
> 
> emailAddress      = tag-local-part " <at> " DNSname
> tag-local-part    = 1*tag-atext *("." 1*tag-atext)
> tag-atext         = ALPHA / DIGIT /
>                      "!"  /  "$"  /
>                      "&"  /  "'"  /
>                      "*"  /  "+"  /
>                      "-"  /  "="  /
>                      "_"  /  "~"
> 
> So I basically return to Tim’s proposal dated 6 July 2005 (“email 
> address in a URI”, <mid:42CBAAE0.3060309 <at> hpl.hp.com>,
> <http://www.w3.org/mid/42CBAAE0.3060309 <at> hpl.hp.com>). The specification 
> of the “tag” scheme will be stronger as a result of the discussion, I hope.
> 

--

-- 

Tim Kindberg
hewlett-packard laboratories
filton road
stoke gifford
bristol bs34 8qz
uk

purl.org/net/TimKindberg
timothy <at> hpl.hp.com
voice +44 (0)117 312 9920
fax +44 (0)117 312 8003

Sandro Hawke | 11 Oct 19:01 2005
Picon

Re: RFC 2822 email addresses in tag URIs


> In a nutshell, there are two poitions:
> 
> The position I began with ("simplicity") allows in tag URIs a few=20
> special characters allowed by RFC 2822, but no %-encoding and hence no=20
> quotes or "quoted pairs", among other things.  This position implies=20
> that e.g. "Fred Smith's uncle!" <at> example.com can't be used to mint tags,=20
> whereas Fred_Smith's_uncle! <at> example.com can -- without transformation.
> 
> The position I tried following feedback ("inclusivity") allows=20
> %-encoding.  So "Fred Smith's uncle!" <at> example.com could be used for tags=20
> but it becomes something that 99% of humans wouldn't be able to=20
> formulate correctly unaided: tag:%22Fred%20...
> 
> Maybe my experience is unusual but I never encounter email addresses=20
> using the new freedoms allowed by RFC 2822 -- which has been around=20
> since 2001.  So it's hard to argue strongly for "inclusivity" -- which,=20
> in addition, (a) turned out to add significant complexity to what is=20
> otherwise simple syntax, and (b) is only "inclusive" if you can (operate=20
> a program to) correctly transform your email address.
> 
> On balance, I'm inclined to follow my original advice -- and now Etan's=20
> -- and go for "simplicity".
> 
> Sandro, what do you think of all this?

Given that it's possible to include %-escapes later and not really
possible to remove them later if they are allowed now, I'm inclined to
go with the "simplicity" approach for now.  I have to admit, though,
that I don't really know much about the politics of these extended
e-mail address characters.

     -- sandro


Gmane