[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issues outstanding
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: 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