Subject: Re: SDP> Suggestions for discussion at SDP session next week

From: Roger K Debry <[email-masked]>
Date: Thu, 14 May 1998 16:27:40 -0400

snip ...

In my conversations with Paul, he had no requirement for a separate data
channel.
<RKD> I thought this was one of Paul's requirements. Paul ???

snip ...

We should define such a lower layer only if the USB and 1394
people fail to define such a layer.
<RKD> I thought non-network attached printers were what were
<RKD> largely driving this discussion, i.e. $299 parallel port
<RKD> attached printers.  I think all of the debate on TCP/IP
<RKD> is interesting, but I'd really like to see the 1394 solution
<RKD> FIRST!

---

From: Robert Herriot <[email-masked]>
Date: Thu, 14 May 1998 15:04:45 -0700

I just talked with Paul about the requirement for a separate data channel.

I think that Paul and I are in agreement that "separate data channel" does 
not necessarily mean that an operation gets a separate channel for data in 
the midst of an IPP/SDP operation. It has at least some elements of the
following.:

    a)  each operation opens a new socket and gets its own channel, or uses 
        an existing socket after the preceding operation has completed. 
    b) a SendDocument gets a different channel from a CreateJob because 
        CreateJob returns a URI which specifies a different host or port.  
    c) data intensive operations, such as PrintJob and Send Document use a 
        different port from other operations.  
    d) the same port is used for all operations, but the printer is able 
        handle connections fast enough that there will never be time-out
problems.

The important concept is that the mechanism for separate channels is handled 
by a layer below IPP/SDP.

At 01:27 PM 5/14/98 , Roger K Debry wrote:
><RK

---

From: Jay Martin <[email-masked]>
Date: Fri, 15 May 1998 11:18:10 -0400

Bob,

> I just talked with Paul about the requirement for a separate data channel.

Given the size, presence and impact Microsoft has in and on the
marketplace, I know I'm not alone in requesting (demanding? begging?)
that Microsoft speak for themselves on this DL regarding requirements
concerns, etc.  It's not right that others submit Microsoft's
comments on key requirements...let Microsoft speak for themselves.

Comments from others on this position?  Agree?  Disagree?  Don't care??

> the midst of an IPP/SDP operation. It has at least some elements of the following.:
> 

I read your "a)" item several times, but still come away confused.
That is, I don't see the value or implication of the statement.
Am I missing something here?

Some of us still want to see the use of a separate data
channel for clean, low-overhead transmission of large
amounts of relatively opaque data (ie, job data).  This
lesson was learned by the FTP folks many years ago, and
we should learn from that experience.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: James Walker <[email-masked]>
Date: Fri, 15 May 1998 13:36:31 -0500

Jay Martin wrote:
> ...

I agree 1000%.  I think that it is in everybody's best interest
if people's comments come directly from their own mouth, rather
than passing through an even unintentional filter.

...walker

--
Jim Walker <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX

---

From: Robert Herriot <[email-masked]>
Date: Fri, 15 May 1998 18:53:47 -0700

I agree that it would be best if Paul would state his position on the DL and 
come to our meetings. But he doesn't have the time, and instead others have 
cited his needs as the reasons why IPP is broken and we need SDP.  I have 
found that in some cases, he has been misunderstood.

When I have learned more about Paul's views, I have communicated them to the 
DL because I felt that the information I gained might be useful even though 
it had passed through my filter and might not be exactly what Paul meant. 

Although the ideal is that Paul  participate in all of our meetings, the
reality is 
that he does not.  So the important question is how do we deal with that 
reality, and still design a solution that is right for us and for Microsoft.

Bob Herriot