headers
Joseph Yee | 10 Jul 2012 18:13

Shepherd report review of mailinglist-02

Hi.

We have just completed a draft of the Shepherd's report and
corresponding pass through the document prior to handing
the mailinglist document off to IESG.

The review turned up several editorial and related issues.  If
possible, we would like to see them corrected into a -03 before
the document is handed off for IETF Last Call.   Getting nits
fixed at this point often saves a lot of time quibbling about
them later.

WG participants: some of these issues are substantive, see
notes 8, 9, and 11 below.

Authors of other documents.  This type of review is a painful
and time-consuming process.  I used to defer parts of it until
AUTH48, but have learned my lesson: it needs to be done either
before we request IETF Last Call, during or after that Last
Call when ADs or other members of the community start
nit-picking, or during AUTH48.  It only gets more painful at
later stages.   If possible, review your own documents to see
if you can spot and fix these sorts of things before I/we have
to.

John, if you don't have time to make these changes within the
next few days but can supply document source and any comments,
we will try to get a new version out.  we really, really want
this document in IETF LC before Vancouver if that is at all all
possible and we are running out of time.
(Continue reading)

Permalink | Reply |
headers
John R Levine | 10 Jul 2012 18:46

Re: Shepherd report review of mailinglist-02

Thanks for this, I'll do a new version later this week.  I also have some 
comments from the WG that I was waiting to fold in.

R's,
John

On Tue, 10 Jul 2012, Joseph Yee wrote:

> Hi.
>
> We have just completed a draft of the Shepherd's report and
> corresponding pass through the document prior to handing
> the mailinglist document off to IESG.
>
> The review turned up several editorial and related issues.  If
> possible, we would like to see them corrected into a -03 before
> the document is handed off for IETF Last Call.   Getting nits
> fixed at this point often saves a lot of time quibbling about
> them later.
>
> WG participants: some of these issues are substantive, see
> notes 8, 9, and 11 below.
>
> Authors of other documents.  This type of review is a painful
> and time-consuming process.  I used to defer parts of it until
> AUTH48, but have learned my lesson: it needs to be done either
> before we request IETF Last Call, during or after that Last
> Call when ADs or other members of the community start
> nit-picking, or during AUTH48.  It only gets more painful at
> later stages.   If possible, review your own documents to see
(Continue reading)

Permalink | Reply |
headers
John C Klensin | 10 Jul 2012 18:54

Re: Shepherd report review of mailinglist-02


--On Tuesday, July 10, 2012 12:46 -0400 John R Levine
<johnl <at> taugh.com> wrote:

> Thanks for this, I'll do a new version later this week.  I
> also have some comments from the WG that I was waiting to fold
> in.

Excellent.

Thanks (from both of us)
   john
Permalink | Reply |
headers
Martin J. Dürst | 11 Jul 2012 11:09
Picon
Gravatar

Re: Shepherd report review of mailinglist-02

Hello Joseph, John, John, and others,

On 2012/07/11 1:13, Joseph Yee wrote:

> (11) Section 3.1

> In paragraph 3:
>     The most commonly-used URI schemes in List-* headers tend to
> be HTTP
>     and mailto, although they sometimes include HTTPS and FTP,
> and in
>     principle can contain any valid URI.
>
> Use "MAILTO", not "mailto" unless you want you waste your time
> and ours in a silly argument.

Scheme names are usually written lower-case, so I suggest to streamline 
this as:

The most commonly-used URI schemes in List-* headers tend to be http
and mailto, although they sometimes include https and ftp, and in
principle can contain any valid URI.

> Paragraph 4 is problematic because the whole state of IRIs is
> up in the air right now.  It might be better to say something
> like:
>
>     Even if a scheme permits an internationalized form, it
>     should use a pure ASCII form of the URI described in
>     [RFC3986].  Future work may extend
(Continue reading)

Permalink | Reply |
headers
John C Klensin | 11 Jul 2012 14:23

Re: Shepherd report review of mailinglist-02

Hi Martin,

Thanks for the comments -- partial responses below.

--On Wednesday, July 11, 2012 18:09 +0900 "\"Martin J. Dürst\""
<duerst <at> it.aoyama.ac.jp> wrote:

>...
>> (11) Section 3.1
> 
>> In paragraph 3:
>>     The most commonly-used URI schemes in List-* headers tend
>>     to be HTTP
>>     and mailto, although they sometimes include HTTPS and FTP,
>> and in
>>     principle can contain any valid URI.
>> 
>> Use "MAILTO", not "mailto" unless you want you waste your time
>> and ours in a silly argument.
> 
> Scheme names are usually written lower-case, so I suggest to
> streamline this as:
> 
> The most commonly-used URI schemes in List-* headers tend to
> be http
> and mailto, although they sometimes include https and ftp, and
> in principle can contain any valid URI.

wfm.  Our concern was only about having some in upper case and
some in lower.
(Continue reading)

Permalink | Reply |
headers
John R Levine | 11 Jul 2012 16:17

Re: Shepherd report review of mailinglist-02

>> The most commonly-used URI schemes in List-* headers tend to
>> be http and mailto, although they sometimes include https and ftp, and
>> in principle can contain any valid URI.
>
> wfm.  Our concern was only about having some in upper case and
> some in lower.

The editors have a style book, and I presume that they will adjust stuff 
like this to match the style as they do the normal copy edit.  Why argue 
about it here?

R's,
John
Permalink | Reply |
headers
Martin J. Dürst | 13 Jul 2012 13:04
Picon
Gravatar

Confusion about backwards-compatibility of 3987bis/IRIs (was: Re: Shepherd report review of mailinglist-02)

[cc'ed to the mailing list of the IRI WG]

[IRI WG: This came up in the EAI (email address internationalization) WG 
when discussing 
http://tools.ietf.org/rfcdiff?url2=draft-ietf-eai-mailinglistbis-03, but 
it's highly relevant to the work of the IRI WG.]

[Everybody, please remove the EAI mailing list if you continue 
discussing IRIs, and the IRI mailing list if you discuss the 
mailinglistbis draft, thanks!]

Hello John,

On 2012/07/11 21:23, John C Klensin wrote:
> Hi Martin,

>> ...
>> As draft-ietf-iri-3987bis isn't yet done, its difficult to say
>> exactly, but while there are many changes and tweaks in the
>> details, the basic principles are exactly the same. Saying
>> that you can't cite RFC 3987 because there's a WG that is
>> working on updating it would be about the same as saying you
>> can't cite RFC 2616 (HTTP) because there's a WG working on
>
> The difference is that the group revising HTTP seems to be bound
> by strict upward compatibility.   The (tentative) decision to
> change the role of IRIs from "UI overlay" to "separate protocol
> element mostly suitable for new protocols" is a significant
> modification that calls 3987 into question.  My own guess is
> that, even if IRIs continue down that path, a profile will
(Continue reading)

Permalink | Reply |
headers
Martin J. Dürst | 16 Jul 2012 11:56
Picon
Gravatar

Re: [EAI] Confusion about backwards-compatibility of 3987bis/IRIs

[I meant to cc the IRI WG, but apparently I didn't. This now goes 
separately to the IRI WG, if you want it to be cross-posted because it's 
relevant to both groups, please cc. ima <at> ietf.org, the mailing list of 
the EAI WG.]

On 2012/07/13 20:04, "Martin J. Dürst" wrote:
> [cc'ed to the mailing list of the IRI WG]
>
> [IRI WG: This came up in the EAI (email address internationalization) WG
> when discussing
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-eai-mailinglistbis-03, but
> it's highly relevant to the work of the IRI WG.]
>
> [Everybody, please remove the EAI mailing list if you continue
> discussing IRIs, and the IRI mailing list if you discuss the
> mailinglistbis draft, thanks!]
>
>
> Hello John,
>
> On 2012/07/11 21:23, John C Klensin wrote:
>> Hi Martin,
>
>>> ...
>>> As draft-ietf-iri-3987bis isn't yet done, its difficult to say
>>> exactly, but while there are many changes and tweaks in the
>>> details, the basic principles are exactly the same. Saying
>>> that you can't cite RFC 3987 because there's a WG that is
>>> working on updating it would be about the same as saying you
>>> can't cite RFC 2616 (HTTP) because there's a WG working on
(Continue reading)

Permalink | Reply |
headers
John R Levine | 12 Jul 2012 23:45

Re: Shepherd report review of mailinglist-02

OK, I've posted an -03 that I think takes into consideration everyone's 
comments.  The comment that lists are inanimate messages while list agents 
are software was a good one, that let me go through and make the document 
(I think) considerably clearer.

Just so you don't think I ignored you:

> FWIW, I've never seen a large list handled by putting hundreds
> of messages into a single SMTP envelope and handing off to a
> conventional submission server.

It's quite common now, e.g., one of Mailman's normal config options.

> In a world in which we encourage explicit confirmation as part
> of an email subscription process for other reasons (ones with
> which you are thoroughly familiar), putting something that
> requires SMTPUTF8 handling into the automated confirmation
> message would not be burdensome.

I didn't do that for two reasons.  One is that while requiring signup 
confirmation usually a good idea, there are real situations where it's not 
needed, and this is the wrong place to argue about list policies.  Also, 
this could apply to lists where the manager is upgrading an existing list 
to EAI, and getting all of a list's subscribers to reconfirm is, ah, 
challenging.  So it mentions it as an option, not as advice.

> We've essentially said that in-transit message downgrading is
> impossible unless the message contains no non-ASCII addresses
> and has non-ASCII material only in header fields in which
> encoded words can be used.  Absent a whole series of provisions
(Continue reading)

Permalink | Reply |
headers
John C Klensin | 13 Jul 2012 01:08

Re: Shepherd report review of mailinglist-02

WG participants,

I've responded to some of John L's points below -- read or not
as you like.  Either way, consider this a heads-up that we will
ask Pete to start the process of initiating an IETF Last Call in
circa 24 hours.  So, if there is anything here you don't like,
this is your last chance to speak up inside the WG.

John,

Inline.

    john

--On Thursday, July 12, 2012 17:45 -0400 John R Levine
<johnl <at> taugh.com> wrote:

> OK, I've posted an -03 that I think takes into consideration
> everyone's comments.  The comment that lists are inanimate
> messages while list agents are software was a good one, that
> let me go through and make the document (I think) considerably
clearer.
> 
> Just so you don't think I ignored you:
> 
>> FWIW, I've never seen a large list handled by putting hundreds
>> of messages into a single SMTP envelope and handing off to a
>> conventional submission server.
> 
> It's quite common now, e.g., one of Mailman's normal config
(Continue reading)

Permalink | Reply |
headers
Martin J. Dürst | 13 Jul 2012 13:27
Picon
Gravatar

Re: Shepherd report review of mailinglist-02

Hello John, others,

On 2012/07/13 8:08, John C Klensin wrote:
> WG participants,
>
> I've responded to some of John L's points below -- read or not
> as you like.  Either way, consider this a heads-up that we will
> ask Pete to start the process of initiating an IETF Last Call in
> circa 24 hours.  So, if there is anything here you don't like,
> this is your last chance to speak up inside the WG.

I'm sorry, but I feel I have to take this chance.

As you can see in detail in a mail that I sent a few minutes ago 
(Subject: Confusion about backwards-compatibility of 3987bis/IRIs), I 
think that the very recent removal of the reference to RFC 3987 (and 
possibly also RFC 6068, but then other URI schemes are also not 
mentioned with a reference) is based on confusion only and is a 
disservice to the reader.

Also, my proposal of different text for the "%-routing problem", which 
is clearer about the source of the problem, in particular that it's an 
implementation problem (correct escaping/unescaping) and not an a-priori 
problem, hasn't been taken into account, and I don't know why.

For your reference, here is the current draft text:

<<<<
    The encoding technique specified in [RFC3986] is to use a pair of hex
    digits preceded by a percent sign, but percent signs have been used
(Continue reading)

Permalink | Reply |
headers
John R Levine | 13 Jul 2012 15:36

Re: Shepherd report review of mailinglist-02

> Also, my proposal of different text for the "%-routing problem", which is 
> clearer about the source of the problem, in particular that it's an 
> implementation problem (correct escaping/unescaping) and not an a-priori 
> problem, hasn't been taken into account, and I don't know why.

I looked at your language, and it seemed to me less clear than what's 
there.  The problem is very simple, some MTAs mishandle addresses that 
contain % signs.  All we need to do is note it, not tell people how we 
think they should fix it or work around it.

Regards,
John Levine, johnl <at> taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
Permalink | Reply |
headers
John C Klensin | 13 Jul 2012 18:03

Re: Shepherd report review of mailinglist-02


--On Friday, July 13, 2012 09:36 -0400 John R Levine
<johnl <at> taugh.com> wrote:

>> Also, my proposal of different text for the "%-routing
>> problem", which is  clearer about the source of the problem,
>> in particular that it's an  implementation problem (correct
>> escaping/unescaping) and not an a-priori  problem, hasn't
>> been taken into account, and I don't know why.
> 
> I looked at your language, and it seemed to me less clear than
> what's there.  The problem is very simple, some MTAs mishandle
> addresses that contain % signs.  All we need to do is note it,
> not tell people how we think they should fix it or work around
> it.

Agreed, but I suggest that there are really two separate
problems.  The first is the one you mention.  The second is that
there is a mismatch between the MAILTO syntax and definition
(necessitated by the URI syntax) and the specification of 5321,
essentially 
"no one gets to interpret the local part string at all".  It is
correct to talk about that as an implementation problem, but it
is an implementation problem that is so widespread as to justify
security warnings, etc. Similar problems --and probably similar
appropriate warnings-- apply to the use of a number of special
characters (notably "+" and "/" in local parts versus the use of
those characters in URIs and HTML.  Not the fault of mailto, but
traps for the unwary.  And we have ample empirical evidence that
there are lots of unwary (or indifferent) implementers and
(Continue reading)

Permalink | Reply |
headers
Joseph Yee | 13 Jul 2012 21:12

Re: Shepherd report review of mailinglist-02



On Fri, Jul 13, 2012 at 9:36 AM, John R Levine <johnl <at> taugh.com> wrote:
Also, my proposal of different text for the "%-routing problem", which is clearer about the source of the problem, in particular that it's an implementation problem (correct escaping/unescaping) and not an a-priori problem, hasn't been taken into account, and I don't know why.

I looked at your language, and it seemed to me less clear than what's there.  The problem is very simple, some MTAs mishandle addresses that contain % signs.  All we need to do is note it, not tell people how we think they should fix it or work around it.


<thought type="personal">

Agreed that describing how to manage % sign is out of scope for this document, but noting it helps readers.

</>
Joseph
 
Regards,
John Levine, johnl <at> taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
IMA mailing list
IMA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
IMA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ima
Permalink | Reply |
headers
John C Klensin | 13 Jul 2012 21:37

Re: Shepherd report review of mailinglist-02


--On Friday, July 13, 2012 15:12 -0400 Joseph Yee
<jyee <at> afilias.info> wrote:

>> <thought type="personal">
> 
> Agreed that describing how to manage % sign is out of scope
> for this document, but noting it helps readers.

<personal>

Once we get EAI wound down or suspended, I want to have a
discussion with the ADs (and maybe the IAB, who have expressed
interest in the past) about re-doing RFC 3696 and/or 4084 to
reflect a whole series of things that either weren't handled
well the first time or need updating to reflect i18n (among
other things).  I'd be delighted to retire to junior author if
someone else is interested in what I think is the right place to
discuss advice about funky characters in mail and how careful
one needs to be if one is going to transform things from one set
of syntax conventions to another one.

Consider that both an offer and, for people who like putting
their names on RFCs, a bribe.

   john
Permalink | Reply |
headers
Martin J. Dürst | 24 Jul 2012 10:30
Picon
Gravatar

Re: Shepherd report review of mailinglist-02

Hello John,

On 2012/07/14 4:37, John C Klensin wrote:

> <personal>
>
> Once we get EAI wound down or suspended, I want to have a
> discussion with the ADs (and maybe the IAB, who have expressed
> interest in the past) about re-doing RFC 3696 and/or 4084 to
> reflect a whole series of things that either weren't handled
> well the first time or need updating to reflect i18n (among
> other things).

I plan to have a look at RFC 3696. Ideally, the issues described therein 
should be clear from the base specs. If we can do anything in 3987bis or 
in the mailto draft, let's do that.

> I'd be delighted to retire to junior author if
> someone else is interested in what I think is the right place to
> discuss advice about funky characters in mail and how careful
> one needs to be if one is going to transform things from one set
> of syntax conventions to another one.

There are most possibly other cases where funky characters in mail are 
relevant, but for the origin of these discussions, I think first and 
foremost, it would be good to make sure that whatever is needed is in 
the mailto draft. My personal guess is that we have enough examples in 
there to make any serious implementer aware of the issues (and 
superficial implementers won't read the document anyway), but if you see 
any way to be clearer, please propose additional text or examples. I'll 
very gladly integrate them into the draft.

Regards,   Martin.

> Consider that both an offer and, for people who like putting
> their names on RFCs, a bribe.
>
>     john
>
> _______________________________________________
> IMA mailing list
> IMA <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ima
>
Permalink | Reply |
headers
Martin J. Dürst | 14 Jul 2012 04:06
Picon
Gravatar

Re: Shepherd report review of mailinglist-02

Hello John,

Thanks for your mail. I think we are getting closer to where we have a 
misunderstanding.

On 2012/07/13 22:36, John R Levine wrote:
>> Also, my proposal of different text for the "%-routing problem", which
>> is clearer about the source of the problem, in particular that it's an
>> implementation problem (correct escaping/unescaping) and not an
>> a-priori problem, hasn't been taken into account, and I don't know why.
>
> I looked at your language, and it seemed to me less clear than what's
> there.

Sorry about that. I don't claim that my text is perfect.

> The problem is very simple, some MTAs mishandle addresses that
> contain % signs.

Here is where we have the misunderstanding/disagreement. The original 
problem is NOT what MTAs do with addresses that contain % signs. If e.g. 
I enter something like gorby%kremvax <at> example.com into a To field in my 
MUA, then that might work somehow, or not, but that's secondary.

To continue, if there is an URI mailto:gorby%25kremvax <at> example.com, and 
it gets correctly converted to gorby%kremvax <at> example.com, then that 
might work somehow, or not, but that's again irrelevant.

The actual problem we want to discuss (on which point I very strongly 
agree with John Klensin) is the case where there is e.g. an URI of the 
form mailto:unlikely%3Faddress <at> example.com, which should end up in a 
mail to unlikely?address <at> example.com, but because the unescaping is 
missing, produces a mail to unlikely%3Faddress <at> example.com.

The address unlikely%3Faddress <at> example.com is essentially wrong. What 
some mailers do with such an address, or with addresses containing % in 
general, just affects who wrongly gets (or doesn't get) the mail, and 
how easy it might be to debug the problem. But the problem happened earlier.

> All we need to do is note it, not tell people how we
> think they should fix it or work around it.

Just to note it may be okay (a nugde in the right direction for a fix 
can't hurt though), but what's important is that the focus has to be on 
unescaping %-encoding when moving from mailto: to raw email addresses, 
rather than on what mailers do with mail addresses that have a % in them.

BTW, the examples are all taken from RFC 6068, so again it might not be 
such a bad idea to reference it.

Regards,   Martin.

> Regards,
> John Levine, johnl <at> taugh.com, Taughannock Networks, Trumansburg NY
> "I dropped the toothpaste", said Tom, crestfallenly.
>
Permalink | Reply |
headers
Alexey Melnikov | 13 Jul 2012 13:10
Favicon

Re: Shepherd report review of mailinglist-02

Hi John,

On 12/07/2012 22:45, John R Levine wrote:
> OK, I've posted an -03 that I think takes into consideration 
> everyone's comments.  The comment that lists are inanimate messages 
> while list agents are software was a good one, that let me go through 
> and make the document (I think) considerably clearer.

I think you need Informative references for mailto:, http: and ftp: URI 
schemes. I am not sure why you removed the mailto: reference from the 
document.

But otherwise this looks good to me.
Permalink | Reply |
headers
John R Levine | 13 Jul 2012 15:39

Re: Shepherd report review of mailinglist-02

> I think you need Informative references for mailto:, http: and ftp: URI 
> schemes. I am not sure why you removed the mailto: reference from the 
> document.

The various URIs only come up in the context of list headers, and there's 
refefrence to RFC 2369 which defines them and does refer to the sources of 
the various schemes.  If you really think we need to tell people where to 
find mailto: and http: I can add refererences, but since the only 
discussion is with respect to % signs in the syntax, not to what they do, 
I don't see the need.

Regards,
John Levine, johnl <at> taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
Permalink | Reply |
headers
Alexey Melnikov | 13 Jul 2012 17:09
Favicon

Re: Shepherd report review of mailinglist-02

On 13/07/2012 14:39, John R Levine wrote:
>> I think you need Informative references for mailto:, http: and ftp: 
>> URI schemes. I am not sure why you removed the mailto: reference from 
>> the document.
>
> The various URIs only come up in the context of list headers, and 
> there's refefrence to RFC 2369 which defines them and does refer to 
> the sources of the various schemes.  If you really think we need to 
> tell people where to find mailto: and http: I can add refererences, 
> but since the only discussion is with respect to % signs in the 
> syntax, not to what they do, I don't see the need.

I believe the rule is that anything mentioned in the document that is 
not defined in it needs to be referenced.
Permalink | Reply |
headers
John R Levine | 13 Jul 2012 17:34

Re: Shepherd report review of mailinglist-02

> I believe the rule is that anything mentioned in the document that is not 
> defined in it needs to be referenced.

My. there's a can of worms.  We don't reference RFC 6531 for SMTPUTF8, 
6532 for non-ASCII headers, 5322 for the From, Reply-To, and Sender 
headers, 5598 for MTA, MDA, and MUA, or 20 for ASCII.

RFC 3986, which we do reference, describes all of the URI schemes that we 
mention.

It probably would be a good idea to reference 6531 and 6532, though.

Regards,
John Levine, johnl <at> taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
Permalink | Reply |
headers
Alexey Melnikov | 13 Jul 2012 19:28
Favicon

Re: Shepherd report review of mailinglist-02

On 13/07/2012 16:34, John R Levine wrote:
>> I believe the rule is that anything mentioned in the document that is 
>> not defined in it needs to be referenced.
>
> My. there's a can of worms.

It can be.

> We don't reference RFC 6531 for SMTPUTF8, 6532 for non-ASCII headers, 
> 5322 for the From, Reply-To, and Sender headers, 5598 for MTA, MDA, 
> and MUA, or 20 for ASCII.
>
> RFC 3986, which we do reference, describes all of the URI schemes that 
> we mention.

Well, no. It describes the generic syntax. But if one wants to study 
mailto: definition in more details, there is no reference.

> It probably would be a good idea to reference 6531 and 6532, though.

Yes. And ASCII, because it is kind of required to understand "non-ASCII" 
;-).
Permalink | Reply |
headers
Martin J. Dürst | 14 Jul 2012 04:14
Picon
Gravatar

Re: Shepherd report review of mailinglist-02

On 2012/07/14 0:34, John R Levine wrote:

> My. there's a can of worms. We don't reference RFC 6531 for SMTPUTF8,
> 6532 for non-ASCII headers, 5322 for the From, Reply-To, and Sender
> headers, 5598 for MTA, MDA, and MUA, or 20 for ASCII.
>
> RFC 3986, which we do reference, describes all of the URI schemes that
> we mention.

Small detail, maybe relevant, maybe not: RFC 3986 only describes the 
general syntax of URIs. It does not define individual schemes. The last 
time general URI syntax and individual schemes were described in the 
same spec was in RFC 1738, which is two generations ago (with RFC 2396 
in between).

> It probably would be a good idea to reference 6531 and 6532, though.

Yes indeed.

Regards,   Martin.
Permalink | Reply |
headers
John C Klensin | 13 Jul 2012 18:04

Re: Shepherd report review of mailinglist-02


--On Friday, July 13, 2012 16:09 +0100 Alexey Melnikov
<alexey.melnikov <at> isode.com> wrote:

> On 13/07/2012 14:39, John R Levine wrote:
>>> I think you need Informative references for mailto:, http:
>>> and ftp:  URI schemes. I am not sure why you removed the
>>> mailto: reference from  the document.
>> 
>> The various URIs only come up in the context of list headers,
>> and  there's refefrence to RFC 2369 which defines them and
>> does refer to  the sources of the various schemes.  If you
>> really think we need to  tell people where to find mailto:
>> and http: I can add refererences,  but since the only
>> discussion is with respect to % signs in the  syntax, not to
>> what they do, I don't see the need.
> 
> I believe the rule is that anything mentioned in the document
> that is not defined in it needs to be referenced.

Then, partially following John's logic, it would be as
reasonable (or more so) to clarify that the particular URIs and
references to them appear in 2369.

Precisely because this document is an informational one that
identifies issues rather than a standards track protocol spec,
I'd like to minimize the number of reference dependencies to the
degree possible.  That makes saying (whether explicitly or not)
"if you want to understand this part of the discussion, you had
better understand 2369, just as other parts of the discussion
require some understanding of 5321/5322" more reasonable that
trying to review 2369 in line and thereby talking about the
particular URIs that might be relevant.

Just my opinion, YMMD.

    john
Permalink | Reply |
headers
John Levine | 13 Jul 2012 21:41

Re: references, was Shepherd report review of mailinglist-02

I don't have strong religious beliefs about references, if we need
them we can put them in.  When I look at the IESG statement about
references, it says "It is not considered necessary to cite basic
specifications that may be safely assumed to be known to
practitioners" which I think lets us off the hook for RFC 20* for
ASCII, 5321 for bounce addresses, and 5322 for common mail message
headers.

How about if I add normative refs to 6531 for SMTPUTF8 and 6532
for non-ASCII headers, and put back 6068 for mailto:, since that's
the only URI scheme we talk about beyond a simple mention?

R's,
John

http://www.ietf.org/iesg/statement/normative-informative.html

* - for which I just filed an erratum, by the way
Permalink | Reply |
headers
John Levine | 14 Jul 2012 02:36

Re: references, was Shepherd report review of mailinglist-02

I just submitted -04 which differs from -03 only in that there is a
new sentence in the introduction with a normative referenc to RFC
6530, which describes all the EAI stuff including SMTPUTF8 and
non-ASCII addresses in mail headers, and a normative reference to RFC
6068 which describes percent encoded addresses in mailto URIs.

R's,
John

PS: Since the point of a normative reference is that a reader is
expected to be familiar with the reference to understand the document,
I'm asuming that means that readers are familiar with the normative
references in the normative references and so forth.  So now that I've
added a reference to RFC 6530, you might want to reread RFC20, RFC791,
RFC821, RFC822, RFC974, RFC1034, RFC1035, RFC1047, RFC1123, RFC1305,
RFC1652, RFC1869, RFC1870, RFC1894, RFC1970, RFC2026, RFC2028,
RFC2033, RFC2034, RFC2045, RFC2046, RFC2048, RFC2119, RFC2192,
RFC2234, RFC2244, RFC2246, RFC2277, RFC2279, RFC2327, RFC2387,
RFC2396, RFC2434, RFC2460, RFC2554, RFC2743, RFC2782, RFC2821,
RFC2822, RFC2860, RFC2978, RFC3023, RFC3190, RFC3207, RFC3280,
RFC3339, RFC3454, RFC3461, RFC3462, RFC3463, RFC3464, RFC3501,
RFC3550, RFC3551, RFC3555, RFC3629, RFC3798, RFC3848, RFC3864,
RFC3885, RFC3886, RFC3887, RFC3888, RFC3986, RFC4013, RFC4234,
RFC4288, RFC4291, RFC4409, RFC4422, RFC4467, RFC4468, RFC4646,
RFC4647, RFC4648, RFC4954, RFC5198, RFC5226, RFC5234, RFC5248,
RFC5321, RFC5322, RFC5646, RFC5890, RFC6152, RFC6409, RFC6522,
RFC6531, RFC6532, RFC6533, ISO 639, NIST SHA-1, and the Apple AIFF-C
spec.
Permalink | Reply |
headers
S Moonesamy | 13 Jul 2012 21:56
Favicon

Re: Shepherd report review of mailinglist-02

Hi John,
At 09:04 13-07-2012, John C Klensin wrote:
>Then, partially following John's logic, it would be as
>reasonable (or more so) to clarify that the particular URIs and
>references to them appear in 2369.

If I recall correctly we discussed about URIs for 
draft-moonesamy-rfc2369bis-04 [1].  Could you refresh my memory about 
what to clarify to help mailinglist-02?

Thanks,
S. Moonesamy

1. http://tools.ietf.org/html/draft-moonesamy-rfc2369bis-04
Permalink | Reply |
headers
John C Klensin | 14 Jul 2012 01:25

Re: Shepherd report review of mailinglist-02


--On Friday, July 13, 2012 12:56 -0700 S Moonesamy
<sm+ietf <at> elandsys.com> wrote:

> Hi John,
> At 09:04 13-07-2012, John C Klensin wrote:
>> Then, partially following John's logic, it would be as
>> reasonable (or more so) to clarify that the particular URIs
>> and references to them appear in 2369.
> 
> If I recall correctly we discussed about URIs for
> draft-moonesamy-rfc2369bis-04 [1].  Could you refresh my
> memory about what to clarify to help mailinglist-02?

As far as mailinglist-02 (or -03) is concerned, I think John L
is on the right track, I agree that we don't need references to
"IETF" or "email", that the issue has gotten down to where
"editor's discretion" sets in, and I'm willing to let him apply
that discretion.

   john
Permalink | Reply |
headers
Arnt Gulbrandsen | 13 Jul 2012 22:00
Picon
Favicon
Gravatar

Re: Shepherd report review of mailinglist-02

On 07/13/2012 05:09 PM, Alexey Melnikov wrote:
> I believe the rule is that anything mentioned in the document that is
> not defined in it needs to be referenced.

Hi Alexey, I noticed that all of your drafts mention the IETF, but you 
neither define it nor reference a definition ;)

Seriously, that rule is generally taken seriously only for terms that 
affect the meaning of the document. "Copyright 2012 trustees of the 
IETF" has no impact on the document's meaning — it could be IBM, the 
document would still say the same thing.

IMO mailto does not need a reference. No matter what mailto actually 
means, the document still says the same thing.

Arnt
Permalink | Reply |
headers
SM | 13 Jul 2012 22:18

Re: Shepherd report review of mailinglist-02

At 13:00 13-07-2012, Arnt Gulbrandsen wrote:
>Hi Alexey, I noticed that all of your drafts mention the IETF, but 
>you neither define it nor reference a definition ;)

+1 :-)

>IMO mailto does not need a reference. No matter what mailto actually 
>means, the document still says the same thing.

I included a reference to "mailto" in a draft as a pointer for an 
implementer to see what's the relevant specification quickly.  I have 
heard of the thing called a search engine.  The short answer is that 
it is more of a matter of style.

Regards,
-sm
Permalink | Reply |
headers
Alexey Melnikov | 13 Jul 2012 13:16
Favicon

Re: Shepherd report review of mailinglist-02

On 10/07/2012 17:13, Joseph Yee wrote:
> Questionable: RFC 3987 and RFC 6068  (used only as part of
> the specification of "the URI-encoded form" in Section 3.1).  I
> urge getting rid of them entirely since it is easy to have the
> discussion that is relevant to this document without them and
> they (especially 3987, which draft-ietf-iri-3987bis (the real
> [I-D.duerst-iri-bis] proposes to obsolete incompatibly.
Sorry, missed this earlier: all URI mentioned in the document need 
Informative references. I don't think just assuming that readers can 
find relevant documents is Ok.
Permalink | Reply |

Gmane