Randy, I have not copied your while message, only one comment from you,
where I think you are breaking the security.
Carl-Uno
>> -- It allows a TLS-capable server the ability
>> to only require TLS negotiation for
>> particular operations that require the server
>> to allocate resources. For instance, a
>> server that requires all print jobs to be
>> authenticated might still want all clients
>> to be able to get attributes for the printer,
>> as well as validate job parameters, without
>> going to the expense of performing TLS
>> negotiation. It basically allows an
>> administrator to decide what types of
>> operations should be authenticated. In the
>> current spec, ALL operations are authenticated
>> or NONE are. This is a nice scalability
>> feature
>>
>> TH> This is a good feature. However, if a client wants security and
>> TH> only has an HTTP URL, how does it get started? It certainly
>> doesn't
>> TH> want to do a Print-Job and send valuable data, before gettting the
>> TH> TLS URL. So this means that the client that wants security is
>> forced
>> TH> to do a Validate-Job with the HTTP://... URL in order to get back
>> TH> the redirect HTTPS://... URL, correct?
>>
> RT>You'll note that most of the scalability and flexibility of
> RT>this proposal mostly applies to IPP servers and subsequently
> RT>server administration framework. If a CLIENT wants a
>particular
> RT>operation to be "secure" , then it includes the
> RT>"client-security-requested" operation attribute with whatever
> RT>operation it is attempting.
>
CM> If you try this with a job submission operation, you have already sent
CM> your MIME type application/ipp, which means that all your data were sent
CM> unencrypted before you got the secure URI back, so your feature does
CM> not make any sense in combination with certain operations. It is not as
CM> generic as you describe it above. Instead you might actually mislead
CM> a user to think that their transmission is secure, when in reality
CM> it is not.
---