RE: draft-cohen-http-ext-postal-00.txt

(Im redirecting the CC to http-ext)
(note to roger: please join our discussion on http-ext
  subscribe to ietf-http-ext@w3.org, thanks )


> -----Original Message-----
> From: koen@win.tue.nl [mailto:koen@win.tue.nl]
> Sent: Monday, February 23, 1998 9:31 AM
> 
> Point 1: `New protocols should be firewall-friendly, i.e. allow for
> easy blocking/filtering'
> 
> I agree with point 1.
> 
> Point 2: `In order to be firewall-friendly, a new protocol should not
> use the POST method plus a new MIME type, but a completely new method'
> 
> I disagree with point 2.  The draft argues that using a new method,
> instead of a new MIME type, allows the firewall to be more efficient,
> because it has to inspect a smaller part of the messages through it.
> 
Operationally, one could apply this metric in their construction
of ACLs.  However, I think that content-type should reflect
the type, not the action.  The method better expresses an action.
"printing" is more of an action than a content type, IMHO.

If this was 1 year from now and all http based applications
were firmly in using POST, I would be more willing to 'taint'
content type in that way.  However, while the cat is out
of the bag on POST, so to speak, I dont beleive that we are
beyond the point of no return yet.

> Point 3: `Any new (IETF) protocol should have the property that a
> firewall will block it by default, and that explicit action is needed
> by the firewall administrator to enable its use'.
> 
> [This point is stated most clearly in section 2:
>   `While the designers of a new
>    protocol may feel that their new protocol introduces no new risks,
>    they do not have the right to decide what a PFB will support.'
> ]
> 
> I could not disagree more.  I feel that there are many cases in which
> it would be quite legitimate for the IETF to decide that, for a
> certain protocol, the default mode should be that `the average
> liberally configured firewall' accepts the protocol.
> 
[.. snip ..]
I disagree, however, I can accept that this is an issue
which experts can disagree on.
Folks who find firewalls an unwelcome restriction on communications
will likely feel that the protocol designers can rightfully choose
which new functionality is 'safe' to pass through firewalls without
operator intervention.

Conversely, folks who beleive that firewalls are a necessity
and that the most specific granularity the better will feel
that they should decide on a case by case basis which protocols
to allow and which not to.  Further, that the default action 
is that a new protocol is blocked until the admin can examine
it and consider allowing it. Finally, these decisions to allow
or disallow a new protocol may have less to do with security and
more to do with a business policy.

[.. Im leaving out what you call the nitpicking :) ..]

My general opinion is that IPP (printing) is a sufficiently
different functionality set than what admins expect when they
allow POST across their firewall.  Therefore, it isnt appropriate
to tunnel it in POST.

If a new functionality is so different or enabled such a compelling
set of functionality that it needs its own standard, then it surely
is not so trivial that it is simply a "minor variance on the current
functionality of POST".  Therefore, a new or different method is 
appropriate.

> Koen.
>

Received on Monday, 23 February 1998 18:35:55 UTC