The IFX WG reviewed the UIF spec and most of the issues in the IFX spec at
the face-to-face meeting, Wednesday, August 1 in Toronto. However, they
agreed to hold a telecon to finish the IFX and do the IPPGET issues. Here
are the telecon details:
Thursday, August 9, 8-10 AM PDT (11-1 PM EDT)
Phone: 1(712) 884-1555, (Xerox folks: 8*596-5170), passcode: 654970
Since there may be folks interested in IPPGET and not IFX, lets start with
IPPGET. Also there are some new issues tacked onto the end of the IFX
issues that arose this week in talking with Marty and Ira about the good
agreements reached in Toronto, in case we have time to cover them.
A. IPPGET Delivery Method (<draft-ietf-ipp-notify-get-04.txt>), posted 7/23:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717-rev.pdf .doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.pdf .doc
B. IFX (IPP FAX Protocol) spec version D0.6, posted 7/27:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf .doc
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf .doc
Michael Sweet (MS), Marty Joel (MJ), Mike Bartman (MB), Carl Kugler <CK>,
and Tom Hastings (TH) have indicated their answers to one or more issues
which I have copied here. I've attempted to filter out the back and forth
and include conclusions only.
A. IPPGET Delivery Method ISSUE (Issues 1-7 were posted to the list on 7/27
for the Toronto meeting, but time did not permit them to be discussed). The
remaining issues 8-12 have been brought up on the IPP mailing list after
7/27.
ISSUE 01 (see section 12): Should we use application/multiplexed
(draft-herriot-application-multiplexed-03.txt) which can chunk mime types
using content lengths, instead of multi-part/related, which uses boundary
strings?
MS> How close is the multiplexed draft to being published as an RFC that
we can actually reference?
MS> I'd suspect that more client software will be able to handle the
multi-part/related MIME type encoding than the new multiplexed
encoding, however, so my vote is to stick with multi-part/related.
<MJ> After reading the draft spec, I see no benefit of using multiplexed
for IPP.
ISSUE 02: For Event Wait Mode, OK to make each successive response after
the first a complete IPP response, instead of just the Event Notification
Attributes Groups?
Then each response looks like a complete response with its own status code.
Also complete responses might be necessary on some other transport. Also we
can move the "notify-interval" attribute back to the Operation Attributes
Group where it belongs, since it applies to all events being returned in
that response.
MS> OK
<MJ> OK
ISSUE 03: OK to clarify that the Per-Job Subscription Object and the
associated Job object MUST persist after the job completes (job completed,
canceled, or aborted) in the Job Retention or Job History phases (see
[RFC2911] section 4.3.7.2)?
Otherwise, a Notification Recipient that is polling would not get the Event
Notification, if it polled after the job completed, but before the Event
Lease Time expired.
MS> Yes, this should be the expected behavior, with the subscription
and job disappearing only after all events have expired.
<MJ> Good argument -- you have my OK.
ISSUE 04: OK to clarify that a client or a Printer MAY disconnect the
underlying transport connect for any operation, including the Event No Wait
Get-Notifications operation and the Event Wait Get-Notifications operation
when the Printer isn't willing to honor the initial request or reneges in a
later response?
So a client could keep the connection open for multiple Event No Wait
Get-Notifications. Before a Printer disconnects it needs to wait enough
time to make sure that any IPP response has had time to get back to the
client before disconnecting, otherwise the client might not see the
response.
MS> OK
<MB> Don't confuse TCP/IP keep alive with HTTP/1.1 Persistent Connections.
Either the client or the Printer can close the HTTP/1.1 connection by
including the "Connection: close" header line in the request or the
response, respectively. From RFC 2068:
===========
HTTP/1.1 defines the "close" connection option
for the sender to signal that the connection will be closed after
completion of the response. For example,
Connection: close
in either the request or the response header fields indicates that
the connection should not be considered `persistent' (section 8.1)
after the current request/response is complete.
HTTP/1.1 applications that do not support persistent connections MUST
include the "close" connection option in every message.
===========
Also:
===========
8.1.2 Overall Operation
A significant difference between HTTP/1.1 and earlier versions of
HTTP is that persistent connections are the default behavior of any
HTTP connection. That is, unless otherwise indicated, the client may
assume that the server will maintain a persistent connection.
===========
So we should only talk about connections in the Encoding and Transport
section.
ISSUE 05: OK to add 'successful-ok-events-complete' status code for a
Get-Notifications response whether Event No Wait or Event Wait mode?
MS> OK
<MJ> OK
Here is more detail:
The Printer MUST return the 'successful-ok-events-complete' status code to
indicate when this return is the last return for all Subscription objects
that match the request, whether or not there are Event Notifications being
returned. This condition occurs for Event Wait Mode Notification Recipients
waiting for responses when the Subscription Object is: (1) canceled with a
Cancel-Subscription operation, (2) deleted when the Per-Printer Subscription
lease time expires, or (3) when the 'job-completed' event occurs for a
Per-Job Subscription. This condition also occurs for a Get-Notifications
request that a Notification Recipient makes after the job completes, but
before the Event Lease Time expires.
Here is a complete table of combinations of "notify-wait", "status-code",
"notify-interval", and Event Notification Attributes Groups for
Get-Notification initial (Wait and No Wait) Responses and subsequent Event
Wait Mode Responses (which may be staying in Wait Mode or may be requesting
the Notification Recipient to leave Wait Mode):
Event
client sends: Printer returns: Notification
"notify-wait" "status-code" "notify-get-interval" Attribute Groups
------------- ------------- --------------------- ----------------
1.'false'/omitted 'successful-ok' MUST return N maybe
2.'false'/omitted 'not-found' MUST NOT MUST NOT
3.'false'/omitted 'busy' MUST return N MUST NOT
4.'false'/omitted 'events-complete' MUST NOT 'job-completed'
5. 'true' 'not-found' MUST NOT MUST NOT
6. 'true' 'busy' MUST return N MUST NOT
7. 'true' 'successful-ok' MUST NOT MUST
8. 'true' 'successful-ok' MUST return N maybe
9. 'true' 'events-complete' MUST NOT 'job-completed'
or maybe other
Explanation:
1-4: client requests Event No Wait
5-9: client request Event No Wait
2,5: Subscription object not found, or was canceled earlier; client should
NOT try again.
3,6: server busy, tells client to try later; client should try again in N
seconds.
4: client polled after job completed, but before Event Lease Time expired,
and got the 'job-completed' event, so the client shouldn't bother trying
again; client should NOT try again later.
7: Printer returns one or more Event Notifications and is ok to stay in
Event Wait Mode; the client waits for more.
8: Printer wants to leave Event Wait mode. Can happen on the first
response (with events) or happen on a subsequent response with or without
Event Notifications; the client should try again in N seconds.
9. Printer either (1) returns 'job-completed' event or (2) the Subscription
Object was canceled by either a Cancel-Job or a Per-Printer Subscription
expired without being renewed. For case (1), at least one event MUST be
returned, while for case (2), it is unlikely that any Events are returned;
the client should NOT try again.
ISSUE 06: Section 12 says: "The Printer MAY chunk the responses, but this
has no significance to the IPP semantics." Is this sufficient, or is
HTTP/1.1 chunking REQUIRED in order to support the multi-part/related MIME
type?
MS> I don't think we have to make this a requirement, because a HTTP
response with no content type has essentially the same semantics
for a wait-mode Get-Notifications request. The only time this
becomes an issue is if the client wants to keep the HTTP connection
alive after the final successful-ok-events-complete message part.
MS> Just make chunking RECOMMENDED, and maybe spell out the reasons why.
<MJ> Chinking isn't required for multipart, and I wonder if they are even
compatible.
<MB> Not quite. Chunking is intended for cases where the total length of a
message can not be determined at the time the HTTP header is transmitted.
When a web page is being generated "on the fly" for example. You can
specify chunking, send the header, then send each part of the response as it
is generated, then signal "that's all!" when you know you've sent it all.
Chunking may also be removed by the transmission linkage if it wants
to...for example a proxy server could convert a chunked message into a
non-chunked message, so using chunking for anything other than occasional
convenience is a bad idea.
Again from RFC 2068:
===========
3.6 Transfer Codings
Transfer coding values are used to indicate an encoding
transformation that has been, can be, or may need to be applied to an
entity-body in order to ensure "safe transport" through the network.
This differs from a content coding in that the transfer coding is a
property of the message, not of the original entity.
transfer-coding = "chunked" | transfer-extension
transfer-extension = token
===========
Despite the fact that chunking is a required part of HTTP 1.1, and IPP 1.0
uses HTTP 1.1, I've run into servers that don't do chunking...which is a
real PITA for me doing printing, since *all* of my stuff is generated "on
the fly" by the formatting parts of the client. The only way I can know up
front how long a Print-Job message will be is to spool the job, then read it
back once I have it all. This slows printing considerably when the link is
fast and the server has a large buffer, since the spooling adds a lot of
disk activity to the process. It's easy to say, "if it isn't compliant,
just don't print to it", but in practical, angry customer, terms, we need to
print anyway if there's any way at all to do so, so I have to treat chunking
as optional, despite the hassle and performance problems.
Just FYI, here's the RFC 2068 stuff on chunking requirements:
===========
All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer coding, and MUST ignore transfer coding extensions
they do not understand. A server which receives an entity-body with a
transfer-coding it does not understand SHOULD return 501
(Unimplemented), and close the connection. A server MUST NOT send
transfer-codings to an HTTP/1.0 client.
===========
> Can multipart and chunking coexist?
I don't see any reason why they couldn't. Chunking is a transmission level
issue, multipart is above that. Chunking is how you get a block of bytes
from point A to point B, while multipart is a question of what that block of
bytes looks like.
ISSUE 07: It has been suggested on the mailing list that the Notification
Recipient could supply pairs of the "notify-sequence-number" and
"subscription-id" and the Printer would only return events with a higher
sequence number on a Get-Notifications request. Thus the Printer would
eliminate duplicate events.
a. Change "notify-subscription-id" (integer(1:MAX)) operation attribute to:
"notify-subscription-ids" (1setOf integer(1:MAX))
ISSUE 07a: We have "notify-subscription-id" (integer(1:MAX)) as an operation
attribute of Renew-Subscription and Cancel-Subscription operations. Should
we make this new 1setOf attribute differ by more than just the letter "s",
say, "notify-subscription-ids-requested"?
b. Add "notify-sequence-numbers" (1setOf integer(1:MAX)) operation
attribute as a parallel attribute. If supplied, the Printer
only returns Events with that sequence number or higher sequence number for
the ith Subscription object identified by the ith subscription id in
"notify-subscription-ids", thereby, eliminating duplicates events on a
Subscription Object basis. If "notify-subscription-id" has fewer (or no)
values than "notify-subscription-ids", the Printer assumes a value of 1 (all
unexpired events are returned). If "notify-subscription-id" has more values
than "notify-subscription-ids", the extra values are ignored.
Note: this is a case of "parallel" attributes which we said we didn't want
to do again. However, these attributes are NOT on an object so there is not
problem with setting parallel attributes and these attributes can never get
into a directory (where the order might get changed). Most cases will be
just one value for each attribute as well.
MS> I think we have to do this - otherwise we put a greater burden
on the server (which has to format and send the extra events),
the network link (which has to carry more data), and the client
(which has to process extra events and throw old ones away.)
MS> By putting this functionality in the server, we eliminate a lot
of overhead at the expense of slightly greater complexity
(basically an integer comparison for each event sent by the
server...)
<MJ> I realize this complicates the spec a bit, but I think it makes ippget
more
versatile, and addresses Michael's excellent point of improving performance
and bandwidth.
<MJ> Better to eliminate uri searching, since Get-Subscriptions can be used
for that. [See ISSUE 12 below about getting rid of uri searching]
ISSUE 08: was really a duplicate of ISSUE 07, so ignore it.
ISSUE 09: Make Event Wait Mode OPTIONAL for a Sender and a Receiver?
Currently the spec REQUIRES the Receiver to support both values of the
"notify-wait" operation attribute ('true' and 'false').
With the Notification Recipient being able to request the Receiver to filter
out duplicates, is it ok to allow the Receiver to always force the
Notification Recipient back to Event No Wait Mode with the
"notify-get-interval" operation attribute of when to poll next?
Or should Event Wait Mode be RECOMMENDED for the Receiver?
What about RECOMMENDED for the Sender?
MS> I think event-wait-mode should be OPTIONAL but RECOMMENDED. There
will always be client and server implementations that can't do the
multipart encoding, or can't spare the extra socket resources.
MS> Since we already have defined the fallback behavior for both client
and server, this should not pose a problem.
<CK> For no-wait-mode you don't need multipart. But multi-part is critical
for wait-mode if we are going to send complete application/ipp responses for
each part, since the version, status, and request-id are positional fields.
MS> It might be useful to provide a new "notify-wait-supported"
attribute that the client can query with the Get-Printer-Attributes
request to see ahead of time if the server can support wait mode,
although with the caveat that the server may choose not to honor
individual requests in the interests of resource management.
<MJ> I like the idea of making Event Wait Mode RECOMMENDED for both the
Sender and Receiver. I don't know if notify-wait-supported is needed,
since I don't see how that would change the Sender's behavior. Does
the Sender care if it sends a request for wait mode and receives a
try-again time, versus sending a non-wait mode and receives a
try-again time?
<TH> How about REQUIRING a Receiver to support Event Wait Mode for at least
one connection? Then the normal IPPFAX case of one Sender and one Receiver
works nicely with Event Wait Mode.
ISSUE 10: OK to change IPPGET "ippget-event-time-to-live" to
"ippget-event-lease-duration"?
MS> maybe we can simplify the name/terminology: ippget-event-life?
We *are* talking about the lifetime of an event, not a lease
time for a subscription (the lease terminology makes sense for
subscriptions because you ask for a subscription for a specific
time period, but events are generated by the printer and aren't
"leased" by the client, right?
TH> How about going with Michael's suggestion for the name:
"ippget-event-life" and defining the term Event Life in IPPGET:
Event Life: The length of time in seconds after an Event occurs during
which
the Printer will return that Event in an Event Notification in a
Get-Notifications response. After the Event Life elapses, the Printer will
no
longer return an Event Notification for that Event in a Get-Notifications
response.
which replaces the IPPGET terms:
Event Notification Lease: The lease that is associated with an Event
Notification. When the lease expires, the Printer discards the associated
Event Notification.
Event Notification Lease Time: The expiration time assigned to a
lease that is associated with an Event Notification.
ISSUE 11: Should the Printer return a "end-wait" (boolean) attribute,
rather than a "notify-get-interval" (integer) with the number of seconds to
try again later?
<MJ> Regarding the whole try-again time issue, I don't think the Receiver
should be sending that, and should indicate the desire to stop or not
start wait mode with a boolean or a status code. The Sender can do a
Get-Printer-Attributes to learn how long events are retained. The
Sender knows by when it must issue another Get-Notifications to avoid
the risk of losing events. If it isn't in keep-alive mode, the Sender
must take into account how long it might take to connect, so the
returning of the number of seconds to wait before trying again is
misleading.
<TH> Or we could clarify the "notify-get-interval" attribute that the
Printer
is returning to be the value of the Printer's "ippget-event-time-to-live"
operation attribute and the client needs to take into the account the time
to
make the connection.
ISSUE 12: Get rid of URI searching/matching for IPPGET?
Delete the "notify-recipient-uri" operation attribute from
Get-Notifications.
The Notification Recipient client MUST supply the "notify-subscription-ids"
operation attribute and MAY supply the "notify-sequence-numbers". The
subscription id MUST specify a Subscription Object that matches the scheme
(case insensitive) IPPGET.
<TH> When the Sender is also the Notification Recipient, the Sender will
know
the subscription id as a response to the Job Creation operation, then the
subscription id is much more specific. When some other client is the
Notification Recipient, it probably will have operator privileges anyway;
otherwise it cannot get events from any Sender's Subscription Object. But
if it
has operator privileges, it can more simply create a Per-Printer
Subscription
Object using the Create-Printer-Subscription operation for a long term lease
and
use its subscription id.
If an IPPFAX Printer is used by several groups, each with their own
secretary,
then each group should have its own URL. Depending on implementation, each
URL
either specifies a different Printer object on the same implementation or a
single Printer object supports multiple IPPFAX URLs. [See IFX ISSUE 43
below].
B. IFX ISSUES
=============
IFX Issues 1-31 were covered or postponed at the Toronto meeting. See the
minutes at:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.doc
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.pdf
Remaining ISSUES in the IFX document are issue 32-41. Issue 42-47 have been
added since the meeting this week in talking with Marty and Ira about the
good agreements reached in Toronto, in case we have time to cover them:
ISSUE 32: Do the conformance requirements look ok?
Need to register the new attributes and the new status code. Text TBD.
ISSUE 33: Need version 3.0 of vCard, since it is an RFC, while version 2.1
is not.
ISSUE 34: Is this example accurate? The phone number format seem wrong.
ISSUE 35 (repeat): What vCard restrictions? No pictures, no logos, no
sound?
ISSUE 36: What other Receiver attributes should go in the Generic Directory
Schema for an IPPFAX Receiver?
ISSUE 37: OK that it is of abstract type printer?
ISSUE 38: Should the concrete type be 'IPP' (since the 'ipp' scheme is
being used), or 'IPPFAX' to differentiate it from an IPP Printer?
ISSUE 39: Is the conformance right?
ISSUE 40: Should we add authors to PWG standards like we do IETF RFCs?
ISSUE 41: Should we add participants to PWG standards like we do IETF RFCs?
The following NEW issues were discovered by Marty Joel, Ira, and myself when
going over the ISSUE resolutions from the meeting.
ISSUE 42: What attributes, attribute values, and operations does a client
see with Get-Printer-Attributes depending on the URL being used (independent
of whether or not we have a new URL scheme - see ISSUE 03)?
ISSUE 42a: According to IPP/1.1, the three parallel "printer-uri-supported",
"uri-security-supported", and "uri-authentication-supported" (the three
musketeers) always returns all values for all schemes, so these three
attributes aren't colored in any way, right?
ISSUE 42b: If a single Printer object supports IPP and IPPFAX with separate
URLs, and a client queries on the IPP URL, does it get back the "ippfax-xxx"
attributes or not?
ISSUE 42c: If we have a separate URI scheme (ISSUE 03), then there is no
need for the newly renamed "semantics-supported" (was
"ippfax-semantics-supported") Printer attribute at all. Instead, the
"printer-uri-supported" serves the same purpose. However, if we don't have
a new IPPFAX URL scheme, will the "semantics-supported" Printer attribute
act like the three musketeers and return all semantics supported no matter
on which URL the client queries?
ISSUE 43: Do we still agree that there are two ways for a single
implementation to support both IPP and IPPFAX:
Method a: A single Printer object supports both semantics with separate
URLs. Depending on which URL the client uses, the IPP versus IPPFAX
semantics are performed. The Printer object's "semantics-supported" and
"printer-uri-supported" list values for both when both are supported. The
system administrator configures the single Printer object's
"semantics-supported" and "printer-uri-supported" attribute for one, the
other, or both.
ISSUE 43a: Do we agree that a single Printer object (Method a) cannot use
the same URL for both IPP and IPPFAX? (Part of ISSUE 11 resolution)
Method b: Two separate Printer objects, also with separate URLs. Depending
on which URL the client uses, the IPP versus IPPFAX semantics are performed.
The System Administrator configures each Printer object independently of the
other. Each Printer object's "semantics-supported" and
"printer-uri-supported" attribute only contain values for one or the other
but not both.
ISSUE 43b: Should we RECOMMEND that if a single implementation has separate
Printer objects (Method b), one for IPP and the other IPPFAX, that the URL
differ only in the scheme? Then a client could try the same URL with the
other scheme?
ISSUE 44: If we do have a new 'ippfax' URL scheme, then the scheme
indicates whether IPP or IPPFAX semantics are wanted, right? Then
"ippfax-version" operation attribute (decision on issue 11 to replace the
"ippfax-semantics" operation attribute), only becomes a version indication,
and NOT a request to use IPPFAX semantics, right?
ISSUE 45: If we have a new IPPFAX URL scheme, then we can have parameters
on it if we spec them now (unlike the IPP scheme). OK? What parameters
should we specify:
ISSUE 45a: How about auth= and sec= corresponding to the
"uri-security-supported", and "uri-authentication-supported" attributes.
These are ones we had wished we has specified for the IPP scheme, but
couldn't because of deployment of IPP. Then a URL completely specifies how
to connect to the Printer object.
ISSUE 45b: We should also figure out how off-ramp parameters can be added as
parameters as well.
ISSUE 46: What TLS options are REQUIRED for IPPFAX? This issue is an
outgrowth of ISSUE 03 (new scheme), but is really separate. IPP only
RECOMMENDS TLS and some of its options. Here are the IPP Security
conformance requirements from RFC2910 [numbers added]:
8.1.1 Digest Authentication
IPP clients MUST support:
1. Digest Authentication [RFC2617].
2. MD5 and MD5-sess MUST be implemented and supported.
3. The Message Integrity feature NEED NOT be used.
IPP Printers SHOULD support:
4. Digest Authentication [RFC2617].
5. MD5 and MD5-sess MUST be implemented and supported.
6. The Message Integrity feature NEED NOT be used.
8.1.2 Transport Layer Security (TLS)
7. IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for
Server Authentication and Operation Privacy.
8. IPP Printers MAY also support TLS for Client Authentication.
9. If an IPP Printer supports TLS, it MUST support the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246
[RFC2246].
10. All other cipher suites are OPTIONAL.
11. An IPP Printer MAY support Basic Authentication (described in HTTP/1.1
[RFC2617]) for Client Authentication if the channel is secure.
12. TLS with the above mandated cipher suite can provide such a secure
channel.
13. If a IPP client supports TLS, it MUST support the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246
[RFC2246].
14. All other cipher suites are OPTIONAL.
8.2 Using IPP with TLS
15. IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism [RFC2817].
16. An initial IPP request never uses TLS.
17. The client requests a secure TLS connection by using the HTTP "Upgrade"
header, while the server agrees in the HTTP response.
18. The switch to TLS occurs either because the server grants the client's
request to upgrade to TLS, or a server asks to switch to TLS in its
response. 19. Secure communication begins with a server's response to
switch to TLS.
ISSUE 47: We have agreed to remove the Off-Ramp attributes, but keep only
"final-destination-uri" which might be a urn of the recipient (see
resolution to ISSUE 29). However, should we have an attribute that is
similar which is to notify the recipient (person) of the arrival of the
document? The URI could be 'mailto', 'tel'. For the former, the IPPFAX
Receiver sends an unsolicited email message saying that a document has been
printed. The latter makes a phone call to announce that the document has
been printed. This attribute does not require the recipient to have done
anything ahead of time and does not require the recipient to be registered
in any system. It is what a secretary typically does today when a FAX is
received at a group FAX.
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Friday, August 03, 2001 15:13
To: IPP FAX DL (E-mail)
Subject: IFX> IPPFAX telecon, Thursday, Aug 9, 8-10 AM PDT (11-1 PM EDT)
The IFX WG reviewed the UIF spec and most of the issues in the IFX spec at
the face-to-face meeting, Wednesday, August 1 in Toronto. However, they
agreed to hold a telecon to finish the IFX and IPPGET issues. Here are the
telecon details:
Thursday, August 9, 8-10 AM PDT (11-1 PM EDT)
Phone: 1(712) 884-1555, (Xerox folks: 8*596-5170), passcode: 654970
We'll send out the issues list early next week with the remaining issues for
IFX and the updated issues list for IPPGET:
2. IFX (IPP FAX Protocol) spec version D0.6, I posted, 7/27:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf .doc
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf .doc
3. IPPGET Delivery Method (<draft-ietf-ipp-notify-get-04.txt>), I posted,
7/23, at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717-rev.pdf .doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.pdf .doc
Tom
This archive was generated by hypermail 2b29 : Wed Aug 08 2001 - 00:47:55 EDT