Printer Services Mail Archive: PS> [PSI]: minutes 10/15/02

PS> [PSI]: minutes 10/15/02

From: BERKEMA,ALAN C (HP-Roseville,ex1) (alan_berkema@hp.com)
Date: Tue Oct 15 2002 - 18:00:12 EDT

  • Next message: McDonald, Ira: "PS> FW: LISA Forum Europe - November 4-7, 2002 in Heidelberg, German y"

    Lots of new actions folks, scan for your name!

     PSI Working Group:
     *Alan Berkema *Gail Songer *Dave Hall
     *Jerry Thasher *Harry Lewis *Ted Tronson
     *Peter Mierau Peter Zehler Paul Tykodi
     *Bob Taylor Don Levinstone Lee Farrell
      Don Wright Kirk Ocke *Ira Mcdonald
      Amir Shahindoust
     
     * = attendance
     
    10/15/02 Agenda
    1) To Do & Action Progress
    2) Get Service Capabilities
    3) Mandatory Optional Attributes

    10/15/02 Minutes:
    See updated status and new discussion in line.

    1) To Do & Action Progress
    Walked through the previous actions and covered the second agenda item
    as one of the actions.

    > 10/08/02 Minutes:
    > As a prelude Ira suggested that we move PSI defined schemas
    > into a seperate
    > directory. Dave mentioned that the spec already calls for
    > them to be ps/0.95
    > so we will put them there.
    >
    > Action: Move them
    > Owner: Alan
      Status: Done
    >
    > 1) Review Harry's e-mail questions
    > The first question revolves around the use of DocumentTypeSupportQuery
    > and what it means if the TargetDeviceidentifier is NULL and
    > is this useful?
    > After much good discussion we decided that we can really do
    > this same thing
    > with
    > GetServiceAttributes as long as we explicitly provide an
    > example of how to
    > do it.
    > So DocumentTypeSupportQuery will be removed from the spec.
    >
    > Action: Write up some examples for GetServiceAttributes
    > Owner: Dave
      Status: Started

    Dave reviewed the examples he started with.
    GetServiceAttributes passes in requestedAttributes which is an XML
    instance document using that conforms to pwgAttr.xsd.
    snippet:

    <copies />
    <duplex />
    <n-up>4</n-up>

    If an empty element is used, the response is all of the values that
    a service or the targetDevice supports. In the case of copies the
    response might be 1 throught 99. In the case of duplex, if this is a
    boolean ine the pwgAttr schema it might be True or False etc.

    If an element has a value than the printer or service indicates whether
    or not it can accomodate the specific value.
    What actually gets returned here? How about
    <n-up>4</n-up> - Means yes, and
    <n-up /> or <n-up></n-up> Means No?

    More details on the examples revelaed in next rev. of the spec.

    In GetServiceAttributes is the targetDeviceIdentfier mandatory?
    Yes, though what if the Service knows about mant targets?
    Could someone respond with the discussion on why the answer is
    still Yes. I recall bits of the discussion though my note taking
    while hold the phone up to my ear was lacking.

    Next we looked for exactly what the "type" of element DocumentFormat
    is? Need to ask at SM meeting.

    Action: Discuss Document Format at SM meeting 10/17/02
    Owner: Ira, Peter Z., Dave (I may not make this meeting)
    Status: Open

    Action: Write up some examples for a document type support query
    Owner: Dave
    Status: Open

    Action: Discuss Non ambiguous element names at SM meeting 10/17/02
    Owner: Ira, Peter Z., Dave (I may not make this meeting)
    Status: Open

    Action: Have something to share on alternatives to returning a Schema in
    GetServiceAttributes by the next call.
    Owner: Bob
    Status: Open

    Action: Add an additional parameter for natural language & char set
    Owner: Dave
    Status: Open

    >
    > Harry's other question was around his new use case, which we agreed
    > was illustrated as Use model 5 in the requirements doc. The
    > question was
    > about
    > RegisterTargetDevice vs. AssociateTargetDevice. These are not
    > intended to
    > used
    > together and enable the different use models we have.
    >
    > Action: Write up a an Applicability statement for
    > AssociateTargetDevice
    > useful in firewall scenario etc. and is redundant otherwise.
    > Owner: Dave
    > Status: Open
    >
    > As we looked at use model 5 in the requirements doc, we noticed that
    > numbering on the
    > arrows were off.
    >
    > Action: Fix Numbers and post
    > Owner: Alan
    > Status: Open

    Action: Include trace diagram for use model 5 in the requirements doc
    Owner: Dave
    Status: Done, the example uses PSI in a dynamic nature

    Action: Include trace diagram for use model 5 in the requirements doc
    that shows pre configuration
    Owner: Dave
    Status: Open

    Discussion on how JobID works in above use model.
    Did we get an action out of this? Spec need some discussion
    on the way this should be handled?

    Action: Ask IANA for PSI port number
    Owner: Harry
    Status: Done, expect one in 30 days, likely not 3700

    This is about as far as we got touched on the next one, though
    may want to discuss some more. Likely that we will not allow
    dynamic ports at any time.
    >
    > 2) Review the use of port 3700
    > PSI has proposed asking IAN for a static port assignment we
    > are calling port
    > 3700 (IANA will probably dictate what actually get).
    > We debated this vs. just using a dynamic port. Ira had some
    > valid reasons
    > for
    > a static port in data aggregation scenarios with routers and gateways.
    > Decided that a static port will be used for QueryInterafceEndpoints.
    > Other discovery protocols will be used to get the hostname
    > and could return
    > a dynamic port. If a port is provide further queries will use
    > that dynamic
    > port.
    > Otherwise the static port will be used.
    > Doesn't this still open us up to the problems with dynamic ports?
    >
    > Action: Provide a brief write that explains why dynamic ports
    > have issues.
    > Also could get a brief write up on why overloading port 80 is
    > not a good
    > idea.
    > Owner: Ira
    > Status: Open
    >
    > 3) Review ToDo list
    > Dave walked us through the ToDo list see spec 0.90 an the
    > seem to be under control.
    >
    > 4) Call for action
    > We are currently at rev 0.90 and it's time to do your homework and to
    > take a close look at the spec. Harry set a good example with
    > his e-mail
    > questions. We will post intervening revs and a 0.94 candidate
    > 2 weeks before the F2F. Fixes from the F2F will be
    > incorporate into the
    > 0.95 candidate.
    >
    > Action: Review the spec.
    > Owner: All
    > Status: Open
    >
    > Thanks,
    > Alan



    This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 18:00:24 EDT