Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06

From: Alfred Hönes <[email-masked]>
Date: Thu, 30 Sep 2010 17:49:14 +0200 (MESZ)

At Mon, 27 Sep 2010 15:49:05 -0400, Ronald Bonica wrote:

> I think that you have hit the nail on the head.  Reading through
> Sections 1-5, I thought that we were trying to fix the feature.
> Only in Section 6 did I realize that we really wanted to drive
> a stake through its heart.
>
> Maybe if we changed the title and added some test to the abstract and
> introduction, this would be better.  Otherwise, people may spend time
> and money fixing the TCP Urgent option instead of just avoiding it.

Oh!  Pay attention!
TCP implementers usually are very different folks than application
designers & implementers!

So giving advice to the former group to sanitize their kernel
stacks (as far as necessary, and based on a uniform, consistent
interpretation of the old contradictory specs) is one point,
and entirely different from giving advice to the apps folks
to avoid the feature.

IMHO, we need both -- fixing the kernel (to the benfit of
existing apps), and avoiding usage of the feature in new apps.

Footnote -- as pointed out on-list during the infancy of the draft:
  The Telnet protocol is tolerant regarding the two interpretations
  of the Urgent Pointer because the trailing DM control character of
  the Telnet SYNC sequence (that's the octet to which the UP points)
  is effectively ignored by the receiving peer in parsing the input
  it reads from the socket (cf. RFC 1123, Section 3.2.4).

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 30 Sep 2010 12:17:20 -0400

Alfred,

I am not sure that we want TCP stack implementers to "repair" this feature. That is may make some applications that rely on broken stack behaviors stop working.

If anything, stack implementers should remove this feature from the stack on the sending side.

                                                       Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, September 30, 2010 11:49 AM
> To: Ronald Bonica; [email-masked]
> Cc: [email-masked]
> Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06
> 
>   Alfred HÎnes.