Re: Issues outstanding

["Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>]

In <4255153E.3080500@xxxxxxxxx> Alexey Melnikov <alexey.melnikov-usefor@xxxxxxxxx> writes:

>Ken has just published a new revision of USEFOR (03). Some comments on 
>the changes and how they relate to the list of issues below:

There is still an awful lot of stuff that is meant to be covered in
USEFOR, but still isn't. But that is for another thread.

>Charles Lindsey wrote:

>>>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 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,
>>
>This change is done as well as description of different parameters.

Yes, but not quite as agreed, because the token he has given for the
parameter is 'complaints-to', rather than 'mail-complaints-to' as we
agreed. That will not satisfy the people who wanted to leave room for a
'url-complaints-to' parameter as a future extension.

>>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.
>>
>This minor issue is still open.

As currently written, the <value> of that parameter is an
<address-list>, which by default means "send to them all" (cf. the
Reply-To header).

>My personal opinion is that if there are multiple email addresses they 
>all should be treated as equal and mailing to ANY of them should suffice.

That could be achieved by adding some wording to say so. I am easy either
way, so we need to hear more opinions.

>>2. Path header delimiters
>>  
>>
>This is still open.
>[...]

Shame! I though we had more-or less agreed on that one. OK, I shall start
another thread to discuss that.

>>3. Mail-Copies-To and Posted-And Mailed
>>
>>>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
>>
>This issue is closed now: the headers will not appear in the USEFOR 
>document. The choice between 2a/2b/3 is up to the WG.

Actually, I have now come to the conclusion that this problem is far worse
with mailing lists than it is on Usenet, so it might be better to fix it
there, maybe based on Mail-Followups-To with some extra features to
incorporate News. Indeed, there was some discussion on the ietf-822 list
about Mail-Followups-To as a possible solution, with many in favour but
two diehards implacably opposed (for completely opposite reasons). Ours is
not the only list that suffers from long discussions with no decision at
the end :-( .

(Oddly, I noticed that John Stanley was in favour of Posted-And-Mailed -
he is quite right, but if Mail- Copies-To has to wait, then
Posted-And-Mailed must wait too.)

I shall now remove all mention of both these headers from USEPRO.

>>4.  Terminology for followups.
>>
>>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.
>>
>I don't believe that anything in the USEFOR should be changed, so this 
>issue concerns the USEPRO document at best.

Could you please explain your reasoning here?

ISTM that any header described in USEFOR needs the following information,
as appropriate:

1. A brief statement of what the header is supposed to achieve.
2. Its syntax.
3. Its semantics (i.e. what information is conveyed by its various
syntactic parts).
4. Any restrictions or requirements on when it is to be used (e.g. it is
"mandatory", or it MUST/SHOULD [NOT] be present if such and such other
circumstances pertain).

Following #4, there has always been a statement like the following
associated with this header:

   A followup MUST have a References-header, and an article that is not
   a followup MUST NOT have a References-header.

It is particularly important to say that here, because it is a change from
RFC 2822, where the word used is only SHOULD.

Now the precise wording of that varies according to exactly how the term
"followup" is defined (and that is what this issue is all about). But both
sides to this argument are agreed that that "MUST" needs to be said, and
this is (AFAICS) the only place where it could be said.

Yes, USEPRO describes in detail how to construct this header in the
particular case of responses/replies to earlier articles, but there are
other applications for it also, for example multipart FAQs and
message/partial (and again it is common ground that these are legitimate
applications).

>>5. Review Injection-Info syntax (this might be related to Complaints-To)
>>
>The updated USEFOR draft now includes description of different parameters.
>If people want an alternative syntax, please speak up now!

Well nobody has spoken on this for a long time. I think the important
thing is that Russ declared that he could live with this syntax, and I
think his opinion is important. But I think we also need some deprecatory
remarks to discourage the wilder (and unnecessary) extremes of RFC 2231
(and please can we use that lovely word "gibbous" in them :-) ).

It is nice to see all the other Injection-Info parameters fully described.
I have a few niggles about the precise details, and there are issues
regarding the way they have been introduced syntactically, but that too is
for another thread.

>>6. Remove filename parameter from the Archive header.
>>
>In the latest USEFOR draft the filename parameter was replaced by a 
>generic parameters.

Fine!

>>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.
>>
>I tend to agree.

>>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.

>NO-WS-CTL have been removed. Can people check that the new syntax is Ok?
>I suspect that some minor issues raised by Frank are yet to be addressed.

Yes, there is a placeholder "[[Adjacent dots should not be allowed]]" for
Frank's problem, but we still need some syntax to plug in there.

We also need some wording drawing attention to this extra departure from
RFC 2822, and referring to [NNTP] which necessitated it.

-- 
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: chl@xxxxxxxxxxxxxxxx      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