[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issues outstanding


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:

Charles Lindsey wrote:

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,

This change is done as well as description of different parameters.

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.

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.


2. Path header delimiters


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

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.



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.

I don't believe that anything in the USEFOR should be changed, so this issue concerns the USEPRO document at best.



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.

The updated USEFOR draft now includes description of different parameters.
If people want an alternative syntax, please speak up now!


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.

In the latest USEFOR draft the filename parameter was replaced by a generic parameters.



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.

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.



Alexey