Subject: [EAI] Fwd: I-D ACTION:draft-duerst-mailto-bis-03.txt

From: Martin Duerst <[email-masked]>
Date: Fri, 27 Oct 2006 11:25:01 +0900

As Kari has already mentioned, I have updated my mailto: URI draft
(draft-duerst-mailto-bis) and it has been republished at
http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-03.txt
(see below if you need further details). Please provide feedback,
in particular on 

I have added a reference to the EAI framework document in the
introduction. The problem is that because mailto: is Standards
Track and EAI (currently) is Experimental, that creates an
undesired dependency (currently the reference is informative,
but there may be a need for a normative reference to one or
more of the EAI documents because of the following material
dependency:

EAI extends mail address formats from a single address to an
UTF-8 address and a fallback address, as defined in
http://www.twnic.net.tw/jeff/draft-ietf-eai-utf8headers-02.txt
(see in particular the productions angle-addr and alt-address).
If it is desirable to be able to represent this in a mailto:
URI as something like mailto:[email-masked][[email-masked]],
then this dependency exists.

Please note that there is no spec-wise dependency just because
EAI introduces non-ASCII local parts. The mailto-bis draft
simply says that non-ASCII local parts are represented as
UTF-8 (percent-encoded for URIs). If there is a system that
can create and deliver to such mail addresses, then people
will start to use that part of the new mailto: spec. If not,
then it's just something specificed but not yet implemented.
There is also no need for mailto: and EAI to use the same
encoding for local parts, as long as conversion is reasonably
possible. The fact that they are both using UTF-8 makes things
much easier for implementers, but isn't relevant for the specs
to be able to work together.

In terms of timeline, there are mainly three possible ways to
move forward with mailto-bis:
a) Wait for EAI to complete Experimental and then move to
   Standards Track.
b) Publish mailto-bis without alt-address provisions, add
   these provisions in a later update.
c) Publish mailto-bis without alt-address provisions, because
   we think than for mailto: URIs, alt-address doesn't make
   sense.

As said above, your comments and advice are highly appreciated.

Reards,     Martin.

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>       Title           : The 'mailto' URI Scheme
>       Author(s)       : M. Duerst, et al.
>       Filename        : draft-duerst-mailto-bis-03.txt
>       Pages           : 17
>       Date            : 2006-10-25
>       
>This document defines the format of Uniform Resource Identifiers
>   (URI) to identify resources that are reached using Internet mail.  It
>   updates the syntax of 'mailto' URIs from [RFC2368] for better
>   compatibility with IRIs ([RFC3987]).
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-03.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>[email-masked] with the word unsubscribe in the body of 
>the message. 
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
>to change your subscription settings.
>
>Internet-Drafts are also available by anonymous FTP. Login with the 
>username "anonymous" and a password of your e-mail address. After 
>logging in, type "cd internet-drafts" and then 
>"get draft-duerst-mailto-bis-03.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>       [email-masked].
>In the body type:
>       "FILE /internet-drafts/draft-duerst-mailto-bis-03.txt".
>       
>NOTE:  The mail server at ietf.org can return the document in
>       MIME-encoded form by using the "mpack" utility.  To use this
>       feature, insert the command "ENCODING mime" before the "FILE"
>       command.  To decode the response(s), you will need "munpack" or
>       a MIME-compliant mail reader.  Different MIME-compliant mail readers
>       exhibit different behavior, especially when dealing with
>       "multipart" MIME messages (i.e. documents which have been split
>       up into multiple messages), so check your local documentation on
>       how to manipulate these messages.
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID: <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-duerst-mailto-bis-03.txt
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-duerst-mailto-bis-03.txt>
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/i-d-announce

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]     

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 27 Oct 2006 12:12:31 +0200

Martin Duerst wrote:

> EAI (currently) is Experimental, that creates an undesired dependency
> (currently the reference is informative, but there may be a need for
> a normative reference to one or more of the EAI documents

Procedural nits - we could ask John how he managed to get a _normative_
reference to the 2821 (PS) in 4409 (DS).  In 3461 (DS) that was "fixed"
to 821 (STD) - so far it's as it should be, but the prose claiming to
reference [1] = 821 obviously cites 2821.  There's no "esmtp-value" in
STD 10.

The problems with 2368bis aren't procedural but substantial.  It's not
backwards compatible and nevertheless tries to preserve things that
didn't work as expected, like the body= pseudo-header-field, or wild
mixtures of <to> and to= header fields.

In a first step 2368 needs to be upgraded to 3986, removing cruft like
body= or to=, and addressing the in-reply-to= feature (as RECOMMENDED).

The issues of "raw" <pct-encoded> Unicode are a separate second step,
minimally a completely separate chapter, starting with a Caveat that
this won't work with existing software.  UAs finding a mailto URL in
a say Latin-1 encoded document won't get this right.  Maybe they will
assume some local default charset if they try to be "smart",

And this could cause havoc, interpreting the raw <pct-encoded> UTF-8
as pseudo-Latin-1 (windows-1252), and if they really try to be "smart"
maybe converting it to their default charset or even UTF-8, encoded
with 2047 (or a CTE + Content-Type for the insane body= construct).

2368bis must be very clear, that if it allows <pct-encoded> UTF-8,
then it will still take some years until this works as expected.

At this time the experimental phase of EAI should be finished, and a
2368ter could remove the Caveat with SHOULD NOT MUSTard, or replace
it by a historical note that some old UAs implemented before 2010 are
expected to get 2368bis hopelessly wrong.

Then we'll also have IDNAbis, and folks are used to work with normal
IRIs, not this worst case "mailto:" (or "xmppp:", where the URI czar
proposed to trash its published RFC - I was stunned, but at least I
hope I've now grokked 3986.  If so it took me "only" two years... ;-)

> then this dependency exists.

It will be of course desirable for 2368ter, but IMO not for 2368bis.
2368bis is already very tricky without this complication.

> it's just something specificed but not yet implemented.

Yes, like the <utf8-non-asciii> in NNTP newsgroup names, it causes
no harm as long as nobody uses it because it's not (yet) supported
in the Netnews Article Format.  BTW, NNTP got 3997 for 997bis, the
RfC editor apparently loves it... :-)

>    we think than for mailto: URIs, alt-address doesn't make

I'd prefer something between b and c.  It would need a good place
to discuss it, the URI list or maybe better (?) the rfc822 list.

Frank

---

From: Kari Hurtta <[email-masked]>
Date: 27 Oct 2006 18:15:14 +0300

> then it will still take some years until this works as expected.

Some MUAs try use UTF-8, some try use local charset. 

I think that my MUA tries UTF-8 for %xx encoded characters first
if given on command line or on List-* -header fields.

Anyway, these decisions are not bind to mailto -scheme.

And RFC 2192   already requires UTF-8   (so using UTF-8 is
natural also on other schemes, such as mailto)  

/ Kari Hurtta

( changelog:

        - Added support for RFC 2368 mailto -urls.
        - It is unclear what character set is used
          on URLs. This especially effects subject
          header and body pseudo header on mailto
          url. Following rules are used:

               - If URL includes non-ascii characters,
                 charset of (decoded) URL is implied
                 charset of URL
               - If URL includes %XX encoded characters
                 > %7F (ie. non-ascii) charset of
                 decoded URL is UTF-8. This means that
                 %XX encoding is assumed to be use
                 UTF-8 character set.
               - Note that these two rules are on
                 conflict if some, but not all non-ascii
                 characters are % -encoded.
)

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 27 Oct 2006 11:29:56 -0700

>    we think than for mailto: URIs, alt-address doesn't make

I suggest: put alt-address provisions in an informational appendix,
and suggest that when and if EAI moves to standards track, the 
mailto provisions should be reviewed and, if necessary, updated.

Larry

---

From: John C Klensin <[email-masked]>
Date: Fri, 27 Oct 2006 15:31:21 -0400

--On Friday, 27 October, 2006 11:29 -0700 Larry Masinter
<[email-masked]> wrote:

> I suggest: put alt-address provisions in an informational
> appendix, and suggest that when and if EAI moves to standards
> track, the  mailto provisions should be reviewed and, if
> necessary, updated.

Folks, move forward as you like on this, but note that...

	(1) At the request of several people around the time of
	the BOF from which EAI was organized, updating mailto
	when appropriate is an explicit work item for the WG.
	
	(2) If you submit this for standardization now, and the
	IESG follows precedent, the document will be referred to
	the EAI WG for evaluation.

My own personal opinion is that, while I understand and
sympathize with the motivation for this draft, introduction of a
partially-internationalized mailto revision at this point would
mostly cause confusion.   In particular, while I hope the
discussion is over, the possibility of a standardized ACE has
started again in the EAI WG.  Were that path to be chosen,
%-encoded UTF-8 might turn out to be quite unattractive.

So I don't think trying to wrap this up now is particularly
helpful.

Just my opinion.
    john

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 28 Oct 2006 00:35:44 +0200

John C Klensin wrote:

> updating mailto when appropriate is an explicit work item for the WG.

Maybe the charter needs an update then, and the mailto draft could be
renamed to draft-ietf-eai-mailto-bis.  For the 2368bis part trying to
get in line with 3986 incl. fixes for several 2368 issues it might be
better to ignore UTF-8 for the moment.  Where <pct-encoded> is allowed
adding UTF-8 later is no problem.
 
> If you submit this for standardization now, and the IESG follows 
> precedent, the document will be referred to the EAI WG for evaluation.

| Adding or removing documents outside of these deliverables will
| require a charter update.

Apparently the Charter says that anything on standards track follows
after the evaluation of the experiment.  It doesn't mention mailto or
2368.  Or I read an obsolete version (2006-08-15).  This URI stuff is
tricky, mailto is the worst case.  Today I found out that there's an
obscure mailto.uri.arpa NAPTR waiting to be fixed.

There are several issues in the mailto draft even without mentioning
UTF-8, I18N, or IRIs.  It needs a new clean decrufted 3986-compatible
version as a solid base before adding new features.  It's too complex
to get this right in one giant jump.

Frank

---

From: Martin Duerst <[email-masked]>
Date: Sat, 28 Oct 2006 15:48:13 +0900

At 07:35 06/10/28, Frank Ellermann wrote:
>Maybe the charter needs an update then,

Yes indeed. I was explicitly raising the question of whether
a mailto: update should be part of the charter or not when
chartering was discussed, and I seem to remember that the
answers were mostly along the lines of "we may need coordination,
but don't make this an item of the WG". I have just reread the
WG charter (at http://www.ietf.org/html.charters/eai-charter.html),
and I have not found any trace or hint of mailto: in there.

Digging a bit, I found the following mail that provides some
additional pointers to the discussion before chartering:
http://www1.ietf.org/mail-archive/web/ima/current/msg00140.html.

>and the mailto draft could be renamed to draft-ietf-eai-mailto-bis.

I would be happy to do this (I can't speak about my coauthors),
but I don't think it's necessary, and I think first there should
be a clear expression of preference from a substantial part of
the WG that we indeed want to change the character in this direction.

>For the 2368bis part trying to

Frank, here I have to disagree with you quite strongly.
Allowing arbitrary byte salad first and then later trying
to limit that to UTF-8 is a very bad idea. It has happened
by accident a few times, but it would be a big failure to
do that deliberately. Also, it would totally leave implementers
in the dark about what to do with those octets. Take for example
   mailto:[email-masked];body=abc%ab%cd%efdef
How is an MUA supposed to send this body? What's the charset?

>> precedent, the document will be referred to the EAI WG for evaluation.

Yes, that's why I'm sending it here, for pre-evaluation.

>version as a solid base before adding new features.

Frank, if you send me a list of things that need to be fixed so
that mailto: gets 3986-compatible, I'll be glad to do all these
fixes. Or do you think they already have been made in
draft-duerst-mailto-bis-03.txt? Then please say so, thanks.

>It's too complex to get this right in one giant jump.

I completely disgaree. There are already some mailers, e.g. Opera
mail, that just do the right thing for %-encoding and UTF-8.
There are others that are waiting for directions. A spec
that allows to send email, but not a word besides US-ASCII
(in the body, where this is possible since ages) is not something
the IETF should approve in this day and age.

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Sat, 28 Oct 2006 18:23:38 +0900

>> track, the  mailto provisions should be reviewed and, if

Thanks for this idea, which is a mixture between a) and b).

>%-encoded UTF-8 might turn out to be quite unattractive.

I don't think that %-encoded UTF-8 would be unattractive at all
in that case. IDNA uses ACE in the protocol, but of course
browsers accept real characters (i.e. IRIs) if they support
IDNA. At least Opera also accepts %-encoding of IDNs, and
that's what's expected by RFC 3986 and RFC 3987. It would
be virtually impossible to convert between IRIs and URIs
if such a conversion had to know all the different protocols
and ACEs involved. Of course, if there is an ACE, that
ACE will also work out of the box, because that's what the
ACE is for, but it will look just ugly.

Regards,    Martin.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 28 Oct 2006 12:11:00 +0200

Martin Duerst wrote:

> to limit that to UTF-8 is a very bad idea.

Sorry, that wasn't what I meant, some %80guess_what_this_is
is of course ugly.  But in an overall structure of...

   mailto:a@b?c=d&e=f#g

...you'd have to allow <pct-encoded> anyway in a..f.  For
anything that's not covered by an <uri-character> derived
from 3986, or used as delimiter @, ?, =, &, #  Maybe the #g
is bogus, then ignore it please.

The spec. could then say that any <pct-encoded> outside of
what's allowed by 2822 has to be UTF-8, and that all details
about raw UTF-8 in email headers are not yet specified.

If you want to preserve the mailbox-list feature of 2368 a
better overall structure might be:

   mailto:a@b,c@d?e=f&g=h#i

That would add "," to the delimiters used before the "?".

And maybe you could allow ";" as common alternative for "&",
adding ";" to the delimiters needed after the "?".  Or use
it on both sides (no comma), slowly drifting away from 2368
to a rather different 2368bis.

Somewhere is a point when "nobody really implemented 2368
as specified" doesn't justify to invent new improved syntax
anymore, that's one of the tricky issues.  But in -03 it's:

   mailto:a@b%2Cc@d?e=f&g=h#i

With %2C as delimiter, IMO that's unnatural.  Admittedly it
works with my vintage '96 UA, but is it in the spirit of
3986 ?

Comma like ";", "=", and "&" belongs to the <sub-delims>, it
shouldn't be necessary to percent-encode it when it's used
for precisely this purpose.

> it would be a big failure to do that deliberately.

Yes, this isn't the ftp-URI scheme, it's mailto, there are
no serious legacy cases of UNKNOWN-8BIT.  Maybe body values
are an exception, but they're a very bad idea.

> How is an MUA supposed to send this body? What's the charset?

Delete body=, it's cruft.  A well earned MUST NOT if you have
to spell it out for a registration as "reserved" header field.

> if you send me a list of things that need to be fixed so that
> mailto: gets 3986-compatible, I'll be glad to do all these
> fixes.

You have a long list of 2822 features that are not allowed in
mailto:  After some years of fun with USEFOR I know exactly
what that means, but I'm not confident that all readers know
the 2822-details by heart.

IMO you should specify what you weant.  You'll end up with
something like the <msg-id-core> in USEFOR, but probably not
exactly the same, you dont need the concept of a "canonical
address".  Or in other words you get its <msg-id-core> without
canonical backslash limitation.

For now and for 2368bis.  For EAI you'd have to add percent-
encoded UTF-8, or reserve this in 2368bis for future use.

The hname= is wrong, it should stick to the syntax of a 2822
header field name, even EAI doesn't plan to modify this.  And
the hvalue= is perfect (for your chosen set of delimiters).

There are several similar open issues in -03.  I could offer
sytax for a no-nonsense 3986 <msg-id-core> adding an arbirary
backslash if necessary.  Or without if you prefer "canonical"
compatibility with <msg-id-core>.

Plus <percent-encoded-utf8> for future use.  Which is again
an issue, IIRC John intended to limit this to <dot-atom-text>
- i.e. no UTF-8 within <no-fold-quote> and <no-fold-literal>.

UTF-8 in a domain literal is clearly stupid, but I'm not sure
about <no-fold-quote> (= local part as quoted string).

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 28 Oct 2006 12:27:13 +0200

> IMO you should specify what you weant.
s/we/w/

> about <no-fold-quote> (= local part as quoted string).

Here's a preliminary version for a pure <msg-id-core> construct:

msg-id-uri     = mid-left "@" mid-right       ; <msg-id-core>

mid-left       = 1*( mid-atext / "." ) /      ; <dot-atom-text>
                 ( "%22" mid-quote "%22" )    ; <no-fold-quote>
mid-quote      = 1*( mid-atext / "." /        ; <mq-text> incl.
                     mid-special /            ; '\"' / "[" / "]"
                     "%5C%22" / "%5B" / "%5D" )

mid-right      = 1*( mid-atext / "." ) /      ; <dot-atom-text>
                 ( "%5B" mid-literal "%5D" )  ; <no-fold-literal>
mid-literal    = 1*( mid-atext / "." /        ; <md-text> incl.
                     mid-special /            ; '"' / "\[" / "\]"
                     "%22" / "%5C%5B" / "%5C%5D" )

mid-special    = "(" / ")" / "," / ":" / ";" /
                 "%3C" / "%40" / "%5C%5C"     ; "<" / "@" / "\\"

mid-atext      = ALPHA / DIGIT /              ; RFC 2822 <atext>
                 "!" / "$" / "&" / "'" /      ; allowed sub-delims
                 "*" / "+" / "=" /            ; allowed sub-delims
                 "-" / "_" / "~" /            ; allowed unreserved
                 "%23" / "%25" / "%2F" /      ; "#" / "%" / "/"
                 "%3F" / "%5E" / "%60" /      ; "?" / "^" / "`"
                 "%7B" / "%7C" / "%7D"        ; "{" / "|" / "}"

That doesn't catch all the details of <msg-id-core>, it mainly
enumerates cases where <pct-encoded> is REQUIRED.  For an address
you'd allow %3E, %5C (instead of %5C%5C), %20, and you'd add some
<percent-encoded-utf8> at strategical places (TBD).

Frank

---

From: Martin Duerst <[email-masked]>
Date: Sun, 29 Oct 2006 18:25:00 +0900

Hello Frank,

>reference [1] = 821 obviously cites 2821.  There's no "esmtp-value" in

There is a special proceduce with which you can request an
exception from the 'no downreferences' rule. If I remember
correctly, it was proposed by John :-).

>body= or to=, and addressing the in-reply-to= feature (as RECOMMENDED).

I guess removing to= (well, it wouldn't just be removing, it would
mean disallowing, or at least further discouraging) may be a good
idea. I don't think removing body= makes sense, because I can
immagine many different scenarios where being able to specify a
(short) body text is helpful. Can you say exactly what you want
to happen with In-Reply-To? (ideally some proposed text?).

>minimally a completely separate chapter,

Making this a separate chapter would make it rather complicated
to write the draft; there would be two grammars, and so on.
The motivation for updating mailto: came from the realization
(expressed by Larry at or around the URI Scheme BOF in San Diego
a few years back) that mailto: needs to be updated for IRIs.
I agreed, and am working on it. If we can iron out a few other
issues on the way, that's good, but we shouldn't loose the
main purpose and motivation for this update.

>starting with a Caveat that
>this won't work with existing software.

It won't work with all existing software, and I think this is
so noted. The very short Section 6 is actually dedicated to
this. If you have any ideas on how to better express things,
please propose actual text, thanks.

>UAs finding a mailto URL in
>a say Latin-1 encoded document won't get this right.

Some older UAs of course will not get this right. Newer
ones, however, do get it right.

>Maybe they will

Yes, older UAs do that for all URIs. This of course runs completely
counter to the purpose of URIs, which are supposed to be independent
of contexts such as which page they appear in. Please note that
in the case of mailto:, IRIs may actually work better than percent-
encoded URIs, because in the case of an IRI in a page encoded in
iso-8859-1, the software would just take that iso-8859-1 and
label it as iso-8859-1, e.g. in a Subject header. This is different
from HTTP, which works on bytes.

>maybe converting it to their default charset

Yes, because there is no standard so far, existing UAs may do anything
(including nothing).

>or even UTF-8, encoded

What would be the issue with this? This would be the right thing
to do pre-EAI, and is shown in various examples in the draft.

>then it will still take some years until this works as expected.

Have you read Section 6 of the current draft? I think it just
says that, even in somewhat different words:

   UTF-8-based percent-encoding should only be used in actual mailto
   URIs once it is well deployed in software that interprets mailto URIs
   (such as mail user agents).

>expected to get 2368bis hopelessly wrong.

And at that time we would also add the syntax for fallback addresses,
if we think it makes sense, yes?

>IRIs, not this worst case "mailto:"

Can you say exactly what you are alluding to?

>(or "xmppp:", where the URI czar

Ok, I guess I can agree with that.

>to discuss it, the URI list or maybe better (?) the rfc822 list.

I think that with respect to alt-address, this list here is
in the best position to discuss this. The decision really depends
on the positioning of alt-address, such as whether this is
supposed to kick in big time or just be an occasional fallback,
and so on.

Regards,   Martin.

---

From: Ted Hardie <[email-masked]>
Date: Sun, 29 Oct 2006 14:31:42 -0800

At the moment, the framework draft has this text:

7.1.  Impact on IRIs

   The mailto: schema defined in [RFC2368] and discussed in IRI
   [RFC3987] may need to be modified when this work is completed and
   standardized.

This implies that the working group will not take up work on the
mailto: scheme until the core specs of the work have moved
out of the experimental phase.  If the working group plans
to modify that, so that one or more URI/IRI schemes change prior to
the email protocols changes becoming standards, I think the framework
draft should say why.  

I'd also like to note that there are a lot of pieces of infrastructure
out there that presume they can include an email address (SNMP
MIBs, X.509 certificates, etc.).  There are also a fair number of identifiers
where there is  a user expectation that the identifier
can be "the same as" the email address, except for the scheme change 
(e.g. sip AORs).  Those, in turn can trickle into other places--as SIP URIs
can show up in radius or diameter.   A close look at at least a few of these
places to determine whether the proposed changes need to be
fed back into further protocol changes seems in order before
making the updates.  

I am tempted to suggest that the investigation of changes to the mailto: uri
should take place in a second working group, as I suspect that the
group of people is overlapping but not completely so.  

Putting on my AD hat for a moment, I will say that the IESG has not recently
liked to approve changes to a charter in advance of the working group
emitting one of its existing chartered items.  In this case, I'd suggest the
working group discuss what the framework document (which is an early
deliverable here) needs to say as a way of framing the discussion of when
the mailto URI needs to be tackled.
			regards,
				Ted Hardie

---

From: John C Klensin <[email-masked]>
Date: Sun, 29 Oct 2006 18:29:33 -0500

Ted,

Speaking for myself only...

I would be quite disappointed if the WG got distracted by taking
up mailto, or other IRI issues, at this time.  I think it would
be premature and distracting and that the reasons for "finish
first, see what the experimental use of the protocols tells us,
and then look at mailto along with standards-track efforts on
the protocols" still stand.

My concern with the "mailto" draft at this particular time is
that I fear interactions among whatever we are doing with IDNA,
the efforts on i18nemail, and changes to make mailto more
internationalization-friendly.  In a perfect world, I'd like to
see both of those development/revision efforts stabilize before
mailto is changed or extended.  Several email exchanges with
Martin over the last couple of days have left me less concerned
about changes we might have to back away from than I was a few
days ago, but I'm still not completely convinced that the need
for the proposed changes is great enough to justify the risk.

best,
   john

--On Sunday, 29 October, 2006 14:31 -0800 Ted Hardie
<[email-masked]> wrote:

>    [RFC3987] may need to be modified when this work is
> completed and    standardized.
> 
> 
> This implies that the working group will not take up work on
> the mailto: scheme until the core specs of the work have moved
> out of the experimental phase.  If the working group plans to
> modify that, so that one or more URI/IRI schemes change prior
> to the email protocols changes becoming standards, I think the
> framework draft should say why.  
> 
> I'd also like to note that there are a lot of pieces of
> infrastructure out there that presume they can include an
> email address (SNMP MIBs, X.509 certificates, etc.).  There
> are also a fair number of identifiers where there is  a user
> expectation that the identifier can be "the same as" the email
> address, except for the scheme change  (e.g. sip AORs).
> Those, in turn can trickle into other places--as SIP URIs can
> show up in radius or diameter.   A close look at at least a
> few of these places to determine whether the proposed changes
> need to be fed back into further protocol changes seems in
> order before making the updates.  
> 
> I am tempted to suggest that the investigation of changes to
> the mailto: uri should take place in a second working group,
> as I suspect that the group of people is overlapping but not
> completely so.  
> 
> Putting on my AD hat for a moment, I will say that the IESG
> has not recently liked to approve changes to a charter in
> advance of the working group emitting one of its existing
> chartered items.  In this case, I'd suggest the working group
> discuss what the framework document (which is an early
> deliverable here) needs to say as a way of framing the
> discussion of when the mailto URI needs to be tackled.
> 			regards,
> 				Ted Hardie
> 
> 
> 
> 
> 
> 
>  
>

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 31 Oct 2006 12:04:28 -0000

> mailto provisions should be reviewed and, if necessary, updated.

That is one way.

What we are looking for is a means to say "this is the mail address to  
send to, but if that does not work, then you can try this other one  
instead. But please do not try both at the same time."

Now there is no reason why Martin should not define such a feature into  
his draft, and there is no reason why he should not (just by coincidence,  
of course :-) ) do it using the same syntax as we are using for UTF8SMTP.

But in that case, please do not publish it until UTF8SMTP is out there as  
an Experimental Protocol (but that is a sensible time scale anyway). And  
bear in mind that a future standardized version of UTF8SMTP would then be  
constrained not to alter that syntax - which it would probably not want to  
do anyway.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 31 Oct 2006 12:12:18 -0000

> group of people is overlapping but not completely so.

The proper place for such discussions is on the [email-masked] mailing list,  
and most of the current discussions between Frank and Martin really belong  
there and should be moved there.

Naturally, this WG would like to be kept informed of matters related to  
UTF-8, but the present proposals to allow UTF-8 either %-encoded or raw in  
an IRI seem fine.

And this WG would certainly expect to be consulted if some proposal to  
include alt-addresses were to be incorporated.