Subject: Issues outstanding

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 4 Feb 2005 21:38:05 GMT

Some while back I posted a list of issues (and our Chair added some more).
We have now reached the point where we cannot continue working on our
drafts until these are resolved.

So here is the list again, with my comments on where we are at on each
one. SO PLEASE CAN WE HAVE INPUT ON THESE, especially on the ones which
still appear to be OPEN?

>We are coming to the point where there is little more that can be done on
>the documents we are supposed to be producing without deciding how various
>outstanding issues are to be resolved.

1. Complaints-To

>I published a list of 4 options (and invited other options) in
>http://www.imc.org/ietf-usefor/mail-archive/msg00151.html. Only three
>people have expressed any preference amongst them. I think #4 is dead, and
>#2 is the one most people could live with (but on such a small sample,
>that is hardly meaningful).

>#2 was to do it in Injection-Info rather than in a Complaints-To header,
>and to provide only a mail-complaints-to parameter (which would leave open
>the option to provide a separate url-complaints parameter as a future
>extension).

I think the conclusion we reached on this was to have a
'mail-complaints-to' parameter in the Injection-Info header with an
<address-list> for its parameter. And we decided not to have any provision
for URLs at this time, though a url-complaints-to parameter could be added
as a future extension if there was a demand for it.

If that is agreed, then this issue is CLOSED, except for deciding whether
multiple <address>s meant you were supposed to reply to ALL of them, or to
ANY ONE of them. Input on this is still needed.

2. Path header delimiters

>.See http://www.imc.org/ietf-usefor/mail-archive/msg00123.html.
>
>I offered 4 schemes A, B, C and D with different ways of indicating:
>    #1 the injecting site
>    #2 identity of previous site verified
>    #3 identity of previous site not verified
>    #4 identity of previous site not checked
>
>A. (draft-13) Uses '%' for #1, '/' for #2, '?' for #3 amd '!' for #4
>
>B. (Henry)    Uses '@' for #1, ',' for #2, ' ' for #3 amd '!' for #4
>
>C. (Diablo)   !foo.example.POSTED! for #1
>              !bar.example.MISMATCH! for #3
>              !baz.example! for #2 and #4 which are not distinguished
>
>D. (CHL)      !foo.example!POSTED! for #1
>              !baz.example!M! (or !baz.example!!) for #2
>              !bar.example!MISMATCH! for #3
>              !baz.example! for #4
>
>But that's just a summary. Please follow the URL for all the pros and
>cons.

Not that the alternative "!baz.example!!" in D relies on some examples in
RFC 1036 which apparently make it OK to have two <delimiter>s in
succession.

THIS ISSUE IS THE MAIN ITEM HOLDING UP FURTHER PROGRESS, but there was
zilch discussion of it, except for some recent comments by Frank who
seemed to support option D in the "!baz.example!!" form.

Would that solution be acceptable to everyone else. If so, I could soon
propose some texts (both within USEFOR and USEPRO). But, in the
meantime, this one is still OPEN.

3. Mail-Copies-To and Posted-And Mailed

>Available options appear to be:
>
>1.  Include them as in draft-13
>2a. Defer them to a future document (standards-track)
>2b. Defer them to a future document (experimental)
>3.  Drop them entirely

>Earlier discussions were inconclusive. I gather our Chair prefers #2 (a or
>b), but he has made no definitive pronouncement.

I think all that the discussion established was that it was as much effort to
remove them (from USEPRO) as to add them (to USEFOR). It is still not clear
(to me) what the objection to keeping them is, and I see no merit at all in
#2b (since these headers are in moderately common use, and the "experiment"
has, in effect, been done).

So this issue is still OPEN.

4.  Terminology for followups.

>1. A followup is a response, and MUST have a References header. A part of
>   a multi-part FAQ (or anything similar) is not a followup, but it MAY
>   nevertheless have a References header.
>
>2. A followup is a response, or a part of a multi-part FAQ (or anything
>   similar). A followup MUST have a References header, and anything else
>   MUST NOT have one.
>
>It has been established that there is no technical difference between
>these formulations. It is just a matter of wording, so a simple majority
>for one of the other should settle the matter.
>
>There are alternative definitions in USEPRO, but no corresponding wordings
>for the References header in USEFOR yet, so maybe we should wait until
>there are.

This one is still OPEN. There are two alternative texts in USEPRO, but the
matching alternative texts for USEFOR are not in place yet (I hope Ken is
working on them). So I am happy to let this one be for now. There is no
technical issue involved - just a question of how to define things.

5. Review Injection-Info syntax (this might be related to Complaints-To)

I invited proposals from anyone who wanted to pursue this. I received none, so
I think this one is CLOSED.

We all agree that RFC 2231 is ugly, but most of it is quite unnecessary in
Netnews. I would be happy for this to be pointed out in USEFOR with suitably
discouraging wording.

6. Remove filename parameter from the Archive header.

I think we concluded that the filename-parameter (and perhaps other
parameters) might well be useful in the future, but there was no need to
define them now. Therefore, we should just keep provision for MIME-style
parameters in this header (so software would be required to ignore such
parameters for now), but leave the definition of any actual parameters for
future extensions.

7. FWS issue in headers.

Frank was very keen to introduce *FWS rather than *CFWS or *FWS in various
headers to cope with the rule that folding should not result in empty lines,
or even in lines with empty content. It was established, however, that the
present verbiage covering this issue would still be needed because it was not
possible to solve all such cases syntactically. I argued that there was no
point in changing only those cases where it would work, thereby introducing
differences from RFC 2822. Note that this issue involves no technical change -
just the method of description.

Frank received no other support, and I propose to do nothing. If Ken wants to
make these changes to USEFOR, then so be it. I regard this one as CLOSED.

8. Define a Message-ID compatible with NNTP, get rid of NO-WS-CTL.

We agreed to get rid of NO-WS-CTL (it would have been incompatible with
the new NNTP draft), but our Chair rules that further departures from RFC
2822 were not to be allowed. So I think this is CLOSED.

So could people who disagree with the ones I have marked CLOSED please
speak up, and otherwise will our Chair please confirm that they are
CLOSED.

And please may we have discussion of the ones still OPEN, especially the
Path header one.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   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: Frank Ellermann <[email-masked]>
Date: Sun, 06 Feb 2005 13:17:29 +0100

Charles Lindsey wrote:

 [Posted-And-Mailed]
> I gather our Chair prefers #2 (a or b), but he has made no
> definitive pronouncement.

Add me and my ersatz-newsreader.  Obscure news-only headers to
"solve" netiquette-problems make no sense, they should at least
also work for mailing lists.

> It is still not clear (to me) what the objection to keeping
> them is

See above.  Some users want / send courtesy copies, other users
hate it.  A news-only "solution" doesn't help, it increases the
confusion (new vs. old UAs + news vs. mailing lists).

 [Followup]
> It has been established that there is no technical difference
> between these formulations. It is just a matter of wording

ACK.  Let's use your 1st definition and get rid of the "MUST":

| A followup is a response, and has a References header.

No details about the parts of a multi-part FAQs, they are only
confusing.  And IMHO no 2119 keywords for definitions, if A is
defined by B, then it's unnecessary to say that A MUST be B.

You also wouldn't say that "green MUST be a colour", it _is_ a
colour.  Adding "one of 9 or 18 parts of golf" doesn't help ;-)

 [folding]
> Frank was very keen to introduce *FWS rather than *CFWS or
> *FWS in various headers

JFTR, SP *WSP instead of SP [FWS] after the colon, and also
*WSP CRLF instead of [FWS] CRLF.

Actually I'd prefer FWS instead of SP [FWS], but you told me
that some news implementations insist on SP after the colon.

And I don't want to "introduce" a SP *WSP instead of SP [FWS],
or *WSP CRLF instead of [FWS] CRLF, this reflects an explicit
MUST in the text.

> I argued that there was no point in changing only those cases
> where it would work, thereby introducing differences from RFC
> 2822.

Yes, the same issue for [CFWS] before or after the field body
is messy.  But that doesn't "introduce" differences from 2822.

Usefor-02 doesn't allow "name:" SP CRLF WSP "body" CRLF for a
folded "name: body" header field.  A PITA for mail2news gateway
operators.

> Note that this issue involves no technical change - just the
> method of description.

Maybe you find a better way to make the difference from 2822
clear for gateways operators and UA implementors ?  IMO a real
solution could be "name:" FWS "body" CRLF for mail _and_ news
in a future 2822bis, but unfortunately we can't fix this here.

 [msg-id]
> I think this is CLOSED.

I'd like to see it.  If it mentions an <id-left> or <id-right>,
then it's probably not ok.  And there were three problems with
dots in a quoted <unique> (cases not covered by dot-atom-text).

                           Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 14 Feb 2005 16:06:42 GMT

>also work for mailing lists.

Actually, Posted-And-Mailed would work fine with mailing lists.

Mail-Copies-To might not, and if the email people were to agree on some
more general solution, then that would be fine. But last time they tried,
they just went round and round in circles. Most of them would have been
happy to use Mail-Followups-To, but a certain Mr Moore and a certain Mr
Lilly were vehemently opposed (for completely opposite reasons), and so
nothing happened and the dilemma remains (I have to remember, for each
mailing list I am on, whether to use "Reply" or "Reply-To-All", with dire
consequences if I use the wrong one).

Mail-Copies-To is moderately widely implemented in the News world and
Mail-Followups-To is moderately widely implemented in the Mail world, and
neither is suitable, as it stands, for use in the other medium.

>ACK.  Let's use your 1st definition and get rid of the "MUST":

Yes, that is my preference.

But the wording given was just a summary of the two positions, and not a
wording for the draft. Indeed, the definition in Usepro contains no RFC
2119 wording.

>is messy.  But that doesn't "introduce" differences from 2822.

A difference in syntax (or a difference in syntactic style) is still a
difference, even if the eventual outcome is the same.

>in a future 2822bis, but unfortunately we can't fix this here.

We discussed this a while back, and the conclusion was that we had to
forbid it becaue there were too many broken sites that would remove
trailing whitespace, and we needed that obligatory SP after the ':' to
survive all transports.

>...  And there were three problems with

Yes, I had forgotten about that. It is now back on my list.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 Feb 2005 23:17:49 +0100

Charles Lindsey wrote:
 
> Posted-And-Mailed would work fine with mailing lists.

If it works for mailing lists and news (with some UAs), a
separate draft should introduce it officially for both mail
and news.  I don't see the point in a news-only solution.

"Mailed-And-Posted: yes" is like "Killfile-Me: yes" for me,
if the sender does not explicitly mention this in the body.
If he mentions it explicitly, what's the point of the header ?

> I have to remember, for each mailing list I am on, whether
> to use "Reply" or "Reply-To-All", with dire consequences if
> I use the wrong one

Of course I've seen your discussions with Keith, and therefore
I'd send a courtesy copy to him, but he's the one exception in
this universe as far as I'm concerned.   Bruce never asked me
why I don't send any courtesy copies, I never asked him why he
does, so we can apparently manage this "netiquette difference"
without an additional header.  <shrug />

 [FWS-issue, but also relevant for id-left "@" id-right]
> A difference in syntax (or a difference in syntactic style)
> is still a difference, even if the eventual outcome is the
> same.

That's true.  But you want the same syntatic style as in 2822
with a different outcome.  That's cheating.  If it really is
different from 2822, then using an apparently identical syntax
is confusing for readers.
  
Unless it's intentional, as planned for the term "msg-id" (and
the production is obviously different from 2822, no artificial
similarity, only the same name "msg-id")

It's not the same as id-left "@" id-right, where I really want
unique "@" mdomain, because that's what it is, and it is also
very different from the 2822 syntax for id-left "@" id-right.

msg-id = "<" id-left "@" id-right ">" would be cheating again,
it's apparently the same line as in 2822, but many details are
"different".  Or rather "better" (towards "correct"), the 2822
concept with its NO-WS-CTL etc. wasn't good enough.  Bye, Frank