Re: Device Capabilities

[Dan Wing <dwing@xxxxxxxxx>]

>>I think the email model requires capabilities - the UK proposal talks
>>about using a minimal transmission until you know the capabilities of the
>>recipient.
>
>True, but just to be on the defensive for a moment.  Implementations could
>elect to handle this in different ways.  After all, exactly what are we
>trying to do with the exchange of capabilities?  We are trying to provide
>the far end with our capabilities (so they can log them) and we are trying
>to get theirs (so we can log them).  It would be simple to send a dummy
>Email fax (rather like a "Fax Capabilities PING"! - now, there's a thought
>.... no - I've rejected that - the far end may be a dial-up so a FAXPING
>would be no use) specifically for the purpose of sending capabilities and
>eliciting a response containing capabilities.

Sure.

>Like Email, most of the people I send faxes to I send to regularly so there
>is no hardship sending/getting capabilities either in the first real
>transmission or in a dummy.

But in the case where you send a fax the first time (lawyer to a potential 
client, let's say) you don't want a low-quality fax to print that first
time.  I suppose an implementation could connect to the remote machine,
determine its capabilities, and hang up.  That'd be better than printing a 
(potentially ugly) fax as your (all important) 'first impression' with a
potential customer (for example).


What if there is a hunt-group of 2 or 3 fax machines with different
capabilities, though??  We've got information from one of them, and
statistically we'll only talk to that machine every other or every
third telephone call.

>>However, I don't believe it addresses the cases where the
>>recipient's capabilities are upgraded or downgraded
>
>Oh yes it does!  

Perhaps, but I've invented one situation (see below) which causes quite
a lot of work and introduces a potential unable-to-deliver problem with
your solution.

>DIS is sent with every message and every response and
>either end would be immediately aware of any change at the other - and log
>it.  All automatic and all simple.  I admit that you might send one
>transmission and receive one negative confirmation (along with the new DIS)
>so your system could automatically adjust and re-transmit using the new
>capabilities.  

So the 'bounce' would contain the full original fax so it could be 
downgraded and re-sent?  Again, why not have the offramp do the downgrade
itself instead of the onramp (or whatever box is doing the 'automatic 
adjustment' you mention above.

>Swapping machines in and out does not happen that often
>(except in our R&D lab!!) so I don't think this is a serious real-world 
>problem.

It is a real world problem - hunt groups and failed (broken) fax machines.

The last company I worked for had two in one office on a hunt group - the
first one was our fancy plain paper fax, the other was the backup thermal
fax (because the thermal one hadn't died yet, we owned the PBX, and people
stole the paper from the plainpaper machine for the laser printer all the
time). 

In your scenerio above, with a hunt group with machines like I have above, I
believe the steps would be like this if we connected to the thermal fax
after having connected to the fancy fax in all previous connections:

  1. offramp bounces the fax to the onramp (because dumb fax doesn't like 
     some of the fancy stuff)
  2. onramp updates its recipient capabilities database
  3. onramp downgrades the fax
  4. onramp re-sends fax to offramp
  5. offramp will talk to fancy machine or dumb machine.  If it talks
     to fancy machine hopefully the fancy machine will accpet the fax
     that was downgraded.
  6. onramp's recipient capabilities database is updated based on the
     machine the offramp just talked to

What if in (5) the fancy fax machine didn't like one of the features
of the dumb fax machine -- how often do we bounce the fax for incorrect 
capabilities.

I think the offramp needs to be able to downgrade from anything the 
offramp is sent.

>>Futher, with vCard or the UK proposal, consider the case where two fax
>>machines are connected to a hunt-group (where someone dials one number
>>and can get the unoccupied fax machine), where the two fax machines have
>>different capabilities.  If you store the capabilities along with the
>>phone number you dialed (which is the only way I think such a database
>>could be designed), you won't get the "correct" fax machine, thus you'll
>>earn a bounce (not good) or some piece of software or firmware will have
>>to downgrade the fax (which I believe is impossible with the UK proposal
>>which includes T.30 data in the message itself, so an offramp couldn't be
>>expected to understand all the NSFs that are possible).
>
>True.  On the other hand I could think of implementations to get round some
>of this.
>
>>(Or is downgrading possible with the UK proposal?
>
>Yes, after receipt of the DIS in the negative confirmation.  Obviously the
>sender would then do exactly what we do for real-time fax - adjust the job
>according to the capabilities of the receiver - it does not require any
>manual intervention to do this.

By 'sender' do you mean the sending fax machine or the sending offramp?

>>And if so, doesn't that mean the offramp understands all of the T.30
>"stuff" encoded in
>>the message and could transmit that stuff itself?)
>
>I don't like the idea of intermediate intelligence because if I am attaching
>files to my faxes and the off ramp finds the receiver can't handle files
>there is no way it can adjust things accordingly.  I prefer everything to be
>end-to-end - like real time fax.

There has to be some intermediate intelligence to keep T.30 happy in the
face of network delays (unless you are using RSVP or have a network
with little delay or predictable delay).

>>I view bounces to non-deliverable faxes due to incompatible capabilities
>>as a workaround to the problem, not a true solution.
>
>I true solution is real-time - no more, no less!  However, we are not (I
>think) discussing real-time here.

I was referring to bounces to the sender's fax machine; what happens 
internal to the S&F software to do downgrading is more-or-less irrelevant
as long as we don't get into a non-deliverable state (as I outlined above).

>>On (D), above, the client can:
>>
>>  1.  guess at the recipient's capabilities and send the message.  This
>>      is what happens with email today.
>
>Agreed.  You can always send fine resolution images first time and be sure
>of getting through.
>
>>  2.  determine the recipient's capabilities and send a message that
>>      doesn't exceed those capabilities.
>>      
>>      First, this only needs to be done if the sender has capabilities
>>      that exceed the minimum implementation requirements specified for
>>      case (1), above.
>>      
>>      If the sender has capabilities that exceed the minimum
>>      requirements, and:
>>      
>>        a. it cannot determine the capabilities of the recipient, the
>>           sender should send the minimum required capabilities.  
>>        b. it can determine the capabilties of the recipient, it can send
>>           the message using those capabilities.
>
>Total agreement.  This leaves freedom to do EVERYTHING or the minimum.  No
>second-best here.
>      
>>  a.  the sender needs to never exceed the recipient's capabilities.
>>      With the UK proposal that includes T.30 data in the message, I
>>      think you can exceed the offramp's capabilities
>
>I have a real hangup about this.  I don't see the need for an "onramp" or an
>"offramp"  I just see two Email addresses sending faxes to one another - in
>which case the T.30 frames hold everything we will ever need.

I've seen you state that before (two email addresses sending mail back and
forth).  As far as any legacy SMTP MTAs between them, that's true.  If the
goal is just to standardize on an image format, we just need to define a 
MIME type and we're done.

That's not my understanding of the goal of this WG.  My understanding
was to concentrate on S&F fax, including integration with legacy (which
means something dials the phone, and I think 'offramp' is as good a term
as any), and including the integration of fax with email.

By putting all the destination information 

>>or:
>>  b.  the offramp needs to be able to transform the message into
>>      something that will work for any recipient.  Perhaps this will
>>      always fall into the "vender value-add", "implementation specific"
>>      arena, and bounces are generated when this can't happen???
>
>Again, I don't like any processing of the message between sender and
>recipient.  The "vendors" I am interested in are the ones who generate the
>Email fax in the first place and those who receive and decode it.  This
>falls into two camps: PC software and fax-capable machines.

But as fax-capable machines don't have disk drives today, they aren't likely
to have one in the near future.  Thus I wouldn't expect them to handle
bounces back to them for subsequent downgrading and re-sending. Fax-capable
machines also wouldn't be able to have a huge directory of the capabilities
of the other systems they've talked to. 

I'm still concerned about caching capabilities, though.

>I hope I don't sound too grumpy but I have spent the day putting a second
>hard disk into my home PC, cloning my office machine onto this disk for use
>at home and trying to get all my hardware gadgets working under Windows '95.
>6 hours of my life have gone out of the window thanks to Mr Gates!  Perhaps
>I should send him a bill for my professional time!!!!  Does ANYONE really
>believe that Windows '95 is "intuitive"?  Perhaps I am just getting old!

It beats Win31.  If Mac had gone with two-button mice I'd be a Mac fan,
though.

-Dan Wing