headers
Frank Ellermann | 1 Jul 2005 01:04
Picon
Picon

Re: #1029: USEFOR 3.2.2 References: Should comments be a MUST NOT? (fwd)


Bruce Lilly wrote:

> I guess we have at least the following options:
> 1. no change
> 2. s/SHOULD NOT/MUST NOT/
> 3. s/cause interoperability problems/be misinterpreted by
>    non-conforming parsers/
> 4. elide the entire text

> Although I suggested the third option, on further
> consideration I'd like to switch to the fourth (with the
> third as a fallback)

We have no general rule stating that unnecessary comments
in a field not designed to be displayed are a stupid idea.

IIRC 2822 only says "if you must do this use at least the
end of a syntactical unit" (or similar), that doesn't help
for a <msg-id-list>, the only unit in sight is a <msg-id>.

Without a general rule removing the entire text (your 4)
is not among my preferences.  It's also very different
from Forrest's MUST NOT (your 2).  If that would be only
between you and me we'd end up with your 3rd option.

 From Harald's "hat on" POV it's probably "no change" (1).

                        Bye, Frank
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bruce Lilly | 1 Jul 2005 01:14
Picon

Re: #1047 Path-identity: A proposal (perhaps)


On Thu June 30 2005 17:44, Frank Ellermann wrote:

> Some of Bruce's points are not yet covered, MISMATCH!MISMATCH
> etc., maybe we have to declare these beasts as special cases
> of a path-delimiter, brain-storming:
> 
> 
>  path-list = [FWS] path-identity 
>              *( path-delimiter [FWS] path-identity [FWS] )
>              path-delimiter tail-entry [FWS]
> 
>  path-delimiter = "!" / "!!" / "!MISMATCH!" / "!POSTED!"
> 
> No more path-keyword.  Does that solve Bruce's problem ?  Bye

That still permits foo!!tail-entry, foo!MISMATCH!tail-entry, and
doesn't address (no pun intended) where IP address literals are or
are not allowed.

I made some quick notes this morning:
path-identity "!POSTED" needs to be a group
path-identity "!!" path-identity needs to be a group
"MISMATCH!" path-identity needs to be a group 
based on the text description following the ABNF in the usefor draft.
That text (and the draft ABNF) implies that
  Path: MISMATCH!example.net!tail-entry
is a valid complete field, which might not be what is intended; the
text doesn't say that there needs to be anything to the left of
MISMATCH.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bruce Lilly | 1 Jul 2005 01:37
Picon

Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.


On Thu June 30 2005 18:01, Graham Drabble wrote:

> FWIW I'm quite happy to allow them to do so. Nothing critical is likely 
> to break because something has the time +-12hrs so making people code 
> exceptions for things that were declared obsolete (and MUST NOT 
> generate) four years a go seems silly.

A few points to bear in mind:
o if we paid due attention to backward compatibility, existing software
  will be largely conforming, and we're not making people code exceptions
  because the 822 2- and 3-letter zone abbreviations have long been
  required
o there exist archived messages (e.g. Frank's favorite non-Netnews but
  news-like mailing list interface gmane).  Many are more than four years
  old
o while an Injection-Date field could not have been generated 4 years ago
  (as it was not then, and is not yet, standardized), that doesn't apply
  to Date, Expires, etc.  There remains the possibility of a special
  exemption for Injection-Date.
o FAQs and other old material may be periodically reposted with a new
  Injection-Date field, but with a Date field corresponding to the last
  change.  That applies to things like a response to "can somebody please
  post a copy of..." requests also.
o combined mail/news UAs (the norm; Communicator, Thunderbird, Outlook
  Express, pine, etc.) need to deal with standard 2822 semantics for the
  standard 2- and 3-letter zone abbreviations.
o of course, "GMT" was also declared obsolete four years ago...
(Continue reading)

Permalink | Reply | 3 comments |
headers
Frank Ellermann | 1 Jul 2005 02:10
Picon
Picon

Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.


Bruce Lilly wrote:

> o there exist archived messages

Sure, no reason to consider e.g. the A-News format.

> o combined mail/news UAs (the norm; Communicator,
>   Thunderbird, Outlook Express, pine, etc.) need
>   to deal with standard 2822 semantics for the
>   standard 2- and 3-letter zone abbreviations.

Sorting by date, yes, but in that case "MUST accept"
doesn't necessarily imply "interpret correctly".

> o of course, "GMT" was also declared obsolete four
>   years ago...

Unlike the rest of this zoo, that was declared obsolete
11 (eleven) years ago:

| timezone   = "UT" / "GMT"
|            / ( "+" / "-" ) hh mm [ space "(" zone-name ")" ]
[...]
| This is a restricted subset of the MAIL date format.
[...]
| The timezone name in parentheses, if present, is a comment;
| software MUST ignore it, except that reading agents might
| wish to display it to the reader.  Timezone names other than
| "UT" and "GMT" MUST appear only in the comment.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Lilly | 1 Jul 2005 02:22
Picon

Re: #1029: USEFOR 3.2.2 References: Should comments be a MUST NOT? (fwd)


On Thu June 30 2005 19:04, Frank Ellermann wrote:

> We have no general rule stating that unnecessary comments
> in a field not designed to be displayed are a stupid idea.

To borrow a statement from another list, we also don't have a
general rule against drinking gasoline.  Sometimes the obvious
does NOT need to be stated.

> IIRC 2822 only says "if you must do this use at least the
> end of a syntactical unit" (or similar), that doesn't help
> for a <msg-id-list>, the only unit in sight is a <msg-id>.

2822 says (in accordance with RFC 2234 sect. 3.1):
  msg-id          =       [CFWS] "<" id-left " <at> " id-right ">" [CFWS]
which explicitly says where CFWS may appear.  BTW, there is no msg-id-list,
-list rules usually imply comma separators, and there are none in
References or In-Reply-To.  822/2822 specify that comments are semantically
equivalent to a space character, and a space character is a typical
separator between msg-ids.

> Without a general rule removing the entire text (your 4)
> is not among my preferences.

I find it hard to get worked up about a lack of second-hand
interoperability problems related to comments which are rarely
inserted in a References field.  The only UAs I know of that do that
are the ones that used to put (badly broken) phrase syntax (which is
MUST NOT generate in 2822) in References fields.  Those broken
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frank Ellermann | 1 Jul 2005 02:51
Picon
Picon

Re: #1047 Path-identity: A proposal (perhaps)


Bruce Lilly wrote:

> That still permits foo!!tail-entry, foo!MISMATCH!tail-entry

Yes, and I wasn't consequent with the [FWS], next attempt:

 path-list      = [FWS] path-identity [FWS]
                  *( path-delimiter [FWS] path-identity [FWS] )
                  ( "!" [ "POSTED!" ] ) [FWS] tail-entry [FWS]

 path-delimiter = "!" [[ "MISMATCH" / "POSTED" ] "!" ]

That's a bit convoluted, maybe a simple list of delimiters is
better, see above: 
                  ( "!" / "!POSTED!" ) [FWS] tail-entry [FWS]

 path-delimiter = "!" / "!!" / "!MISMATCH!" / "!POSTED!"

> doesn't address (no pun intended) where IP address literals
> are or are not allowed.

It was based on Charles' revised syntax for a <path-identity>:

| path-identity = ( ALPHA / DIGIT )
|                 *( ALPHA / DIGIT / "-" / "." / "_" ) /
|                 IPv4address / IPv6address    ; see [RFC 3986]

> I made some quick notes this morning:
> path-identity "!POSTED" needs to be a group
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruce Lilly | 1 Jul 2005 03:49
Picon

Re: #1047 Path-identity: A proposal (perhaps)


On Thu June 30 2005 20:51, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> > doesn't address (no pun intended) where IP address literals
> > are or are not allowed.
> 
> It was based on Charles' revised syntax for a <path-identity>:
> 
> | path-identity = ( ALPHA / DIGIT )
> |                 *( ALPHA / DIGIT / "-" / "." / "_" ) /
> |                 IPv4address / IPv6address    ; see [RFC 3986]

That's inconsistent with Harald's "diagnostic stuff".

> > That text (and the draft ABNF) implies that
> >   Path: MISMATCH!example.net!tail-entry
> > is a valid complete field, which might not be what is
> > intended; the text doesn't say that there needs to be
> > anything to the left of MISMATCH.
> 
> Then it was wrong, "!MISMATCH!" is the same idea as "!!", only
> for a mismatch.  In my hardcore nitpicking mode it should be:

I guess it's up to somebody who cares for the newfangled "feature"
to open a ticket proposing a specific text change...

> path-identity "!" path-identity "!MISMATCH!" path-list
> 
> a!b!MISMATHCH!c!...!not-for-mail as in "I got this starting
(Continue reading)

Permalink | Reply | 0 comments |
headers
Forrest J. Cavalier III | 1 Jul 2005 04:07

Re: #1029: USEFOR 3.2.2 References: Should comments be a MUST NOT? (fwd)


Bruce Lilly wrote:
> On Thu June 30 2005 15:15, Frank Ellermann wrote:
> 
>>Bruce Lilly wrote:
>>
>>
>>>the only issue appears to be that some UAs (no other
>>>software has need to parse a References field) are not
>>>compliant with the specifications
>>
>>That's not exactly the point:
>>
>>A few of these "UAs" can be Web interfaces trying to display
>>some sort of "threads" using (among others) the References.
>>
>>Some of these broken UAs can mangle the References in wild and
>>wonderful ways causing more wonderful side effects with other
>>UAs, which can normally handle all syntactically well-formed
>>References.
> 
> 
> Do you mean when creating a f^H(avoiding controversial term) response?
> If so, and the UA/posting agent/(controversial word) agent generates
> invalid syntax, then the injection agent ought to reject that response
> article, avoiding damage.  If not, then how does such mangled content
> get from one UA to another?
> 
> I believe that rejecting invalid articles at the injection agent is
> consistent with WG consensus, though USEPRO section 7.2 doesn't
(Continue reading)

Permalink | Reply | 8 comments |
headers
Frank Ellermann | 1 Jul 2005 04:09
Picon
Picon

Re: #1029: USEFOR 3.2.2 References: Should comments be a MUST NOT? (fwd)


Bruce Lilly wrote:

> To borrow a statement from another list, we also don't have
> a general rule against drinking gasoline.  Sometimes the
> obvious does NOT need to be stated.

In that case it's not so obvious:  We know that some UAs have
difficulties with excessively long References.  We know that
some servers reject excessively long References.  We know that
I might be able to trim References manually, but we're even
less confident about UAs.  We have a simple followup-and-trim
algorithm, but we're far from sure that all UAs get it right
in the presence of comments.  And of course we know this...

> msg-id = [CFWS] "<" id-left " <at> " id-right ">" [CFWS]

...and so the implementation strategy "grab <msg-id> content
and add it to the old <msg-id-list> separated by CFWS, then
trim it" might introduce [CFWS] found in the <msg-id>.  Stupid
or not, shit happens.  In that case it's not really broken, it
is only stupid, potentially causing harm for the next (old) UA
that didn't expect the legal [CFWS] => the first UA SHOULD NOT.

> BTW, there is no msg-id-list,

In some cases where I disagree with Charles' ABNF I use my own:

   references  = "References:" SP msg-id-list CRLF
   msg-id-list = [CFWS] *( msg-id CFWS ) msg-id [CFWS]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ellermann | 1 Jul 2005 04:54
Picon
Picon

Re: #1029: USEFOR 3.2.2 References: Should comments be a MUST NOT? (fwd)


Forrest J. Cavalier III wrote:

> 5. Agents MAY remove comments from References.

BTW, are you sure that we want this in USEFOR ?  The proper
way to generate and trim References is in USEPRO.  And if we
move this issue to USEPRO we could combine Bruce's 4th point
"delete SHOULD NOT" with your 5th point "agents MAY remove".

All we then need is a hint that the separator used to be SP,
now it's CFWS, and that's not the same as 2822 [CFWS].

Here's an idea of 4+5 in USEFOR-05

=== OLD ===
   o  Message identifiers MUST be separated with CFWS.

   o  Comments in CFWS between message identifiers can cause
      interoperability problems, so comments SHOULD NOT be generated,
      but MUST be accepted.

   references      =  "References:" SP [CFWS] msg-id *(CFWS msg-id)
                      [CFWS] CRLF
=== NEW ===
   o  Message identifiers MUST be separated with CFWS, typically a
      space or FWS.

   references      =  "References:" SP msg-id-list CRLF
   msg-id-list     =  [CFWS] *( msg-id CFWS ) msg-id [CFWS] CRLF
(Continue reading)

Permalink | Reply | 3 comments |

Gmane