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

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




Frank Ellermann wrote:


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
=== END ===

Your point 5 going to USEPRO, is that okay ? Bye, Frank


USEFOR can CFWS in ABNF without limit, but in USEPRO have this idea.... Comments in CFWS between message identifiers can cause interoperability problems, so comments SHOULD NOT be generated, but MUST be accepted, and MAY be removed.

I know, "MUST accept+MAY remove" is probably unheard of, but that MAY
puts "innovators" on notice that they can't expect comments to propagate, and
helps implement a messy place that XSS scripting could happen in
web UIs.  Should a web UI be forced to accept (and
display?) a hacked up References field in an attempt to XSS?  There
have been too many clever XSS and "response splitting" style attacks to
think that all HTML that gets a green-light in one browser is not
a XSS in another.

Sure, avoiding XSS is a problem for a web agent to handle CFWS in
any header fields, but References is likely to go through an additional
level of processing that gets A HREFs added (to link back to
precursors.)

No, I don't like it that there might be two non-identical copies of
an article propagating, but I suppose you can limit the
MAY remove to non-transport agents.

Yes, this is probably a weird idea, but please find a real reason to
dismiss it, not just that it is weird to write a "MUST accept+MAY
remove."