IFX Mail Archive: IFX> Agenda IPPGET/IPPFAX telecon, Thursda

IFX Mail Archive: IFX> Agenda IPPGET/IPPFAX telecon, Thursda

IFX> Agenda IPPGET/IPPFAX telecon, Thursday, Aug 9, 8-10 AM PDT (11-1 PM EDT)

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Aug 08 2001 - 00:44:11 EDT

  • Next message: Hastings, Tom N: "IFX> UIF ISSUE 02: Break C Profile into 2 profiles: color and grayscal e; L Profile REQUIRE LAB palette (n=6)"

    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

    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

    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

    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

    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.

    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

    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):
      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
    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
    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

    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

    <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

    <MJ> I realize this complicates the spec a bit, but I think it makes ippget
    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

    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
    the Printer will return that Event in an Event Notification in a
    Get-Notifications response. After the Event Life elapses, the Printer will
    longer return an Event Notification for that Event in a Get-Notifications

    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

    <TH> Or we could clarify the "notify-get-interval" attribute that the
    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
    make the connection.

    ISSUE 12: Get rid of URI searching/matching for IPPGET?

    Delete the "notify-recipient-uri" operation attribute from

    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
    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
    Object using the Create-Printer-Subscription operation for a long term lease
    use its subscription id.

    If an IPPFAX Printer is used by several groups, each with their own
    then each group should have its own URL. Depending on implementation, each
    either specifies a different Printer object on the same implementation or a
    single Printer object supports multiple IPPFAX URLs. [See IFX ISSUE 43


    IFX Issues 1-31 were covered or postponed at the Toronto meeting. See the
    minutes at:


    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

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


    This archive was generated by hypermail 2b29 : Wed Aug 08 2001 - 00:45:05 EDT