Hi,
I agree with all of Mike's comments.
Since the original Cloud Imaging Client (talking to the Cloud)
can't ever reach any URI in the remote domain "at" or "behind"
the Cloud Imaging System Proxy, there is no need to publish
them.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Wed, Jul 9, 2014 at 4:43 PM, Michael Sweet <msweet at apple.com> wrote:
> Bill,
>> On Jul 9, 2014, at 4:16 PM, William A Wagner <wamwagner at comcast.net>
> wrote:
>> At the last conference call, it was questioned whether the
> ServiceXriSupported complex element should be provided to the Cloud Imaging
> Services by the Local Imaging Services (via the Proxy). XriSupported
> includes XriUri, XriAuthentication, and XriSecurity, which correspond to
> the IPP attributes of printer-uri-supported, uri-authentication-supported,
> and uri-security-supported.
>>> Also, ServiceXriSupported comes from the IPP printer-xri-supported
> attribute (RFC 3380).
>> The point was made that, since the neither the Cloud Imaging System nor
> its services are intended to communicate directly with the Local Imaging
> System, they have no need for this information.
>>>> It should be noted that SystemXriSupported was added to the elements to be
> provided to the Cloud Imaging Control Service during the June 8 conference
> call (cloud-concall-minutes-20140609.pdf
> <http://ftp.pwg.org/pub/pwg/cloud/minutes/cloud-concall-minutes-20140609.pdf>).
> (ServiceXriSupported was added some time previous)
>>>> It would appear that, because by the Model all communication between the
> Cloud Services and the Local Services is initiated by the proxy, the Cloud
> Services do not need this information. However, it may be argued that the,
> aside from configured Services and perhaps state, the Cloud Services do not
> need any of the Local Service and System information sent; rather, this
> information is ultimately for the User. The question then is whether the
> User (in any role) has a need for this information. The question may be
> applied to all of the currently identified local system and service
> elements, the values of which are to be communicated to the Cloud
> Services..
>> For the Local System:
>> · CharsetConfigured
>> · NaturalLanguageConfigured
>> · MakeAndModel
>> · OwnerURI
>> · SystemGeoLocation
>> · SystemLocation
>> · SystemNameSystem
>> · XriSupported
>> · ConfiguredServices
>> · SystemUuid
>> · State
>> Probably don't need XriSupported or ConfiguredServices.
>> And for each Local Service:
>> · CharsetConfigured
>> · NaturalLanguageConfigured
>> · OperationsSupported
>> · ServiceName
>> · ServiceXriSupported
>> · VersionsSupported
>> · ServiceUuid
>> · State
>> · StateReasons
>> · IsAcceptingJobs
>> I would appreciate opinions on this.
>>> Probably don't need OperationsSupported, ServiceXriSupported, or
> VersionsSupported.
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>> _______________________________________________
> cloud mailing list
>cloud at pwg.org>https://www.pwg.org/mailman/listinfo/cloud>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20140709/11a8bf2f/attachment.html>