Hello Harald, It seems that the scenarios draft has expired. Do you plan to resubmit it, or not? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst <at> it.aoyama.ac.jp
I plan to resubmit it as soon as I have verified consistency with the
framework draft. But getting the framework draft to the IESG is more
important - and also requires me to do some homework.
Harald
--On 9. januar 2007 16:44 +0900 Martin Duerst <duerst <at> it.aoyama.ac.jp>
wrote:
> Hello Harald,
>
> It seems that the scenarios draft has expired. Do you plan to resubmit
> it, or not?
>
> Regards, Martin.
>
>
># -#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
># -#-# http://www.sw.it.aoyama.ac.jp mailto:duerst <at> it.aoyama.ac.jp
>#
>
>
The EAI WG hereby requests publication of draft-ietf-eai-framework-04 as
an Informational document.
The EAI WG further requests that an IETF Last Call be performed on the
document prior to approval.
The writeup below is based on draft-ietf-proto-wgchair-doc-shepherding-08.
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?
Harald Alvestrand is Document Shepherd. He has reviewed the document.
(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?
The review in the WG has been thorough, and many people who are not WG
members are aware of the document.
We think that the IETF would benefit from having its attention called to
the document, so that people are aware that the EAI experiment is being
tried, and so that any issues with the general approach taken can be
raised before the WG settles on final specifications for the technical
components of the proposal; this is the reason for asking for
publication of this document before the technical specifications are
finished.
(1.c) Does the Document Shepherd have concerns that the document
(Continue reading)
The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'Overview and Framework for Internationalized Email ' <draft-ietf-eai-framework-04.txt> as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf <at> ietf.org mailing lists by 2007-01-26. Exceptionally, comments may be sent to iesg <at> ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-eai-framework-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14701&rfc_flag=0
(1) This version still has some editor's notes. Are these intended
for publication?
(2) In section 1.3:
An "i18mail user" has one or more non-ASCII email addresses. Such a
user may have ASCII addresses too; if the user has more than one
email account and corresponding address, or more than one alias for
the same address, he or she has some method to choose which address
to use on outgoing email. Note that under this definition, it is not
possible to tell from the address that an email sender or recipient
is an i18mail user. There is no such thing as an "i18mail message";
the term applies only to users and their agents and capabilities.
Does the second-to-last sentence refer to an ASCII address, or any
address? The wording implies any address, but if an address is
non-ASCII, surely that is a good sign that the owner of that address
is an i18mail user?
(3) In section 4.3:
the risk should be
minimized by the fact that the selection of submission servers are
presumably under the control of the sender's client and the selection
of potential intermediate relays is under the control of the
administration of the final delivery server.
[snip]
For situations in which a client encounters a server that does not
support UTF8SMTP, there are basically two possibilities:
(Continue reading)
--On Tuesday, 16 January, 2007 18:44 -0800 Randall Gellens
<randy <at> qualcomm.com> wrote:
> (1) This version still has some editor's notes. Are these
> intended for publication?
No. I had intended to change the xml2rfc parameters to shut
them off when I submitted the draft and forgot. My apologies.
If they are significantly confusing to anyone, let me know and
I'll post a new version of the draft.
john
At 9:45 AM -0500 1/17/07, John C Klensin wrote: > --On Tuesday, 16 January, 2007 18:44 -0800 Randall Gellens > <randy <at> qualcomm.com> wrote: > >> (1) This version still has some editor's notes. Are these >> intended for publication? > > No. I had intended to change the xml2rfc parameters to shut > them off when I submitted the draft and forgot. My apologies. > If they are significantly confusing to anyone, let me know and > I'll post a new version of the draft. I don't think they're confusing, but some of them suggest unresolved issues. -- -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The curse of all Art is that the devotee or disciple is always more certain than the Priest. --Rudyard Kipling
At 9:45 AM -0500 1/17/07, John C Klensin wrote: > --On Tuesday, 16 January, 2007 18:44 -0800 Randall Gellens > <randy <at> qualcomm.com> wrote: > >> (1) This version still has some editor's notes. Are these >> intended for publication? > > No. I had intended to change the xml2rfc parameters to shut > them off when I submitted the draft and forgot. My apologies. > If they are significantly confusing to anyone, let me know and > I'll post a new version of the draft. I don't think they're confusing, but some of them suggest unresolved issues. -- -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The curse of all Art is that the devotee or disciple is always more certain than the Priest. --Rudyard Kipling _______________________________________________ Ietf mailing list Ietf <at> ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Randall Gellens wrote: > (1) This version still has some editor's notes. Are these intended > for publication? No. The writeup didn't get copied into the Last Call, but as WG chair, I believe that the document is complete if all the editor's notes are deleted. Some of them point to areas that might be improved, but, in my opinion, such improvements are not a requirement for publication. > > > (2) In section 1.3: > An "i18mail user" has one or more non-ASCII email addresses. Such a > user may have ASCII addresses too; if the user has more than one > email account and corresponding address, or more than one alias for > the same address, he or she has some method to choose which address > to use on outgoing email. Note that under this definition, it is not > possible to tell from the address that an email sender or recipient > is an i18mail user. There is no such thing as an "i18mail message"; > the term applies only to users and their agents and capabilities. > > Does the second-to-last sentence refer to an ASCII address, or any > address? The wording implies any address, but if an address is > non-ASCII, surely that is a good sign that the owner of that address > is an i18mail user? Right. The situation that is being warned against is taking an ASCII address as a clear sign that the address owner is not an i18mail user. > > > (3) In section 4.3: > the risk should be > minimized by the fact that the selection of submission servers are(Continue reading)
At 8:44 PM +0100 1/17/07, Harald Alvestrand wrote:
>> (2) In section 1.3:
>> An "i18mail user" has one or more non-ASCII email addresses. Such a
>> user may have ASCII addresses too; if the user has more than one
>> email account and corresponding address, or more than one alias for
>> the same address, he or she has some method to choose which address
>> to use on outgoing email. Note that under this definition, it is not
>> possible to tell from the address that an email sender or recipient
>> is an i18mail user. There is no such thing as an "i18mail message";
>> the term applies only to users and their agents and capabilities.
>>
>> Does the second-to-last sentence refer to an ASCII address, or any
>> address? The wording implies any address, but if an address is
>> non-ASCII, surely that is a good sign that the owner of that
>> address is an i18mail user?
> Right. The situation that is being warned against is taking an
> ASCII address as a clear sign that the address owner is not an
> i18mail user.
I'd like to see the text improved to make this more clear. As a
suggestion, replace:
Note that under this definition, it is not possible to tell from
the address that an email sender or recipient is an i18mail user.
with:
Note that under this definition, it is not possible to tell from
an ASCII address if an email sender or recipient is an i18mail
(Continue reading)
RSS Feed1 | |
|---|---|
9 | |
1 | |
32 | |
42 | |
66 | |
30 | |
109 | |
38 | |
142 | |
33 | |
116 | |
42 | |
4 | |
18 | |
57 | |
45 | |
44 | |
55 | |
61 | |
69 | |
13 | |
46 | |
47 | |
98 | |
242 | |
135 | |
69 | |
36 | |
46 | |
96 | |
84 | |
22 | |
9 | |
13 | |
72 | |
2 | |
45 | |
19 | |
19 | |
27 | |
98 | |
96 | |
97 | |
42 | |
8 | |
1 | |
12 | |
5 | |
4 | |
28 | |
4 | |
25 | |
28 | |
56 | |
6 | |
6 | |
11 | |
27 | |
19 | |
47 | |
17 | |
114 | |
44 | |
140 | |
43 | |
37 | |
84 | |
49 | |
146 | |
254 | |
184 | |
169 | |
96 | |
163 | |
256 | |
2 | |
57 | |
114 | |
74 | |
46 | |
58 | |
90 | |
25 | |
1 | |
57 | |
17 | |
3 |
