IPP Mail Archive: IPP> NOT - Minutes of IPPGET telecon, Thur

IPP> NOT - Minutes of IPPGET telecon, Thursday, Aug 9, 8-10 AM PDT (11 -1 PM EDT)

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Thu Aug 09 2001 - 19:01:17 EDT

  • Next message: Bergman, Ron: "IPP> Media Standardized Names Specification, revision D0.11 is now ava ilable"

    Attendees: Marty Joel (Netreon), Ira McDonald (High North), Pete Zehler
    (Xerox), Ron Bergman (Hitachi-Koki), Carl Kugler (IBM), Tom Hastings
    (Xerox)

    Summary:

    1. We discussed all IPPGET issues and resolved all of them (see below),
    except one:

    2. ISSUE 11: (Get-Notifications return a time or just a boolean for the next
    poll). We are still debating whether it is possible for the Printer to
    return a time to next poll that is every larger than the Event Life time?
    If the Printer ever returns a larger value, the client could miss an event,
    unless the Printer magically increases its Life for that (those)
    Subscription object(s).

    3. We also agreed to add Event Wait Mode to Job Creation operations as a
    REQUIRED feature of supporting IPPGET (but allowing a Printer to always
    renege - see ISSUE 09 which REQUIRES that the Printer support Event Wait
    Mode, but only RECOMMENDS that the Printer accept Event Wait Mode requests
    (to help reduce network traffic from polling). This addition is one of the
    features that IBM had included in their original server directed polling
    proposal. See ISSUE 02 resolution discussion.

    4. We also agreed to limit the range of the "ippget-event-life" Printer
    Description attribute to be 15 seconds or more in the syntax (integer
    (15:MAX)) and the RECOMMENDED value of at least 60 seconds which agrees with
    the PWG Job Monitoring MIB (RFC 2707). See ISSUE 03 resolution discussion.

    5. We did not get to any IFX issues.

    6. We will hold another telecon to address the IFX issues, next Tuesday
    (same time, same numbers):

    Tuesday, August 14, 8-10 AM PDT (11-1 PM EDT)
    Phone: 1(712) 884-1555, (Xerox folks: 8*596-5170), passcode: 654970

    The agreements reached are preceded by AGREED>.

    Please respond if there are any disagreements with the agreements.

    Tom

    Agreements

    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

    Michael Sweet (MS), Marty Joel (MJ), Mike Bartman (MB), Carl Kugler <CK>,
    and Tom Hastings (TH) have indicated their answers (before the telecon)
    to one or more issues which I have copied. I've attempted to filter out
    the back and forth and include conclusions only.

    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.

    AGREED> We will use multi-part/related, not application/multiplexed.
    Multi-part/related is not a problem for the Printer. Its the client that
    has to search for the boundary string and that code is already deployed.
    Application/multiplexed was designed more for mixing streams of binary data
    into a main stream, such as XML.

    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

    AGREED> Yes. Then each response is a full IPP response which is more
    suitable for any transport. Also each response can be generated by any IPP
    responder and parsed by an IPP parser.

    AGREED> We also agreed to add Event Wait Mode with multiple responses to
    Job Creation operations as a REQUIRED feature of supporting IPPGET (but
    allowing a Printer to always renege - see ISSUE 09 which REQUIRES that the
    Printer support Event Wait Mode, but only RECOMMENDS that the Printer accept
    Event Wait Mode requests (to help reduce network traffic from polling).
    This addition is one of the features that IBM had included in their original
    server directed polling proposal.

    So the Job Submission Client can supply a "notify-wait" (boolean) with a
    'true' value in any Job Creation Operation (Print-Job, Print-URI,
    Create-Job) which will have the same semantics as for the Get-Notifications
    operation. If the Printer wants to renege, the Printer MUST still accept
    the request and return the "notify-get-interval" with the value by which the
    client needs to be reconnected in order not to miss any events.

    We didn't discuss the Document Creation operations (Send-Document and
    Send-URI) as to whether the client could also supply "notify-wait" (boolean)
    with either value and whether the Printer can return the
    "notify-get-interval" to renege.

    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.

    AGREED> Yes.

    AGREED> We also agreed to limit the range of the "ippget-event-life" Printer
    Description attribute to be 15 seconds or more in the syntax (integer
    (15:MAX)) and the RECOMMENDED value of at least 60 seconds which agrees with
    the PWG Job Monitoring MIB (RFC 2707) jmGeneralJobPersistence and
    jmGeneralAttributePersistence objects.

    AGREED> We also agreed that the "ippget-event-life" value is the value by
    which the client must be reconnected in order not to miss any events. So
    the client has to initiate the Get-Notifications enough sooner, so that the
    request has been accepted by the Printer in order to be guaranteed not to
    miss events.

    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.

    AGREED> We agreed to add something about HTTP persistent connections to the
    IPPGET Encoding and Transport section, but that it applies to all
    operations, not just to Get-Notifications, though the discussion is
    particularly germane to the Get-Notifications operation.

    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.

    AGREED> We agreed to add 'successful-ok-events-complete' and to include the
    table of combinations for clarification.

    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.

    AGREED> We agreed to add something to the Encoding and Transport section
    about chunking and multi-part/related. Also add a note to allay implementer
    fears that HTTP proxies might collect chunked responses over time and only
    send them back together as a single unchunked response (with a Content
    Length instead) much delayed as HTTP/1.1 allows. However, in practice, no
    proxy wants to have an infinite buffer. Also no proxy wants to hold up
    responses, since users would be furious. So not to worry.

    ACTION ITEM (Carl): Propose some text to the mailing list.

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

    AGREED> NO. Its OK to have this operation attribute differ by just a
    single letter "s" when it is the 1setOf form of the singular. So we will
    have "notify-subscription-ids" (1setOf integer(1:MAX)) in Get-Notifications
    and "notify-subscription-id" (integer(1:MAX)) in Cancel-Subscription and
    Renew-Subscription operations. OK to just add "s" for
    notify-sequence-numbers (1setOf integer(1:MAX)).

    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-sequence-numbers" has fewer (or no)
    values than "notify-subscription-ids", the Printer assumes a value of 1 (all
    unexpired events are returned). If "notify-sequence-numbers" 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]

    AGREED> We agreed to REQUIRE the Printer to support both
    "notify-subscription-ids" and "notify-sequence-numbers" operation attributes
    with multiple values. The client MUST supply at least one value for the
    "notify-subscription-ids" attribute.

    AGREED> We also agreed that any number of different clients can do a
    Get-Notifications for a Subscription object subject only to access control.
    Therefore, the Printer MUST NOT discard Events until the Event Life Time
    expires, no matter how many times it returns the corresponding Event
    Notification in Get-Notification responses. Also the same client can issue
    multiple Get-Notifications for the same Subscription Object and get back the
    same events, as long as they haven't expired. So there is no concept of a
    single listener for a Subscription Object.

    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.

    AGREED> After much discussion, we agreed that the Printer MUST accept
    requests for Event Wait Mode (in Get-Notifications and Job Creation
    operations) with either the 'true' or 'false' value. And we agreed that a
    Printer SHOULD honor the request. However, it is conforming for a Printer
    to always renege and return the "notify-get-interval" (though such an
    implementation would not be following the recommendation).

    The reason that it would be unwise to require Event Wait Mode for even one
    connection on an IPPFAX Printer, is the case of a long job being submitted.
    There would be a significant time between receipt of the last page and the
    printing of that last page, during which the Printer MAY want to be
    accepting other jobs. Also a Job that is submitted with "job-hold-until"
    set for a long time in the future should not be able to tie up a connection
    until that time. Or a job that needs resources to be configured before it
    can be processed on a spooling printer that can process other jobs.

    AGREED> A client MUST accept the "notify-get-interval" and re-issue the
    Get-Notifications (with or without "notify-wait" = 'true') in order to get
    more events.

    AGREED> We don't need to add a new Printer Description attribute to
    indicate whether or not the Printer always reneges on Event Wait Mode
    requests. The client MUST be able to work with such a Printer. So the
    client may as well always request Event Wait Mode, whether or not the
    Printer really can do it and then take the appropriate action when the
    Printer reneges.

    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.

    AGREED> yes.

    AGREED> To clarify that the value of the "ippget-event-life" is the time by
    which a client must be reconnected to the Printer in order not to miss any
    events. So the client must factor in a fudge time in order to issue the
    Get-Notifications request in time to have the Printer accept it before the
    Event Life elapses.

    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-life" Printer Description attribute and the client needs to
    take into the account the time to make the connection.

    AGREED> That the "notify-get-interval" operation attribute returned in the
    response MUST be at least as long as the value of the "ippget-event-life"
    Printer Description attribute.

    NOT AGREED> However, if the value is greater than the Printer's
    "ippget-event-life" value, then a Notification Recipient could miss an event
    if it didn't poll at the "ippget-event-life" rate. What to do?

    We are still debating whether it is possible for the Printer to return a
    time to next poll that is ever larger than the Event Life time? If the
    Printer ever returns a larger value, the client could miss an event, unless
    the Printer magically increases its Life for that (those) Subscription
    object(s).

    So is returning a boolean the best the Printer can ever do?

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

    AGREED> Yes.



    This archive was generated by hypermail 2b29 : Thu Aug 09 2001 - 19:05:52 EDT