Google ক্লাউড প্রিন্ট 31 ডিসেম্বর, 2020 থেকে আর সমর্থিত নয়। মাইগ্রেট করার জন্য সহায়তার নিবন্ধটি দেখুন।

এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

প্রাইভেট

Privet হল একটি ক্লাউড ডিভাইস লোকাল ডিসকভারি API যা ক্লাউড পরিষেবা দ্বারা ব্যবহৃত হয়। এই নথিটি নিম্নলিখিত বিভাগে সংগঠিত:

ভূমিকা : Privet পরিচিতি
আবিষ্কার : স্থানীয় আবিষ্কার প্রক্রিয়া
ঘোষণা : স্থানীয় আবিষ্কারের ঘোষণা
API : সাধারণ ক্লাউড ডিভাইসের জন্য Privet APIs
প্রিন্টার API : প্রিন্টার দ্বারা ব্যবহৃত Privet APIs
পরিশিষ্ট : সম্পূরক চিত্র

1। পরিচিতি

ক্লাউড কানেক্টেড ডিভাইসের অনেক সুবিধা রয়েছে। তারা অনলাইন রূপান্তর পরিষেবাগুলি ব্যবহার করতে পারে, ডিভাইসটি অফলাইনে থাকাকালীন কাজের সারিগুলি হোস্ট করতে পারে এবং বিশ্বের যে কোনও জায়গা থেকে অ্যাক্সেসযোগ্য হতে পারে৷ যাইহোক, একটি প্রদত্ত ব্যবহারকারীর দ্বারা অ্যাক্সেসযোগ্য অনেক ক্লাউড ডিভাইসের সাথে, অবস্থানের উপর ভিত্তি করে নিকটতম ডিভাইসটি খুঁজে বের করার জন্য আমাদের একটি পদ্ধতি প্রদান করতে হবে। প্রাইভেট প্রোটোকলের উদ্দেশ্য হল ক্লাউড ডিভাইসগুলির নমনীয়তাকে একটি উপযুক্ত স্থানীয় আবিষ্কার প্রক্রিয়ার সাথে আবদ্ধ করা যাতে ডিভাইসগুলি নতুন পরিবেশে সহজেই আবিষ্কৃত হয়।

এই প্রোটোকলের লক্ষ্যগুলি হল:

ক্লাউড ডিভাইসগুলিকে স্থানীয়ভাবে আবিষ্কার করা যায়
একটি ক্লাউড পরিষেবা দিয়ে ক্লাউড ডিভাইস নিবন্ধন করুন
নিবন্ধিত ডিভাইসগুলিকে তাদের ক্লাউড প্রতিনিধিত্বের সাথে সংযুক্ত করুন
অফলাইন কার্যকারিতা সক্ষম করুন
বাস্তবায়ন সহজ করুন যাতে ছোট ডিভাইস এটি ব্যবহার করতে পারে

Privet প্রোটোকল 2টি প্রধান অংশ নিয়ে গঠিত: আবিষ্কার এবং API। স্থানীয় নেটওয়ার্কে ডিভাইসটি খুঁজে পেতে ডিসকভারি ব্যবহার করা হয় এবং ডিভাইস সম্পর্কে তথ্য পেতে এবং কিছু ক্রিয়া সম্পাদন করতে API ব্যবহার করা হয়। এই নথি জুড়ে, ডিভাইসটি প্রাইভেট প্রোটোকল বাস্তবায়নকারী একটি ক্লাউড সংযুক্ত ডিভাইসকে নির্দেশ করে।

2. আবিষ্কার

আবিষ্কার হল একটি জিরোকনফ ভিত্তিক (mDNS + DNS-SD) প্রোটোকল। ডিভাইসটিকে অবশ্যই IPv4 লিঙ্ক-স্থানীয় ঠিকানা প্রয়োগ করতে হবে। ডিভাইসটিকে অবশ্যই mDNS এবং DNS-SD স্পেস মেনে চলতে হবে।

http://www.rfc-editor.org/rfc/rfc3927.txt (IPv4 লিঙ্ক-স্থানীয়)
http://www.rfc-editor.org/rfc/rfc4862.txt (IPv6 লিঙ্ক-স্থানীয়)
http://www.rfc-editor.org/rfc/rfc6762.txt (mDNS)
http://www.rfc-editor.org/rfc/rfc6763.txt (DNS-SD)

ডিভাইসটি অবশ্যই উপরোক্ত স্পেসিফিকেশন অনুযায়ী নামের দ্বন্দ্ব সমাধান করতে হবে।

2.1। সেবার ধরণ

DNS পরিষেবা আবিষ্কার পরিষেবার প্রকারের জন্য নিম্নলিখিত বিন্যাস ব্যবহার করে: _applicationprotocol._transportprotocol । Privet প্রোটোকলের ক্ষেত্রে, DNS-SD-এর পরিষেবার ধরনটি হওয়া উচিত: _privet._tcp

ডিভাইসটি অন্যান্য পরিষেবার প্রকারগুলিও প্রয়োগ করতে পারে। ডিভাইস দ্বারা প্রয়োগ করা সমস্ত পরিষেবা প্রকারের জন্য একই পরিষেবা উদাহরণের নাম ব্যবহার করার পরামর্শ দেওয়া হচ্ছে৷ উদাহরণস্বরূপ: একটি প্রিন্টার "প্রিন্টার XYZ._privet._tcp" এবং "প্রিন্টার XYZ._printer._tcp" পরিষেবাগুলি প্রয়োগ করতে পারে৷ এটি ব্যবহারকারীর জন্য সেটআপ সহজতর করবে। যাইহোক, Privet ক্লায়েন্টরা শুধুমাত্র "_privet._tcp" এর জন্য দেখবে।

প্রধান পরিষেবার ধরন ছাড়াও, ডিভাইসটিকে অবশ্যই তার সংশ্লিষ্ট সাব-টাইপ(গুলি) এর জন্য PTR রেকর্ডের বিজ্ঞাপন দিতে হবে (ডিএনএস-এসডি স্পেক দেখুন: "7.1। নির্বাচনী উদাহরণ গণনা (সাবটাইপ)")। বিন্যাস অনুসরণ করা উচিত: _<subtype>._sub._privet._tcp

বর্তমানে সমর্থিত একমাত্র ডিভাইস সাবটাইপ হল প্রিন্টার । সুতরাং, সমস্ত প্রিন্টারকে অবশ্যই দুটি পিটিআর রেকর্ডের বিজ্ঞাপন দিতে হবে:

_privet._tcp.local
_printer._sub._privet._tcp.local

2.2। TXT রেকর্ড

DNS পরিষেবা আবিষ্কার TXT রেকর্ডে একটি পরিষেবা সম্পর্কে ঐচ্ছিক তথ্য যোগ করার জন্য ক্ষেত্রগুলিকে সংজ্ঞায়িত করে৷ একটি TXT রেকর্ড কী/মান জোড়া নিয়ে গঠিত। প্রতিটি কী/মান জোড়া দৈর্ঘ্য বাইট থেকে শুরু হয় এবং 255 বাইট পর্যন্ত পাঠ্য থাকে। কী হল প্রথম '=' অক্ষরের আগে লেখা টেক্সট এবং মান হল শেষ পর্যন্ত প্রথম '=' অক্ষরের পরের টেক্সট। স্পেসিফিকেশন রেকর্ডে কোনো মান না রাখার অনুমতি দেয়, এই ক্ষেত্রে '=' অক্ষর হবে না বা '=' অক্ষরের পরে কোনো পাঠ্য থাকবে না। (ডিএনএস-এসডি স্পেস দেখুন: "6.1। DNS TXT রেকর্ডের জন্য সাধারণ বিন্যাস নিয়ম" DNS TXT রেকর্ড বিন্যাসের জন্য এবং প্রস্তাবিত দৈর্ঘ্যের জন্য "6.2. DNS-SD TXT রেকর্ড আকার")।

Privet-এর জন্য ডিভাইসটিকে TXT রেকর্ডে নিম্নলিখিত কী/মান জোড়া পাঠাতে হবে। কী/মান স্ট্রিংগুলি অক্ষর-সংবেদনশীল, উদাহরণস্বরূপ "CS=অনলাইন" এবং "cs=ONLINE" একই। TXT রেকর্ডের তথ্য অবশ্যই /info API এর মাধ্যমে অ্যাক্সেসযোগ্য হিসাবে একই হতে হবে (4.1. API বিভাগ দেখুন)।

TXT রেকর্ডের আকার 512 বাইটের নিচে রাখার সুপারিশ করা হয়।

2.2.1। txtvers

TXT কাঠামোর সংস্করণ। txtvers অবশ্যই TXT কাঠামোর প্রথম রেকর্ড হতে হবে। বর্তমানে একমাত্র সমর্থিত সংস্করণ হল 1।

txtvers=1

2.2.2। ty

ডিভাইসের একটি ব্যবহারকারী-পাঠযোগ্য নাম প্রদান করে। উদাহরণ স্বরূপ:

ty=Google Cloud Ready Printer Model XYZ

2.2.3। নোট (ঐচ্ছিক)

ডিভাইসের একটি ব্যবহারকারী-পাঠযোগ্য নাম প্রদান করে। উদাহরণ স্বরূপ:

note=1st floor lobby printer

দ্রষ্টব্য: এটি একটি ঐচ্ছিক কী এবং এড়িয়ে যাওয়া হতে পারে৷ যাইহোক, যদি উপস্থিত থাকে, ব্যবহারকারী এই মান পরিবর্তন করতে সক্ষম হওয়া উচিত। ডিভাইস নিবন্ধন করার সময় একই বিবরণ ব্যবহার করা আবশ্যক।

2.2.4। url

সার্ভার URL এই ডিভাইসটি সংযুক্ত (প্রটোকল সহ)। উদাহরণ স্বরূপ:

url=https://www.google.com/cloudprint

2.2.5। প্রকার

এই ডিভাইস দ্বারা সমর্থিত ডিভাইস সাব-টাইপগুলির কমা দ্বারা পৃথক করা তালিকা। বিন্যাস হল: "type=_subtype1, _subtype2"। বর্তমানে, একমাত্র সমর্থিত ডিভাইস সাবটাইপ হল প্রিন্টার ।

type=printer

তালিকাভুক্ত প্রতিটি উপপ্রকার একটি সংশ্লিষ্ট পিটিআর রেকর্ড ব্যবহার করে বিজ্ঞাপন দেওয়া উচিত। প্রতিটি সমর্থিত পরিষেবা উপ-প্রকারের জন্য, একটি সংশ্লিষ্ট আইটেম থাকা উচিত। পরিষেবার সাবটাইপের নাম (<subtype>._sub._privet._tcp) এখানে ডিভাইসের প্রকারের সমান হওয়া উচিত।

2.2.6। আইডি

ডিভাইস আইডি। যদি ডিভাইসটি এখনও নিবন্ধিত না হয় তবে এই কীটি উপস্থিত থাকা উচিত, তবে মান খালি হওয়া উচিত। উদাহরণ স্বরূপ:

  id=11111111-2222-3333-4444-555555555555
  id=

2.2.7। cs

ডিভাইসের বর্তমান সংযোগ অবস্থা নির্দেশ করে। চারটি সম্ভাব্য মান এই বৈশিষ্ট্যে সংজ্ঞায়িত করা হয়েছে।

"অনলাইন" নির্দেশ করে যে ডিভাইসটি বর্তমানে ক্লাউডের সাথে সংযুক্ত রয়েছে৷
"অফলাইন" নির্দেশ করে যে ডিভাইসটি স্থানীয় নেটওয়ার্কে উপলব্ধ, কিন্তু সার্ভারের সাথে কথা বলতে পারে না৷
"সংযোগ" নির্দেশ করে যে ডিভাইসটি তার স্টার্টআপ সিকোয়েন্স সম্পাদন করছে এবং এখনও সম্পূর্ণ অনলাইন নয়৷
"কনফিগার করা হয়নি" নির্দেশ করে যে ডিভাইসের ইন্টারনেট অ্যাক্সেস এখনও কনফিগার করা হয়নি। এই মানটি বর্তমানে ব্যবহার করা হয় না, তবে স্পেসিফিকেশনের ভবিষ্যতের সংস্করণে উপযোগী হতে পারে।

উদাহরণ স্বরূপ:

cs=অনলাইন
cs=অফলাইন
cs = সংযোগ

যদি ডিভাইসটি একটি ক্লাউডের সাথে নিবন্ধিত হয়ে থাকে, তবে স্টার্টআপে এটির সংযোগের অবস্থা সনাক্ত করতে সার্ভারের সাথে সংযোগ পরীক্ষা করা উচিত (উদাহরণস্বরূপ, ডিভাইস সেটিংস পেতে ক্লাউড API কল করা)। এই মান রিপোর্ট করতে ডিভাইসটি তার বিজ্ঞপ্তি চ্যানেল (যেমন XMPP) সংযোগ অবস্থা ব্যবহার করতে পারে। স্টার্টআপে অনিবন্ধিত ডিভাইসগুলি তাদের সংযোগের অবস্থা সনাক্ত করার জন্য একটি ডোমেনকে পিং করতে পারে (উদাহরণস্বরূপ, ক্লাউড প্রিন্ট ডিভাইসের জন্য www.google.com পিং)।

3. ঘোষণা

ডিভাইস স্টার্টআপ, শাটডাউন বা অবস্থা পরিবর্তনের সময়, ডিভাইসটিকে অবশ্যই mDNS স্পেসিফিকেশনে বর্ণিত ঘোষণার ধাপটি সম্পাদন করতে হবে। এটি তাদের মধ্যে কমপক্ষে এক-সেকেন্ডের ব্যবধান সহ কমপক্ষে দুবার সংশ্লিষ্ট ঘোষণা পাঠাতে হবে।

3.1। স্টার্টআপ

ডিভাইস স্টার্টআপে এটি অবশ্যই mDNS স্পেসিফিকেশনে বর্ণিত পদক্ষেপগুলি অনুসন্ধান এবং ঘোষণার পদক্ষেপগুলি সম্পাদন করবে৷ এক্ষেত্রে SRV, PTR এবং TXT রেকর্ড পাঠাতে হবে। সম্ভব হলে সমস্ত রেকর্ডকে একটি DNS প্রতিক্রিয়াতে গোষ্ঠীভুক্ত করার পরামর্শ দেওয়া হয়। যদি না হয়, নিম্নলিখিত অর্ডার সুপারিশ করা হয়: SRV, PTR, TXT রেকর্ড।

3.2। শাটডাউন

ডিভাইস শাটডাউনে এটি TTL=0 (mDNS ডকুমেন্টেশনে বর্ণিত) সহ একটি "গুডবাই প্যাকেট" পাঠিয়ে এটি সম্পর্কে সমস্ত আগ্রহী পক্ষকে অবহিত করার চেষ্টা করা উচিত।

3.3। হালনাগাদ

TXT-তে বর্ণিত কোনো তথ্য পরিবর্তিত হলে, ডিভাইসটিকে অবশ্যই একটি আপডেট ঘোষণা পাঠাতে হবে। এই ক্ষেত্রে শুধুমাত্র নতুন TXT রেকর্ড পাঠানোই যথেষ্ট। উদাহরণস্বরূপ, একটি ডিভাইস নিবন্ধিত হওয়ার পরে, এটি অবশ্যই নতুন ডিভাইস আইডি সহ একটি আপডেট ঘোষণা পাঠাতে হবে৷

4. API

একটি ক্লাউড ডিভাইস আবিষ্কৃত হওয়ার পরে, স্থানীয় নেটওয়ার্কের মাধ্যমে সরাসরি ডিভাইসের সাথে ক্লায়েন্ট যোগাযোগ সক্ষম করা হয়। সমস্ত API HTTP 1.1 ভিত্তিক। ডেটা ফরম্যাটগুলি JSON ভিত্তিক। API অনুরোধগুলি GET বা POST অনুরোধ হতে পারে৷

প্রতিটি অনুরোধে একটি বৈধ " X-Privet-Token " শিরোনাম থাকা আবশ্যক৷ শুধুমাত্র একটি খালি "X-Privet-Token" শিরোনাম রাখার অনুমতি দেওয়া হল /privet/info অনুরোধ (মনে রাখবেন যে শিরোনামটি এখনও উপস্থিত থাকতে হবে)। যদি "X-Privet-Token" শিরোনামটি অনুপস্থিত থাকে, তাহলে ডিভাইসটিকে অবশ্যই নিম্নলিখিত HTTP 400 ত্রুটির সাথে প্রতিক্রিয়া জানাতে হবে:

HTTP/1.1 400 Missing X-Privet-Token header.

যদি "X-Privet-Token" শিরোনাম খালি বা অবৈধ হয়, তাহলে ডিভাইসটিকে অবশ্যই "অবৈধ X-Privet-টোকেন ত্রুটি" সহ প্রতিক্রিয়া জানাতে হবে (invalid_x_privet_token, বিস্তারিত জানার জন্য ত্রুটি বিভাগ দেখুন)। একমাত্র ব্যতিক্রম হল /info API। কেন এটি করা হয় এবং কীভাবে টোকেন তৈরি করা উচিত সে সম্পর্কে আরও তথ্যের জন্য, পরিশিষ্ট A দেখুন: XSSI এবং XSRF আক্রমণ এবং প্রতিরোধ।

একটি অনুরোধ করা API বিদ্যমান না থাকলে বা সমর্থিত না হলে, ডিভাইসটিকে অবশ্যই একটি HTTP 404 ত্রুটি ফেরত দিতে হবে৷

4.1। API প্রাপ্যতা

যেকোনো API (/info API সহ) প্রকাশ করার আগে, স্থানীয় সেটিংস চেক করতে ডিভাইসটিকে অবশ্যই সার্ভারের সাথে যোগাযোগ করতে হবে। স্থানীয় সেটিংস পুনঃসূচনা মধ্যে সংরক্ষণ করা আবশ্যক. সার্ভার উপলব্ধ না হলে, সর্বশেষ পরিচিত স্থানীয় সেটিংস ব্যবহার করা উচিত। ডিভাইসটি এখনও নিবন্ধিত না হলে, এটি ডিফল্ট সেটিংস অনুসরণ করা উচিত।

ক্লাউড প্রিন্ট ডিভাইসগুলিকে নিবন্ধন, গ্রহণ এবং স্থানীয় সেটিংস আপডেট করতে নীচের পদক্ষেপগুলি অনুসরণ করতে হবে৷

4.1.1। নিবন্ধন

যখন ডিভাইসটি নিবন্ধিত হয়, তখন এটিকে অবশ্যই "স্থানীয়_সেটিংস" পরামিতি উল্লেখ করতে হবে, নিম্নরূপ:

{
       "current": {
                "local_discovery": true,
                "access_token_enabled": true,
                "printer/local_printing_enabled": true,
                "printer/conversion_printing_enabled": true,
                "xmpp_timeout_value": 300
        }
}

নিম্নলিখিত সেটিংস সেট করা যেতে পারে:

মান নাম	মান প্রকার	বর্ণনা
স্থানীয়_আবিষ্কার	বুলিয়ান	স্থানীয় আবিষ্কারের কার্যকারিতা অনুমোদিত কিনা তা নির্দেশ করে। "মিথ্যা" হলে, সমস্ত স্থানীয় API (/তথ্য সহ) এবং DNS-SD আবিষ্কার অক্ষম করতে হবে। ডিফল্টরূপে, নতুন নিবন্ধিত ডিভাইস "সত্য" পাস করা উচিত।
অ্যাক্সেস_টোকেন_সক্ষম	বুলিয়ান (ঐচ্ছিক)	স্থানীয় নেটওয়ার্কে /accesstoken API প্রকাশ করা উচিত কিনা তা নির্দেশ করে। ডিফল্টরূপে "সত্য" হওয়া উচিত।
প্রিন্টার/স্থানীয়_মুদ্রণ_সক্ষম	বুলিয়ান (ঐচ্ছিক)	স্থানীয় নেটওয়ার্কে স্থানীয় মুদ্রণ কার্যকারিতা (/প্রিন্টার/ক্রিয়েটজব, /প্রিন্টার/সাবমিটডক, /প্রিন্টার/জবস্টেট) প্রকাশ করা উচিত কিনা তা নির্দেশ করে। ডিফল্টরূপে "সত্য" হওয়া উচিত।
প্রিন্টার/রূপান্তর_মুদ্রণ_সক্ষম	বুলিয়ান (ঐচ্ছিক)	স্থানীয় মুদ্রণ রূপান্তরের জন্য সার্ভারে কাজ পাঠাতে পারে কিনা তা নির্দেশ করে। স্থানীয় মুদ্রণ সক্ষম হলেই কেবল তা বোঝা যায়।
xmpp_timeout_value	int (ঐচ্ছিক)	XMPP চ্যানেল পিংগুলির মধ্যে সেকেন্ডের সংখ্যা নির্দেশ করে৷ ডিফল্টরূপে 300 (5 মিনিট) বা তার বেশি হতে হবে।

গুরুত্বপূর্ণ: কোনো ঐচ্ছিক মানের অভাব নির্দেশ করে যে সংশ্লিষ্ট কার্যকারিতা ডিভাইস দ্বারা সম্পূর্ণরূপে অসমর্থিত।

4.1.2। স্টার্টআপ

ডিভাইস স্টার্টআপে, স্থানীয় নেটওয়ার্কে প্রকাশ করার জন্য কী কী API পাওয়া যায় তা পরীক্ষা করতে সার্ভারের সাথে যোগাযোগ করা উচিত। ক্লাউড প্রিন্টের সাথে সংযুক্ত প্রিন্টারদের জন্য, তাদের কল করা উচিত:

/cloudprint/printer?printerid=<printer_id>

বা

/cloudprint/list

/ক্লাউডপ্রিন্ট/প্রিন্টারকে /ক্লাউডপ্রিন্ট/তালিকা থেকে পছন্দ করা হয়, তবে উভয়ই কাজ করবে।

স্থানীয় API-এর সেটিংস সহ এই API বর্তমান ডিভাইসের পরামিতি প্রদান করে। সার্ভার থেকে উত্তর নিম্নলিখিত বিন্যাস থাকবে:

"local_settings": {
        "current": {
                "local_discovery": true,
                "access_token_enabled": true,
                "printer/local_printing_enabled": true,
                "printer/conversion_printing_enabled": true,
                "xmpp_timeout_value": 300
         },
         "pending": {
                "local_discovery": true,
                "access_token_enabled": true,
                "printer/local_printing_enabled": false,
                "printer/conversion_printing_enabled": false,
                "xmpp_timeout_value": 500
         }
}

"বর্তমান" বস্তু সেটিংস নির্দেশ করে যা এই মুহূর্তে কার্যকর।

"মুলতুবি" বস্তুটি নির্দেশ করে যে সেটিংস ডিভাইসে প্রয়োগ করা উচিত (এই বস্তুটি অনুপস্থিত হতে পারে)।

একবার ডিভাইসটি "মুলতুবি" সেটিংস দেখে, এটি অবশ্যই তার অবস্থা আপডেট করবে (নীচে দেখুন)।

4.1.3। হালনাগাদ

সেটিংস আপডেটের প্রয়োজন হলে, ডিভাইসে একটি XMPP বিজ্ঞপ্তি পাঠানো হবে। বিজ্ঞপ্তিটি নিম্নলিখিত বিন্যাসে হবে:

<device_id>/update_settings

এই ধরনের একটি বিজ্ঞপ্তি প্রাপ্তির পরে, ডিভাইসটিকে অবশ্যই সাম্প্রতিক সেটিংস পেতে সার্ভারকে জিজ্ঞাসা করতে হবে৷ ক্লাউড প্রিন্ট ডিভাইস অবশ্যই ব্যবহার করতে হবে:

/cloudprint/printer?printerid=<printer_id>

একবার ডিভাইসটি /ক্লাউডপ্রিন্ট/প্রিন্টার API (স্টার্টআপে বা বিজ্ঞপ্তির কারণে) এর ফলে "মুলতুবি" বিভাগটি দেখে, নতুন সেটিংস মনে রাখার জন্য এটির অভ্যন্তরীণ অবস্থা আপডেট করতে হবে। নতুন সেটিংস নিশ্চিত করতে সার্ভার API কল করতে হবে। ক্লাউড প্রিন্টারের জন্য, ডিভাইসটিকে অবশ্যই /ক্লাউডপ্রিন্ট/আপডেট API কল করতে হবে এবং রেজিস্ট্রেশনের সময় "স্থানীয়_সেটিংস" প্যারামিটার ব্যবহার করতে হবে।

XMPP চ্যানেলের সাথে পুনরায় সংযোগ করার সময়, ডিভাইসটিকে অবশ্যই /ক্লাউডপ্রিন্ট/প্রিন্টার এপিআই কল করতে হবে যাতে শেষ সময় থেকে স্থানীয় সেটিংস পরিবর্তন করা হয়েছে কিনা।

4.1.3.1। স্থানীয় সেটিংস মুলতুবি৷

"স্থানীয়_সেটিংস" প্যারামিটার যা ডিভাইসটি সার্ভার API কল করতে ব্যবহার করে তাতে কখনই "মুলতুবি" বিভাগ থাকতে হবে না।

4.1.3.2। স্থানীয় সেটিংস বর্তমান

শুধুমাত্র ডিভাইসটি "স্থানীয়_সেটিংস" এর "বর্তমান" বিভাগটি পরিবর্তন করতে পারে। অন্য সবাই "মুলতুবি" বিভাগটি পরিবর্তন করবে, এবং ডিভাইস দ্বারা "বর্তমান" বিভাগে পরিবর্তনগুলি প্রচার না হওয়া পর্যন্ত অপেক্ষা করুন৷

4.1.4 অফলাইন

স্টার্টআপের সময় সার্ভারের সাথে যোগাযোগ করতে না পারলে, বিজ্ঞপ্তির পরে, ডিভাইসটি অবশ্যই সর্বশেষ পরিচিত স্থানীয় সেটিংস ব্যবহার করবে।

4.1.5। পরিষেবা থেকে ডিভাইস মুছে ফেলা হচ্ছে

যদি ডিভাইসটি পরিষেবা থেকে মুছে ফেলা হয় (উদাহরণস্বরূপ GCP), ডিভাইসটিতে একটি XMPP বিজ্ঞপ্তি পাঠানো হবে। বিজ্ঞপ্তিটি নিম্নলিখিত বিন্যাসে হবে:

<device_id>/delete

এই ধরনের একটি বিজ্ঞপ্তি পাওয়ার পর, ডিভাইসটিকে অবশ্যই সার্ভারে গিয়ে তার অবস্থা পরীক্ষা করতে হবে। ক্লাউড প্রিন্ট ডিভাইস অবশ্যই ব্যবহার করতে হবে:

/cloudprint/printer?printerid=<printer_id>

ডিভাইসটি অবশ্যই সফল = মিথ্যা এবং কোনো ডিভাইস/প্রিন্টার বিবরণ সহ একটি সফল HTTP উত্তর পাবে। এর অর্থ হল ডিভাইসটি সার্ভার থেকে সরানো হয়েছে, এবং ডিভাইসটিকে অবশ্যই তার শংসাপত্রগুলি মুছে ফেলতে হবে এবং ডিফল্ট ফ্যাক্টরি সেটিংস মোডে যেতে হবে৷

যে কোনো সময় ডিভাইসটি /ক্লাউডপ্রিন্ট/প্রিন্টার API (স্টার্টআপ, আপডেট সেটিংস বিজ্ঞপ্তি, দৈনিক পিং) এর ফলে এটি মুছে ফেলা হয়েছে নির্দেশ করে এমন একটি উত্তর পায়, এটি অবশ্যই তার প্রমাণপত্র মুছে ফেলতে হবে এবং ডিফল্ট মোডে যেতে হবে।

4.2। /privet/info API

তথ্য API বাধ্যতামূলক এবং প্রতিটি ডিভাইস দ্বারা প্রয়োগ করা আবশ্যক। এটি "/privet/info" url-এর জন্য একটি HTTP GET অনুরোধ: GET /privet/info HTTP/1.1

তথ্য API একটি ডিভাইস এবং এটি সমর্থন করে কার্যকারিতা সম্পর্কে প্রাথমিক তথ্য প্রদান করে। এই এপিআই কখনই ডিভাইসের স্থিতি পরিবর্তন করবে না বা কোনো কাজ করবে না, কারণ এটি XSRF আক্রমণের জন্য ঝুঁকিপূর্ণ। এটি একটি খালি "এক্স-প্রাইভেট-টোকেন" শিরোনাম রাখার জন্য অনুমোদিত একমাত্র API। ক্লায়েন্টদের /privet/info API কল করা উচিত "X-Privet-Token" শিরোনাম X-Privet-Token-এ সেট করা: ""

তথ্য API-কে অবশ্যই আবিষ্কারের সময় TXT রেকর্ডে উপলব্ধ ডেটার সাথে সামঞ্জস্যপূর্ণ ডেটা ফেরত দিতে হবে।

4.2.1। ইনপুট

/privet/info API এর কোন ইনপুট প্যারামিটার নেই।

4.2.2। প্রত্যাবর্তন

/privet/info API ডিভাইস এবং সমর্থিত কার্যকারিতা সম্পর্কে প্রাথমিক তথ্য প্রদান করে।

TXT কলাম DNS-SD TXT রেকর্ডের সংশ্লিষ্ট ক্ষেত্র নির্দেশ করে।

মান নাম	মান প্রকার	বর্ণনা	TXT
সংস্করণ	স্ট্রিং	API-এর সর্বোচ্চ সংস্করণ (major.minor) সমর্থিত, বর্তমানে 1.0
নাম	স্ট্রিং	ডিভাইসটির মানুষের পঠনযোগ্য নাম।	ty
বর্ণনা	স্ট্রিং	(ঐচ্ছিক) ডিভাইসের বিবরণ। ব্যবহারকারী দ্বারা পরিবর্তনযোগ্য হওয়া উচিত।	বিঃদ্রঃ
url	স্ট্রিং	এই ডিভাইসটি যে সার্ভারের সাথে কথা বলছে তার URL৷ ইউআরএলে অবশ্যই প্রোটোকল স্পেসিফিকেশন থাকতে হবে, যেমন: https://www.google.com/cloudprint।	url
প্রকার	স্ট্রিং তালিকা	সমর্থিত ডিভাইস প্রকারের তালিকা।	প্রকার
আইডি	স্ট্রিং	ডিভাইস আইডি, খালি যদি ডিভাইস এখনও নিবন্ধিত না হয়.	আইডি
device_state	স্ট্রিং	ডিভাইসের অবস্থা। নিষ্ক্রিয় মানে ডিভাইস প্রস্তুত প্রক্রিয়াকরণ মানে ডিভাইস ব্যস্ত এবং কার্যকারিতা কিছু সময়ের জন্য সীমিত হতে পারে থামানো মানে ডিভাইস কাজ করছে না এবং ব্যবহারকারীর হস্তক্ষেপ প্রয়োজন
সংযোগ_স্থিতি	স্ট্রিং	সার্ভারের সাথে সংযোগের অবস্থা (base_url) অনলাইন - সংযোগ উপলব্ধ অফলাইন - কোন সংযোগ নেই সংযোগ করা - স্টার্টআপ পদক্ষেপগুলি সম্পাদন করা কনফিগার করা হয়নি - সংযোগ এখনও কনফিগার করা হয়নি একটি নিবন্ধিত ডিভাইস বিজ্ঞপ্তি চ্যানেলের অবস্থার (যেমন XMPP সংযোগ অবস্থা) উপর ভিত্তি করে তার সংযোগের অবস্থা রিপোর্ট করতে পারে।	cs
প্রস্তুতকারক	স্ট্রিং	ডিভাইস প্রস্তুতকারকের নাম
মডেল	স্ট্রিং	ডিভাইসের মডেল
ক্রমিক সংখ্যা	স্ট্রিং	অনন্য ডিভাইস শনাক্তকারী। এই বৈশিষ্ট্যে, এটি অবশ্যই একটি UUID হতে হবে। (GCP 1.1 বিশেষত্ব) (ঐচ্ছিক) আমরা দৃঢ়ভাবে সব জায়গায় একই সিরিয়াল নম্বর আইডি ব্যবহার করার পরামর্শ দিই, যাতে বিভিন্ন ক্লায়েন্ট একই ডিভাইস সনাক্ত করতে পারে। উদাহরণস্বরূপ, আইপিপি বাস্তবায়নকারী প্রিন্টাররা "প্রিন্টার-ডিভাইস-আইডি" ক্ষেত্রে এই সিরিয়াল নম্বর আইডি ব্যবহার করতে পারে।
ফার্মওয়্যার	স্ট্রিং	ডিভাইস ফার্মওয়্যার সংস্করণ
আপটাইম	int	ডিভাইস বুট থেকে সেকেন্ডের সংখ্যা।
সেটআপ_ইউআরএল	স্ট্রিং	(ঐচ্ছিক) সেটআপ নির্দেশাবলী সহ পৃষ্ঠার URL (প্রটোকল সহ)
support_url	স্ট্রিং	(ঐচ্ছিক) সমর্থন সহ পৃষ্ঠার URL (প্রটোকল সহ), প্রায়শই জিজ্ঞাসা করা প্রশ্নাবলী তথ্য
আপডেট_ইউআরএল	স্ট্রিং	(ঐচ্ছিক) আপডেট ফার্মওয়্যার নির্দেশাবলী সহ পৃষ্ঠার URL (প্রটোকল সহ)
x-privet-টোকেন	স্ট্রিং	X-Privet-Token হেডারের মান যা XSSI এবং XSRF আক্রমণ প্রতিরোধ করার জন্য সমস্ত API-তে পাস করতে হবে। দেখুন 6.1। বিস্তারিত জানার জন্য.
এপিআই	API-এর বিবরণ	সমর্থিত API-এর তালিকা (নীচে বর্ণিত)
শব্দার্থিক_রাষ্ট্র	JSON	(ঐচ্ছিক) CloudDeviceState ফর্ম্যাটে ডিভাইসের শব্দার্থিক অবস্থা।

api - স্থানীয় নেটওয়ার্কের মাধ্যমে উপলব্ধ API-এর তালিকা ধারণকারী একটি JSON তালিকা। মনে রাখবেন যে স্থানীয় নেটওয়ার্কে একই সময়ে সমস্ত API উপলব্ধ নাও হতে পারে৷ উদাহরণস্বরূপ, একটি নতুন সংযুক্ত ডিভাইস শুধুমাত্র /register api সমর্থন করবে:

"api": [
        "/privet/register",
]

একবার ডিভাইস রেজিস্ট্রেশন সম্পূর্ণ হলে, ডিভাইসটিকে /register API সমর্থন করা বন্ধ করতে হবে। স্থানীয় নেটওয়ার্কে কী কী API প্রকাশ করা যেতে পারে তা সরবরাহ করার জন্য ডিভাইসটির পরিষেবাটিও পরীক্ষা করা উচিত। যেমন:

"api": [
        "/privet/accesstoken",
        "/privet/capabilities",
        "/privet/printer/submitdoc",
]

নিম্নলিখিত APIগুলি এই সময়ে উপলব্ধ:

/privet/register - স্থানীয় নেটওয়ার্কে ডিভাইস নিবন্ধনের জন্য API। (বিশদ বিবরণের জন্য /privet/register API দেখুন)। ডিভাইসটি সফলভাবে ক্লাউডে নিবন্ধিত হওয়ার পরে এই APIটি অবশ্যই লুকানো উচিত৷
/privet/accesstoken - ডিভাইস থেকে অ্যাক্সেস টোকেন অনুরোধ করার জন্য API (বিশদ বিবরণের জন্য /privet/accesstoken API দেখুন)।
/privet/ক্ষমতা - ডিভাইসের ক্ষমতা পুনরুদ্ধার করতে API (বিশদ বিবরণের জন্য /privet/ক্ষমতা API দেখুন)।
/privet/printer/* - "প্রিন্টার" ডিভাইসের জন্য নির্দিষ্ট API, বিস্তারিত জানার জন্য প্রিন্টার নির্দিষ্ট API দেখুন।

এখানে /privet/info প্রতিক্রিয়ার একটি উদাহরণ। (/privet/register API-এর অভাব লক্ষ্য করুন, যেহেতু এটি ইতিমধ্যেই নিবন্ধিত ডিভাইস):

{
        "version": "1.0",
        "name": "Gene’s printer",
        "description": "Printer connected through Chrome connector",
        "url": "https://www.google.com/cloudprint",
        "type": [
                "printer"
        ],
        "id": "11111111-2222-3333-4444-555555555555",
        "device_state": "idle",
        "connection_state": "online",
        "manufacturer": "Google",
        "model": "Google Chrome",
        "serial_number": "1111-22222-33333-4444",
        "firmware": "24.0.1312.52",
        "uptime": 600,
        "setup_url": "http://support.google.com/cloudprint/answer/1686197/?hl=en",
        "support_url": "http://support.google.com/cloudprint/?hl=en",
        "update_url": "http://support.google.com/cloudprint/?hl=en",
        "x-privet-token": "AIp06DjQd80yMoGYuGmT_VDAApuBZbInsQ:1358377509659",
        "api": [
                "/privet/accesstoken",
                "/privet/capabilities",
                "/privet/printer/submitdoc",
        ]
}

এখানে একটি প্রিন্টারের জন্য /privet/info প্রতিক্রিয়ার একটি উদাহরণ যা কালি ফুরিয়ে গেছে (বিজ্ঞপ্তি শব্দার্থিক_রাষ্ট্র ক্ষেত্র):

{
        "version": "1.0",
        "name": "Gene’s printer",
        "description": "Printer connected through Chrome connector",
        "url": "https://www.google.com/cloudprint",
        "type": [
                "printer"
        ],
        "id": "11111111-2222-3333-4444-555555555555",
        "device_state": "stopped",
        "connection_state": "online",
        "manufacturer": "Google",
        "model": "Google Chrome",
        "serial_number": "1111-22222-33333-4444",
        "firmware": "24.0.1312.52",
        "uptime": 600,
        "setup_url": "http://support.google.com/cloudprint/answer/1686197/?hl=en",
        "support_url": "http://support.google.com/cloudprint/?hl=en",
        "update_url": "http://support.google.com/cloudprint/?hl=en",
        "x-privet-token": "AIp06DjQd80yMoGYuGmT_VDAApuBZbInsQ:1358377509659",
        "api": [
                "/privet/accesstoken",
                "/privet/capabilities",
                "/privet/printer/submitdoc",
        ],
        "semantic_state": {
                "version": "1.0",
                "printer": {
                        "state": "STOPPED",
                        "marker_state": {
                                "item": [
                                        {
                                                "vendor_id": "ink",
                                                "state": "EXHAUSTED",
                                                "level_percent": 0
                                        }
                                ]
                        }
                }
        }
}

4.2.3। ত্রুটি

X-Privet-Token হেডার অনুপস্থিত থাকলে /privet/info API শুধুমাত্র একটি ত্রুটি ফেরত দেবে। এটি HTTP 400 ত্রুটি হতে হবে:

HTTP/1.1 400 Missing X-Privet-Token header.

4.3। /privet/রেজিস্টার API

/privet/register API ঐচ্ছিক। এটি একটি HTTP POST অনুরোধ। /privet/register API অবশ্যই একটি বৈধ X-Privet-টোকেন হেডারের জন্য পরীক্ষা করতে হবে। ডিভাইসটিকে অবশ্যই "/privet/register" url-এ এই API প্রয়োগ করতে হবে:

POST /privet/register?action=start&user=user@domain.com HTTP/1.1
POST /privet/register?action=complete&user=user@domain.com HTTP/1.1

ডিভাইসটিকে /privet/register API প্রকাশ করা উচিত যখন এটি এই মুহূর্তে বেনামী নিবন্ধনের অনুমতি দেয়। উদাহরণ স্বরূপ:

যখন ডিভাইসটি চালু করা হয় (অথবা ডিভাইসে একটি বিশেষ বোতামে ক্লিক করার পরে) এবং এখনও নিবন্ধন করা হয়নি, তখন স্থানীয় নেটওয়ার্ক থেকে একজন ব্যবহারকারীকে প্রিন্টার দাবি করার অনুমতি দেওয়ার জন্য এটি /privet/register API প্রকাশ করবে৷
রেজিস্ট্রেশন সম্পূর্ণ হওয়ার পর, ডিভাইসটিকে স্থানীয় নেটওয়ার্কে অন্য ব্যবহারকারীকে ডিভাইসটি পুনঃ দাবি করা থেকে আটকাতে /privet/register API প্রকাশ করা বন্ধ করতে হবে।
কিছু ডিভাইসে ডিভাইস নিবন্ধন করার বিভিন্ন উপায় থাকতে পারে এবং /privet/register API (উদাহরণস্বরূপ, Chrome ক্লাউড প্রিন্ট সংযোগকারী) প্রকাশ করা উচিত নয়।

নিবন্ধন প্রক্রিয়াটি 3টি ধাপ নিয়ে গঠিত (ক্লাউড প্রিন্টের জন্য বেনামী নিবন্ধন দেখুন)।

বেনামী নিবন্ধন প্রক্রিয়া শুরু করুন.
একজন ক্লায়েন্ট /privet/register API কল করে এই প্রক্রিয়াটি শুরু করে। ডিভাইসটি সেই সময়ে ব্যবহারকারীর নিশ্চিতকরণের জন্য অপেক্ষা করতে পারে।
দাবি টোকেন পান.

ডিভাইসটি কখন চালিয়ে যাওয়ার জন্য প্রস্তুত তা জানতে ক্লায়েন্ট পোল করে। একবার ডিভাইসটি প্রস্তুত হলে, এটি সার্ভারের কাছে নিবন্ধন টোকেন এবং নিবন্ধন URL পুনরুদ্ধার করার জন্য একটি অনুরোধ পাঠায়। প্রাপ্ত টোকেন এবং URL ক্লায়েন্টকে ফেরত দিতে হবে। এই ধাপে, ডিভাইসটি যদি রেজিস্ট্রেশন শুরু করার জন্য আরেকটি কল পায়, তাহলে এটি করা উচিত:

যদি এটি একই ব্যবহারকারী হন যিনি নিবন্ধন শুরু করেছেন - সমস্ত পূর্ববর্তী ডেটা (যদি থাকে) ফেলে দিন এবং একটি নতুন নিবন্ধন প্রক্রিয়া শুরু করুন৷
যদি এটি ভিন্ন ব্যবহারকারী হয় - ডিভাইস_ব্যস্ত ত্রুটি এবং 30 সেকেন্ডের টাইমআউট ফেরত দিন।

সম্পূর্ণ রেজিস্ট্রেশন প্রক্রিয়া।

ক্লায়েন্ট ডিভাইসটি দাবি করার পরে, ক্লায়েন্টকে রেজিস্ট্রেশন সম্পূর্ণ করার জন্য ডিভাইসটিকে অবহিত করা উচিত। রেজিস্ট্রেশন প্রক্রিয়া সম্পূর্ণ হলে, ডিভাইসটিকে নতুন অর্জিত ডিভাইস আইডি সহ একটি আপডেট ঘোষণা পাঠাতে হবে।

দ্রষ্টব্য: যখন ডিভাইসটি একটি /privet/register API কল প্রক্রিয়া করছে, তখন অন্য কোন /privet/register API কল একই সাথে প্রক্রিয়া করা যাবে না। ডিভাইসটি অবশ্যই ডিভাইস_ব্যস্ত ত্রুটি এবং 30 সেকেন্ডের টাইমআউট ফেরত দেবে।

ডিভাইসে নিবন্ধনের জন্য ব্যবহারকারী নিশ্চিতকরণ অত্যন্ত সুপারিশ করা হয়. বাস্তবায়িত হলে, ডিভাইসটিকে /privet/register?action=start API কল পাওয়ার পর ব্যবহারকারীর নিশ্চিতকরণের জন্য অপেক্ষা করতে হবে। ক্লায়েন্ট /privet/register?action=getClaimToken API-এ কল করবে কখন ব্যবহারকারীর নিশ্চিতকরণ সম্পূর্ণ হয়েছে এবং টোকেন পাওয়া যাবে তা জানতে। যদি ব্যবহারকারী ডিভাইসে নিবন্ধন বাতিল করে (যেমন বাতিল বোতাম টিপুন), user_cancel ত্রুটি অবশ্যই ফেরত দিতে হবে। ব্যবহারকারী একটি নির্দিষ্ট সময়সীমার মধ্যে নিবন্ধন নিশ্চিত না করলে, নিশ্চিতকরণ_টাইমআউট ত্রুটিটি অবশ্যই ফেরত দিতে হবে। আরো বিস্তারিত জানার জন্য ডিফল্ট বিভাগ দেখুন.

4.3.1। ইনপুট

/privet/register API-এর নিম্নলিখিত ইনপুট পরামিতি রয়েছে:

নাম	মান
কর্ম	নিম্নলিখিতগুলির মধ্যে একটি হতে পারে: শুরু - নিবন্ধন প্রক্রিয়া শুরু করতে getClaimToken - ডিভাইসের জন্য দাবি টোকেন পুনরুদ্ধার করুন বাতিল - নিবন্ধন প্রক্রিয়া বাতিল করতে সম্পূর্ণ - নিবন্ধন প্রক্রিয়া সম্পূর্ণ করতে
ব্যবহারকারী	এই ডিভাইসটি দাবি করবে এমন ব্যবহারকারীর ইমেল।

নাম

মান

কর্ম

নিম্নলিখিতগুলির মধ্যে একটি হতে পারে:
শুরু - নিবন্ধন প্রক্রিয়া শুরু করতে
getClaimToken - ডিভাইসের জন্য দাবি টোকেন পুনরুদ্ধার করুন
বাতিল - নিবন্ধন প্রক্রিয়া বাতিল করতে
সম্পূর্ণ - নিবন্ধন প্রক্রিয়া সম্পূর্ণ করতে

ব্যবহারকারী

এই ডিভাইসটি দাবি করবে এমন ব্যবহারকারীর ইমেল।

ডিভাইসটিকে অবশ্যই পরীক্ষা করতে হবে যে সমস্ত অ্যাকশনের ইমেল ঠিকানা (শুরু, getClaimToken, বাতিল, সম্পূর্ণ) মেলে।

4.3.2। প্রত্যাবর্তন

/privet/register API নিম্নলিখিত ডেটা প্রদান করে:

মান নাম	মান প্রকার	বর্ণনা
কর্ম	স্ট্রিং	ইনপুট পরামিতি হিসাবে একই কর্ম।
ব্যবহারকারী	স্ট্রিং (ঐচ্ছিক)	ইনপুট প্যারামিটারের মতো একই ব্যবহারকারী (ইনপুটে বাদ দিলে অনুপস্থিত হতে পারে)।
টোকেন	স্ট্রিং (ঐচ্ছিক)	রেজিস্ট্রেশন টোকেন ("getClaimToken" প্রতিক্রিয়ার জন্য বাধ্যতামূলক, "শুরু", "সম্পূর্ণ", "বাতিল" এর জন্য বাদ দেওয়া হয়েছে)।
claim_url	স্ট্রিং (ঐচ্ছিক)	রেজিস্ট্রেশন URL ("getClaimToken" প্রতিক্রিয়ার জন্য বাধ্যতামূলক, "শুরু", "সম্পূর্ণ", "বাতিল" এর জন্য বাদ দেওয়া হয়েছে)। ক্লাউড প্রিন্টারের জন্য এটি অবশ্যই সার্ভার থেকে প্রাপ্ত "complete_invite_url" হতে হবে।
স্বয়ংক্রিয়_দাবি_ইউআরএল	স্ট্রিং (ঐচ্ছিক)	রেজিস্ট্রেশন URL ("getClaimToken" প্রতিক্রিয়ার জন্য বাধ্যতামূলক, "শুরু", "সম্পূর্ণ", "বাতিল" এর জন্য বাদ দেওয়া হয়েছে)। ক্লাউড প্রিন্টারের জন্য এটি অবশ্যই সার্ভার থেকে প্রাপ্ত "স্বয়ংক্রিয়_আমন্ত্রণ_ইউআরএল" হতে হবে।
device_id	স্ট্রিং (ঐচ্ছিক)	নতুন ডিভাইস আইডি ("শুরু" প্রতিক্রিয়ার জন্য বাদ দেওয়া হয়েছে, "সম্পূর্ণ" এর জন্য বাধ্যতামূলক)।

রেজিস্ট্রেশন সম্পূর্ণ হলেই ডিভাইসটিকে অবশ্যই /privet/info API প্রতিক্রিয়াতে তার ডিভাইস আইডি ফেরত দিতে হবে।

উদাহরণ 1:

{
        "action": "start",
        "user": "user@domain.com",
}

উদাহরণ 2:

{
        "action": "getClaimToken",
        "user": "user@domain.com",
        "token": "AAA111222333444555666777",
        "claim_url": "https://domain.com/SoMeUrL",
}

উদাহরণ 3:

{
        "action": "complete",
        "user": "user@domain.com",
        "device_id": "11111111-2222-3333-4444-555555555555",
}

4.3.3। ত্রুটি

/privet/register API নিম্নলিখিত ত্রুটিগুলি ফিরিয়ে দিতে পারে (বিশদ বিবরণের জন্য ত্রুটি বিভাগ দেখুন):

ত্রুটি	বর্ণনা
ডিভাইস_ব্যস্ত	ডিভাইসটি ব্যস্ত এবং অনুরোধ করা ক্রিয়া সম্পাদন করতে পারে না৷ সময় শেষ হওয়ার পরে আবার চেষ্টা করুন।
মুলতুবি_ব্যবহারকারী_ক্রিয়া	"getClaimToken" এর প্রতিক্রিয়াতে এই ত্রুটিটি নির্দেশ করে যে ডিভাইসটি এখনও ব্যবহারকারীর নিশ্চিতকরণের অপেক্ষায় রয়েছে এবং "getClaimToken" অনুরোধটি সময় শেষ হওয়ার পরে পুনরায় চেষ্টা করা উচিত।
user_cancel	ব্যবহারকারী স্পষ্টভাবে ডিভাইস থেকে নিবন্ধীকরণ প্রক্রিয়া বাতিল.
নিশ্চিতকরণ_সময় শেষ	ব্যবহারকারী নিশ্চিতকরণ সময় শেষ.
অবৈধ_ক্রিয়া	অবৈধ কর্ম বলা হয়. উদাহরণস্বরূপ, যদি ক্লায়েন্ট কল করার আগে action=complete কল করে action=start এবং action=getClaimToken।
invalid_params	অনুরোধে উল্লেখিত অবৈধ প্যারামিটার। (ভবিষ্যত সামঞ্জস্যের জন্য অজানা প্যারামিটার নিরাপদে উপেক্ষা করা উচিত)। উদাহরণস্বরূপ, যদি ক্লায়েন্ট অ্যাকশন=অজানা বা ব্যবহারকারী= বলে ডাকে তাহলে এটি ফেরত দিন।
device_config_error	তারিখ/সময় (বা অন্য কিছু সেটিংস) ডিভাইসের দিকে ভুল। ব্যবহারকারীকে (ডিভাইসের অভ্যন্তরীণ ওয়েবসাইটে) যেতে হবে এবং ডিভাইস সেটিংস কনফিগার করতে হবে।
অফলাইন	ডিভাইসটি বর্তমানে অফলাইনে রয়েছে এবং সার্ভারের সাথে কথা বলতে পারে না৷
সার্ভার সমস্যা	নিবন্ধন প্রক্রিয়া চলাকালীন সার্ভার ত্রুটি.
invalid_x_privet_token	এক্স-প্রাইভেট-টোকেন অনুরোধে অবৈধ বা খালি।

রেজিস্ট্রেশন সফলভাবে সম্পন্ন হওয়ার পর ডিভাইসটিকে অবশ্যই /privet/register API প্রকাশ করা বন্ধ করতে হবে। ডিভাইসটি /privet/register API প্রকাশ না করলে, এটি অবশ্যই HTTP 404 ত্রুটি ফেরত দেবে। অতএব, যদি একটি ডিভাইস ইতিমধ্যেই নিবন্ধিত থাকে, তাহলে এই API কল করলে অবশ্যই 404 ফেরত দিতে হবে। যদি X-Privet-Token হেডারটি অনুপস্থিত থাকে, তাহলে ডিভাইসটিকে HTTP 400 ত্রুটি ফেরাতে হবে।

4.4। /privet/accesstoken API

/privet/accesstoken API ঐচ্ছিক। এটি একটি HTTP GET অনুরোধ। /privet/accesstoken API একটি বৈধ "X-Privet-Token" শিরোনাম পরীক্ষা করতে হবে। ডিভাইসটিকে অবশ্যই "/privet/accesstoken" url-এ এই API প্রয়োগ করতে হবে:

GET /privet/accesstoken HTTP/1.1

ডিভাইসটি যখন /accesstoken API কলটি গ্রহণ করে, তখন প্রদত্ত ব্যবহারকারীর জন্য অ্যাক্সেস টোকেন পুনরুদ্ধার করতে এবং ক্লায়েন্টকে টোকেন ফেরত দিতে সার্ভারকে কল করা উচিত। ক্লায়েন্ট তখন ক্লাউডের মাধ্যমে এই ডিভাইসটি অ্যাক্সেস করতে অ্যাক্সেস টোকেন ব্যবহার করবে।

ক্লাউড প্রিন্ট ডিভাইসগুলিকে অবশ্যই নিম্নলিখিত API কল করতে হবে:

/cloudprint/proximitytoken

এবং স্থানীয় API থেকে "printerid=<printer_id>" এবং "ব্যবহারকারী" প্যারামিটার পাস করুন। সফল হলে, সার্ভারের প্রতিক্রিয়াতে নিম্নলিখিত অবজেক্ট থাকবে:

"proximity_token": {
        "user": "user@domain.com",
        "token": "AAA111222333444555666777",
        "expires_in": 600
}

ক্লাউড প্রিন্ট ডিভাইসগুলিকে স্থানীয় /privet/accesstoken API কলগুলির প্রতিক্রিয়াতে "proximity_token" অবজেক্টের মান পাস করতে হবে। এটি আরও সুবিধাজনক (ভবিষ্যত-প্রমাণ) যদি ডিভাইসটি সমস্ত পরামিতি পাস করতে পারে (এই বৈশিষ্ট্যে বর্ণিত নয় এমনগুলি সহ)।

4.4.1। ইনপুট

/privet/accesstoken API-এর নিম্নলিখিত ইনপুট পরামিতি রয়েছে:

নাম	মান
ব্যবহারকারী	এই অ্যাক্সেস টোকেনটি ব্যবহার করতে চান এমন ব্যবহারকারীর ইমেল৷ অনুরোধে খালি হতে পারে।

4.4.2। প্রত্যাবর্তন

/privet/accesstoken API নিম্নলিখিত ডেটা প্রদান করে:

মান নাম	মান প্রকার	বর্ণনা
টোকেন	স্ট্রিং	সার্ভার দ্বারা ফেরত অ্যাক্সেস টোকেন
ব্যবহারকারী	স্ট্রিং	ইনপুট প্যারামিটারের মতো একই ব্যবহারকারী।
মেয়াদ শেষ	int	এই টোকেনের মেয়াদ শেষ না হওয়া পর্যন্ত সেকেন্ডের সংখ্যা। সার্ভার থেকে প্রাপ্ত এবং এই প্রতিক্রিয়া পাস.

উদাহরণ:

{
        "token": "AAA111222333444555666777",
        "user": "user@domain.com",
        "expires_in": 600
}

4.4.3। ত্রুটি

/privet/accesstoken API নিম্নলিখিত ত্রুটিগুলি ফিরিয়ে দিতে পারে (বিশদ বিবরণের জন্য ত্রুটি বিভাগ দেখুন):

ত্রুটি	বর্ণনা
অফলাইন	ডিভাইসটি বর্তমানে অফলাইনে রয়েছে এবং সার্ভারের সাথে কথা বলতে পারে না৷
অ্যাক্সেস_অস্বীকৃত	অপর্যাপ্ত অধিকার। অ্যাক্সেস অস্বীকার করা হয়েছে৷ সার্ভার দ্বারা অনুরোধটি স্পষ্টভাবে অস্বীকার করা হলে ডিভাইসটিকে এই ত্রুটিটি ফেরত দেওয়া উচিত৷
invalid_params	অনুরোধে উল্লেখিত অবৈধ প্যারামিটার। (ভবিষ্যত সামঞ্জস্যের জন্য অজানা প্যারামিটার নিরাপদে উপেক্ষা করা উচিত)। উদাহরণস্বরূপ, যদি ক্লায়েন্ট /accesstoken?user= অথবা /accesstoken কল করে।
সার্ভার সমস্যা	সার্ভার সমস্যা.
invalid_x_privet_token	এক্স-প্রাইভেট-টোকেন অনুরোধে অবৈধ বা খালি।

ডিভাইসটি /privet/accesstoken API প্রকাশ না করলে, এটি অবশ্যই HTTP 404 ত্রুটি ফেরত দেবে। যদি X-Privet-Token হেডারটি অনুপস্থিত থাকে, তাহলে ডিভাইসটিকে HTTP 400 ত্রুটি ফেরাতে হবে।

4.5। /privet/ক্ষমতা API

/privet/ক্ষমতা API ঐচ্ছিক। এটি একটি HTTP GET অনুরোধ। /privet/capabilities API একটি বৈধ "X-Privet-Token" শিরোনাম পরীক্ষা করতে হবে। ডিভাইসটিকে অবশ্যই "/privet/capabilities" url-এ এই API প্রয়োগ করতে হবে:

GET /privet/capabilities HTTP/1.1

যখন ডিভাইসটি /capabilities API কল গ্রহণ করে, ডিভাইসটি সক্ষম হলে, আপডেট করা ক্ষমতা পেতে সার্ভারের সাথে যোগাযোগ করা উচিত। উদাহরণস্বরূপ, যদি একটি প্রিন্টার ক্লাউড প্রিন্ট পরিষেবার মাধ্যমে একটি প্রিন্ট জব (স্থানীয়ভাবে প্রাপ্ত) পোস্ট করা সমর্থন করে, তাহলে ক্লাউড প্রিন্ট পরিষেবাটি ফিরে আসবে এমন ক্ষমতাগুলি ফিরিয়ে দেওয়া উচিত৷ এই ক্ষেত্রে ক্লাউড প্রিন্ট প্রিন্টারে কাজ পাঠানোর আগে নতুন বৈশিষ্ট্যগুলি যোগ করে মূল প্রিন্টারের ক্ষমতাগুলিকে পরিবর্তন করতে পারে। সর্বাধিক সাধারণ ক্ষেত্রে সমর্থিত নথি প্রকারের একটি তালিকা। যদি প্রিন্টারটি অফলাইনে থাকে, তবে এটি সমর্থন করে এমন নথির ধরনগুলি ফিরিয়ে দেওয়া উচিত৷ যাইহোক, যদি প্রিন্টারটি অনলাইনে থাকে এবং ক্লাউড প্রিন্টের সাথে নিবন্ধিত হয় তবে এটি অবশ্যই সমর্থিত প্রকারগুলির একটি হিসাবে "*/*" ফেরত দেবে৷ ক্লাউড প্রিন্ট পরিষেবা এই ক্ষেত্রে প্রয়োজনীয় রূপান্তর সম্পাদন করবে৷ অফলাইন প্রিন্টিংয়ের জন্য, প্রিন্টারকে অবশ্যই অন্তত "image/pwg-raster" ফরম্যাট সমর্থন করতে হবে।

4.5.1। ইনপুট

/privet/capabilities API-এর নিম্নলিখিত ইনপুট পরামিতি রয়েছে:

নাম	মান
অফলাইন	(ঐচ্ছিক) শুধুমাত্র "অফলাইন=1" হতে পারে। এই ক্ষেত্রে ডিভাইসটিকে অফলাইন ব্যবহারের জন্য ক্ষমতা ফিরিয়ে দেওয়া উচিত (যদি সেগুলি "অনলাইন" ক্ষমতা থেকে আলাদা হয়)।

নাম

মান

অফলাইন

(ঐচ্ছিক) শুধুমাত্র "অফলাইন=1" হতে পারে। এই ক্ষেত্রে ডিভাইসটিকে অফলাইন ব্যবহারের জন্য ক্ষমতা ফিরিয়ে দেওয়া উচিত (যদি সেগুলি "অনলাইন" ক্ষমতা থেকে আলাদা হয়)।

4.5.2। প্রত্যাবর্তন

/privet/capabilities API ক্লাউড ডিভাইস বর্ণনা (CDD) JSON ফর্ম্যাটে ডিভাইসের ক্ষমতা প্রদান করে (বিশদ বিবরণের জন্য CDD নথি দেখুন)। ন্যূনতম প্রিন্টারদের এখানে সমর্থিত প্রকারের একটি তালিকা ফেরত দিতে হবে। উদাহরণস্বরূপ, একটি ক্লাউড রেডি প্রিন্টার যা বর্তমানে অনলাইনে রয়েছে তা এইরকম কিছু (সর্বনিম্নভাবে) ফেরত দিতে পারে:

{
        "version": "1.0",
        "printer": {
                "supported_content_type": [
                        {
                                "content_type": "application/pdf",
                                "min_version": "1.4"
                        },
                        { "content_type": "image/pwg-raster" },
                        { "content_type": "image/jpeg" },
                        { "content_type": "*/*" }
                ]
        }
}

এবং যখন এটি সার্ভার থেকে সংযোগ বিচ্ছিন্ন হয়, তখন এটি ফিরে আসতে পারে:

{
        "version": "1.0",
        "printer": {
                "supported_content_type": [
                        {
                                "content_type": "application/pdf",
                                "min_version": "1.4"
                        },
                        { "content_type": "image/pwg-raster" },
                        { "content_type": "image/jpeg" }
                ]
        }
}

দ্রষ্টব্য : প্রিন্টারগুলি অর্ডার ব্যবহার করে সমর্থিত বিষয়বস্তুর প্রকারের অগ্রাধিকার প্রকাশ করে। উদাহরণস্বরূপ, উপরের নমুনাগুলিতে, প্রিন্টারটি নির্দিষ্ট করে যে এটি "ইমেজ/পিডব্লিউজি-রাস্টার" এবং "ইমেজ/জেপিইজি" এর চেয়ে "অ্যাপ্লিকেশন/পিডিএফ" ডেটা পছন্দ করে। যদি সম্ভব হয় ক্লায়েন্টদের প্রিন্টার অগ্রাধিকারকে সম্মান করা উচিত (বিশদ বিবরণের জন্য CDD নথি দেখুন)।

4.5.3। ত্রুটি

/privet/capabilities API নিম্নলিখিত ত্রুটিগুলি ফিরিয়ে দিতে পারে (বিশদ বিবরণের জন্য ত্রুটি বিভাগ দেখুন):

ত্রুটি	বর্ণনা
invalid_x_privet_token	এক্স-প্রাইভেট-টোকেন অনুরোধে অবৈধ বা খালি।

ডিভাইসটি /privet/capabilities API প্রকাশ না করলে, এটি অবশ্যই HTTP 404 ত্রুটি ফেরত দেবে। যদি X-Privet-Token হেডারটি অনুপস্থিত থাকে, তাহলে ডিভাইসটিকে HTTP 400 ত্রুটি ফেরাতে হবে।

4.6। ত্রুটি

উপরের API গুলি থেকে নিম্নলিখিত বিন্যাসে ত্রুটিগুলি ফেরত দেওয়া হয়েছে:

মান নাম	মান প্রকার	বর্ণনা
ত্রুটি	স্ট্রিং	ত্রুটির ধরন (এপিআই প্রতি সংজ্ঞায়িত)
বর্ণনা	স্ট্রিং (ঐচ্ছিক)	ত্রুটির মানব পাঠযোগ্য বর্ণনা।
সার্ভার_এপিআই	স্ট্রিং (ঐচ্ছিক)	সার্ভার ত্রুটির ক্ষেত্রে, এই ক্ষেত্রটিতে সার্ভার API রয়েছে যা ব্যর্থ হয়েছে।
সার্ভার_কোড	int (ঐচ্ছিক)	সার্ভার ত্রুটির ক্ষেত্রে, এই ক্ষেত্রটিতে সেই ত্রুটি কোড রয়েছে যা সার্ভারটি ফেরত দিয়েছে।
সার্ভার_http_code	int (ঐচ্ছিক)	সার্ভার HTTP ত্রুটির ক্ষেত্রে, এই ক্ষেত্রটিতে HTTP ত্রুটি কোড সার্ভার ফেরত রয়েছে।
সময় শেষ	int (ঐচ্ছিক)	পুনরায় চেষ্টা করার আগে ক্লায়েন্টের অপেক্ষা করার জন্য সেকেন্ডের সংখ্যা (শুধুমাত্র পুনরুদ্ধারযোগ্য ত্রুটির জন্য)। ক্লায়েন্টকে এই মান থেকে প্রকৃত টাইমআউটকে র্যান্ডমাইজ করতে হবে + 20%।

X-Privet-Token হেডার অনুপস্থিত থাকলে সমস্ত API-কে HTTP 400 ত্রুটি ফেরত দিতে হবে।

HTTP/1.1 400 অনুপস্থিত X-Privet-টোকেন হেডার।

উদাহরণ 1:

{
        "error": "server_error",
        "description": "Service unavailable",
        "server_api": "/submit",
        "server_http_code": 503
}

উদাহরণ 2:

{
        "error": "printer_busy",
        "description": "Printer is currently printing other job",
        "timeout": 15
}

5. প্রিন্টার API

এই প্রোটোকল সমর্থন করে এমন একটি ডিভাইসের ধরন হল টাইপ প্রিন্টার। এই ধরনের সমর্থনকারী ডিভাইসগুলি প্রিন্টারগুলির জন্য নির্দিষ্ট কিছু কার্যকারিতা প্রয়োগ করতে পারে। আদর্শভাবে, ক্লাউড-রেডি প্রিন্টারে মুদ্রণ একটি ক্লাউড প্রিন্ট সার্ভারের মাধ্যমে হবে:

কিছু ক্ষেত্রে একজন ক্লায়েন্টকে স্থানীয়ভাবে একটি নথি পাঠাতে হতে পারে। ক্লায়েন্টের Google ID না থাকলে বা ক্লাউড প্রিন্ট সার্ভারের সাথে কথা বলতে অক্ষম হলে এটির প্রয়োজন হতে পারে। এই ক্ষেত্রে, মুদ্রণ কাজ স্থানীয়ভাবে প্রিন্টারে জমা দেওয়া হবে। প্রিন্টার, পরিবর্তে, কাজের সারিবদ্ধকরণ এবং রূপান্তরের জন্য ক্লাউড প্রিন্ট পরিষেবা ব্যবহার করবে। প্রিন্টার ক্লাউড প্রিন্ট পরিষেবাতে স্থানীয়ভাবে জমা দেওয়া কাজটি পুনরায় পোস্ট করবে এবং তারপরে অনুরোধ করবে, যেহেতু এটি ক্লাউডের মাধ্যমে জমা দেওয়া হয়েছিল। এই প্রক্রিয়াটি পরিষেবা (রূপান্তর) এবং প্রিন্ট জব ম্যানেজমেন্ট/ট্র্যাকিংয়ের ক্ষেত্রে নমনীয় ব্যবহারকারীর অভিজ্ঞতা প্রদান করবে।

যেহেতু ক্লাউড প্রিন্ট পরিষেবা রূপান্তর প্রয়োগ করে, তাই প্রিন্টারকে সমর্থিত সামগ্রী প্রকারের তালিকার মধ্যে সমস্ত ইনপুট ফর্ম্যাট ("*/*") সমর্থন করে বিজ্ঞাপন দেওয়া উচিত:

{
        "version": "1.0",
        "printer": {
                "supported_content_type": [
                        { "content_type": "image/pwg-raster" },
                        { "content_type": "*/*" }
                ]
        }
}

কিছু ক্ষেত্রে একটি সম্পূর্ণ অফলাইন সমাধান কাঙ্ক্ষিত. যেহেতু প্রিন্টারগুলি সীমিত সংখ্যক ইনপুট ফর্ম্যাট সমর্থন করে, তাই একজন ক্লায়েন্টকে নথিগুলিকে কয়েকটি স্থানীয়ভাবে সমর্থিত প্রিন্টার ফর্ম্যাটে রূপান্তর করতে হবে।

অফলাইন প্রিন্টিং কেসের জন্য কমপক্ষে PWG রাস্টার ("image/pwg-raster") বিন্যাস সমর্থন করার জন্য এই বৈশিষ্ট্যটির জন্য সমস্ত প্রিন্টার প্রয়োজন৷ একটি প্রিন্টার অন্যান্য ফরম্যাট (উদাহরণস্বরূপ JPEG) সমর্থন করতে পারে এবং যদি একটি ক্লায়েন্ট এটি সমর্থন করে, তাহলে এটি সেই বিন্যাসে নথি পাঠাতে পারে। প্রিন্টারকে অবশ্যই / সক্ষমতা API এর মাধ্যমে সমর্থিত প্রকারগুলি প্রকাশ করতে হবে, উদাহরণস্বরূপ:

{
        "version": "1.0",
        "printer": {
                "supported_content_type": [
                        { "content_type": "image/pwg-raster" },
                        { "content_type": "image/jpeg" }
                ]
        }
}

একটি ক্লায়েন্ট স্থানীয় নেটওয়ার্কে মুদ্রণ শুরু করতে পারে এমন দুটি উপায় রয়েছে।

সহজ মুদ্রণ - ক্লায়েন্ট স্থানীয় নেটওয়ার্কের মাধ্যমে নথিটি /submitdoc API এ পাঠায় (job_id প্যারামিটার নির্দিষ্ট না করে)। জমা দেওয়া নথিটি ডিফল্ট প্রিন্ট টিকিট সেটিংস ব্যবহার করে প্রিন্ট করা হবে এবং কোনো প্রিন্ট কাজের অবস্থার প্রয়োজন নেই। যদি প্রিন্টার শুধুমাত্র এই ধরনের মুদ্রণ সমর্থন করে, তাহলে এটি অবশ্যই /privet/info API প্রতিক্রিয়াতে শুধুমাত্র /submitdoc API-এর বিজ্ঞাপন দিতে হবে।

"api": [
        "/privet/accesstoken",
        "/privet/capabilities",
        "/privet/printer/submitdoc",
]

অ্যাডভান্সড প্রিন্টিং - ক্লায়েন্টকে প্রথমে অনুরোধে একটি বৈধ CJT চাকরির টিকিট সহ /privet/printer/createjob API এ কল করে প্রিন্টারে একটি প্রিন্ট কাজ তৈরি করতে হবে। প্রিন্টারকে অবশ্যই প্রিন্ট টিকিট মেমরিতে সংরক্ষণ করতে হবে এবং ক্লায়েন্টকে একটি job_id ফেরত দিতে হবে। তারপর ক্লায়েন্ট /printer/submitdoc API এ কল করবে এবং পূর্বে প্রাপ্ত job_id উল্লেখ করবে। সেই সময়ে প্রিন্টারটি মুদ্রণ শুরু করবে। ক্লায়েন্ট /privet/printer/jobstate API এ কল করে প্রিন্ট কাজের অবস্থার জন্য প্রিন্টারকে পোল করবে।

একটি মাল্টি-ক্লায়েন্ট পরিবেশে, এই APIটি কীভাবে বলা হবে তার কোন গ্যারান্টি নেই। একজন ক্লায়েন্টের পক্ষে অন্য ক্লায়েন্টের /createjob->/submitdoc কলগুলির মধ্যে / createjob-কে কল করা সম্ভব। সম্ভাব্য অচলাবস্থা দূর করতে এবং ব্যবহারযোগ্যতা উন্নত করতে, আমরা প্রিন্টারে (অন্তত 3-5টি) মুলতুবি থাকা প্রিন্ট কাজের একটি ছোট সারি রাখার সুপারিশ করেছি:

/createjob সারিতে প্রথম উপলব্ধ স্থান নেয়।
চাকরির জীবনকাল (সারিতে) কমপক্ষে 5 মিনিট।
যদি সারির সমস্ত দাগ নেওয়া হয়, তবে সবচেয়ে পুরানো, অ-মুদ্রণ কাজটি সরিয়ে দেওয়া হবে এবং সেখানে একটি নতুন স্থাপন করা হবে।
If there is a print job currently printing on the device (simple or advanced printing), /submitdoc should return status busy and propose a timeout to retry this print job.
If /submitdoc refers to a job that has been removed from the queue (due to replacement or timeout), the printer should return an error invalid_print_job and the client will retry the process from the /createjob step. The client MUST wait for a random timeout period of up to 5 seconds before retrying.

If memory constraints prevent storing multiple pending jobs on the device, it is possible to have a queue of 1 print job long. It should still follow the same protocol as above. After a job has completed or failed with an error, the printer should store information about the job's status for at least 5 minutes. The queue size for storing completed job statuses should be at least 10. If there are more job statuses that need to be stored, the oldest one may be removed from the queue before the 5 minute timeout.

Note: For now clients will poll for job status. In the future, we may require the printer to send TXT DNS notification when ANY print job status has changed.

5.1. /privet/printer/createjob API

/privet/printer/createjob API is OPTIONAL (see Simple Printing above). It is an HTTP POST request. /privet/printer/createjob API MUST check for a valid "X-Privet-Token" header. The device MUST implement this API on "/privet/printer/createjob" url:

POST /privet/printer/createjob HTTP/1.1

When receiving /privet/printer/createjob API call, the printer MUST create a new print job ID, store the received print ticket in the CJT format, and return print job id back to the client.

5.1.1. Input

/privet/printer/createjob API has no input parameters in URL. The request body should contain the print job ticket data in CJT format.

5.1.2. প্রত্যাবর্তন

/privet/printer/createjob API returns the following data:

Value name	Value type	বর্ণনা
job_id	string	ID of the newly created print job.
expires_in	int	Number of seconds this print job is valid.

Example:

{
        "job_id": "123",
        "expires_in": 600
}

5.1.3. Errors

/privet/printer/createjob API may return the following errors (see Errors section for details):

Error	বর্ণনা
invalid_ticket	Submitted print ticket is invalid.
printer_busy	Printer is busy and can't currently process /createjob. Retry after timeout.
printer_error	Printer is in error state and requires user interaction to fix it. Description should contain more detailed explanation (eg "Paper jam in Tray 1").
invalid_x_privet_token	X-Privet-Token is invalid or empty in the request.

If device is not exposing /privet/printer/createjob it MUST return HTTP 404 error. If X-Privet-Token header is missing, the device MUST return HTTP 400 error.

5.2. /privet/printer/submitdoc API

/privet/printer/submitdoc API is REQUIRED to implement printing over a local network (offline or repost to Cloud Print). It is an HTTP POST request. /privet/printer/submitdoc API MUST check for a valid "X-Privet-Token" header. The device MUST implement this API on "/privet/printer/submitdoc" url:

POST /privet/printer/submitdoc HTTP/1.1

When receiving the /privet/printer/submitdoc API call, the printer should start printing. If it is unable to begin printing, it MUST return the error printer_busy and a recommended timeout period for the client to wait before trying again.

If the printer is not able to hold all of the data in its internal buffer, it SHOULD use TCP mechanisms to slow down data transfer until it prints a portion of the document, making part of the buffer available again. (For example, the printer may set windowsize=0 on TCP layers, which will make the client wait.)

Submitting a document to the printer may take a significant amount of time. The client should be able to check the state of the printer and job (advanced printing) while printing is in progress. In order to do that, the printer MUST allow the client to call the /privet/info and /privet/printer/jobstate APIs while processing /privet/printer/submitdoc API calls. It is recommended for all clients to start a new thread to execute the /privet/printer/submitdoc API call, so that the main thread can use the /privet/info and /privet/printer/jobstate APIs to check printer and job states.

Note : Upon completion or abortion of the local print job, it is strongly recommended (and will be required in a future version of this spec) to report the final state of the job to the /cloudprint/submit interface for accounting and user experience purposes. The parameters "printerid", "title", "contentType" and "final_semantic_state" (in PrintJobState format) are required, and the parameters "tag" (repeated parameter) and "ticket" (the ticket of the job in CloudJobTicket format). Note that the provided PrintJobState must actually be final, ie its type must be DONE or ABORTED, and a cause must be provided in the case that it is ABORTED (see JobState for details). Also note that this use of the /cloudprint/submit interface to report local print jobs is not mentioned in its specification because that section is intended to describe the interface's primary use: submitting a print job with the document to print provided in the "content" parameter.

5.2.1. Input

/privet/printer/submitdoc API has the following input parameters:

নাম	Value
job_id	(optional) Print job id. May be omitted for simple printing case (see above). Must match the one returned by the printer.
user_name	(optional) Human readable user name. This is not definitive, and should only be used for print job annotations. If job is re-posted to the Cloud Print service this string should be attached to the Cloud Print job.
client_name	(optional) Name of the client application making this request. For display purposes only. If job is re-posted to the Cloud Print service this string should be attached to the Cloud Print job.
job_name	(optional) Name of the print job to be recorded. If job is re-posted to the Cloud Print service this string should be attached to the Cloud Print job.
offline	(optional) Could only be "offline=1". In this case printer should only try printing offline (no re-post to Cloud Print server).

Request body should contain a valid document for printing. "Content-Length" should include the correct length of the request. "Content-Type" header should be set to document MIME type and match one of the types in the CDD (unless CDD specifies "*/*").

Clients are HIGHLY recommended to provide a valid user name (or email), a client name and a job name with this request. Those fields are only used in UIs to improve user experience.

5.2.2. প্রত্যাবর্তন

/privet/printer/submitdoc API returns following data:

Value name	Value type	বর্ণনা
job_id	string	ID of the newly created print job (simple printing) or job_id specified in the request (advanced printing).
expires_in	int	Number of seconds this print job is valid.
job_type	string	Content-type of the submitted document.
job_size	int 64 bit	Size of the print data in bytes.
job_name	string	(optional) Same job name as in input (if any).

Example:

{
        "job_id": "123",
        "expires_in": 500,
        "job_type": "application/pdf",
        "job_size": 123456,
        "job_name": "My PDF document"
}

5.2.3. Errors

/privet/printer/submitdoc API may return the following errors (see Errors section for details):

Error	বর্ণনা
invalid_print_job	Invalid/expired job id is specified in the request. Retry after timeout.
invalid_document_type	Document MIME-type is not supported by the printer.
invalid_document	Submitted document is invalid.
document_too_large	Document exceeds maximum size allowed.
printer_busy	Printer is busy and can't currently process document. Retry after timeout.
printer_error	Printer is in error state and requires user interaction to fix it. Description should contain more detailed explanation (eg "Paper jam in Tray 1").
invalid_params	Invalid parameters specified in the request. (Unknown parameters should be safely ignored for future compatibility)
user_cancel	User explicitly cancelled printing process from the device.
server_error	Posting document to Cloud Print has failed.
invalid_x_privet_token	X-Privet-Token is invalid or empty in the request.

If the device is not exposing /privet/printer/submitdoc, it MUST return HTTP 404 error. If the X-Privet-Token header is missing, the device MUST return HTTP 400 error.

Note : /privet/printer/submitdoc API may require special handling on printer side (because of the large payload attached). In some cases (depends on the printer HTTP server implementation and platform), printer may close socket BEFORE returning HTTP error. In other, printer may return 503 error (instead of Privet error). Printers SHOULD try as much as possible to return Privet. However, every client implementing Privet specification SHOULD be able to handle socket close (no HTTP error) and 503 HTTP error cases for /privet/printer/submitdoc API. In this case, client SHOULD handle it as a Privet "printer_busy" error with "timeout" set to 15 seconds. To avoid infinite retries, client may stop retrying after a reasonable number of attempts (for example, 3).

5.3. /privet/printer/jobstate API

/privet/printer/jobstate API is OPTIONAL (see Simple Printing above). It is an HTTP GET request. /privet/printer/jobstate API MUST check for a valid "X-Privet-Token" header. The device MUST implement this API on "/privet/printer/jobstate" url:

GET /privet/printer/jobstate HTTP/1.1

When receiving a /privet/printer/jobstate API call, a printer should return the status of the requested print job or invalid_print_job error.

5.3.1. Input

/privet/printer/jobstate API has following input parameters:

নাম	Value
job_id	Print job ID to return status for.

5.3.2. প্রত্যাবর্তন

/privet/printer/jobstate API returns the following data:

Value name	Value type	বর্ণনা
job_id	string	Print job id there status information is for.
state	string	draft - print job has been created on the device (no /privet/printer/submitdoc calls have been received yet). queued - print job has been received and queued, but printing has not started yet. in_progress - print job is in the progress of printing. stopped - print job has been paused, but can be restarted manually or automatically. done - print job is done. aborted - print job failed.
description	string	(optional) Human readable description of the print job status. Should include additional information if state < is stopped or aborted . The semantic_state field usually provides better and more meaningful description to the client.
expires_in	int	Number of seconds this print job is valid.
job_type	string	(optional) Content-type of the submitted document.
job_size	int 64 bit	(optional) Size of the print data in bytes.
job_name	string	(optional) Same job name as in input (if any).
server_job_id	string	(optional) ID of the job returned from the server (if job has been posted to Cloud Print service). Omitted for offline printing.
semantic_state	JSON	(optional) Semantic state of the job in PrintJobState format.

Example (printing by reporting through Cloud Print):

{
        "job_id": "123",
        "state": "in_progress",
        "expires_in": 100,
        "job_type": "application/pdf",
        "job_size": 123456,
        "job_name": "My PDF document",
        "server_job_id": "1111-2222-3333-4444"
}

Example (offline printing error):

{
        "job_id": "123",
        "state": "stopped",
        "description": "Out of paper",
        "expires_in": 100,
        "job_type": "application/pdf",
        "job_size": 123456,
        "job_name": "My PDF document"
}

Example (print job aborted by the user):

{
        "job_id": "123",
        "state": "aborted",
        "description": "User action",
        "expires_in": 100,
        "job_type": "application/pdf",
        "job_size": 123456,
        "job_name": "My PDF document",
        "semantic_state": {
                "version": "1.0",
                "state": {
                        "type": "ABORTED",
                        "user_action_cause": {"action_code": "CANCELLED"}
                },
                "pages_printed": 7
        }
}

Example (print job stopped due to out of paper). Notice the reference to the device state. The client will need to call the /privet/info API to get more details about the device state:

{
        "job_id": "123",
        "state": "stopped",
        "description": "Out of paper",
        "expires_in": 100,
        "job_type": "application/pdf",
        "job_size": "123456",
        "job_name": "My PDF document",
        "semantic_state": {
                "version": "1.0",
                "state": {
                        "type": "STOPPED",
                        "device_state_cause": {"error_code": "INPUT_TRAY"}
                },
                "pages_printed": 7
        }
}

5.3.3. Errors

/privet/printer/jobstate API may return the following errors (see Errors section for details):

Error	বর্ণনা
invalid_print_job	Invalid/expired job ID is specified in the request.
server_error	Getting print job status (for print jobs posted to Cloud Print) has failed.
invalid_x_privet_token	X-Privet-Token is invalid or empty in the request.

If device is not exposing /privet/printer/jobstate, it MUST return HTTP 404 error. If the X-Privet-Token header is missing, the device MUST return HTTP 400 error.

6. Appendix

6.1. Default behavior and settings

This section will explain the default behavior we expect from ALL Privet-compatible devices.

Out-of-the-box devices should support only /privet/info and /privet/register APIs. All other APIs (eg /privet/accesstoken, local printing) should be disabled.
Registration requires physical interaction with a device.

User MUST take a physical action on the device (eg, pressing a button) to confirm their access to the device.
After the user takes the action noted above, the printer should send the /cloudprint/register request. It should not send this request until after the action is taken (see Sequence Diagram 1).
If the device is processing a /privet/register request (for instance, waiting on the action above), it must reject all other /privet/register requests. The device MUST return the device_busy error in this case.
The device should timeout any /register request that does not receive the physical action mentioned above within 60 seconds. The device MUST return the confirmation_timeout error in this case.
Optional: Recommended but not required, the following may improve user experience:

The printer might flash a light or its screen to indicate that the user needs to take an action to confirm registration.
The printer might state on its screen that 'it is being registered to Google Cloud Print for user ' abc@def.com ' - press OK to continue', where abc@def.com is the user parameter from the /register API call. This would make it clearer to a user that:

it is their registration request that they are confirming
what is happening if s/he didn't trigger the request.

In addition to a physical action to confirm from the printer (eg, 'Press the OK button'), a printer may also offer the user a button to cancel the request (eg, 'Press Cancel to reject'). This would allow users who did not trigger the registration request to cancel it before the 60 second timeout. The device MUST return the user_cancel error in this case.

Ownership transfers:

The device may be deleted explicitly from the Cloud service.

If the device receives success, but no device description as a result of /cloudprint/printer (for GCP) call, it MUST revert to default (out-of-the-box) mode.
If the device's credentials no longer work (explicitly because of "invalid credentials" response from the server), it MUST revert to default (out-of-the-box) mode.

Local factory reset MUST clear device's credentials and set it to default state.
Optional: The device may provide a menu item to clear credentials and put it into default mode.

Devices supporting XMPP notifications MUST include the ability to ping the server. The ping timeout MUST be controllable from the server through "local_settings".
The device may explicitly ping the server (/cloudprint/printer API for GCP, in addition to XMPP pings) no more often than once a day (24 hours) to make sure they are in sync. It is recommended to randomize the check window within 24-32 hour window.
Optional: For Cloud Print devices, it is recommended but not required to have a manual way (button) to allow the user to initiate a check for new print jobs from the device. Some printers already have this.
Optional. Enterprise printers may have an option to disable local discovery completely. In such case, the device MUST update these local settings on the server. New local settings MUST be empty (setting "local_discovery" to "false", means that it can be re-enabled from the GCP Service).

6.1.2 Default Registration Diagram

6.2. XSSI and XSRF attacks and prevention

This section will explain the possibility of XSSI and XSRF attacks on the device and how to protect from them (including token generation techniques).
More details are here: http://googleonlinesecurity.blogspot.com/2011/05/website-security-for-webmasters.html
Normally, XSSI and XSRF attacks are possible when a site is using cookie authentication mechanisms. While Google doesn't use cookies with their Cloud Print Service, such attacks are still possible. Local network access, by design, implicitly trusts requests.

6.2.1. XSSI

It is possible for a malicious website to guess the IP address and port number of a Privet-compatible device and to try to call the Privet API using "src=<api name>" inside of a <script> tag:

<script type="text/javascript" src="http://192.168.1.42:8080/privet/info"></script>

Without protection, malicious websites would be able to execute API calls and access results.
To prevent this type of attack, ALL Privet API calls MUST require the "X-Privet-Token" header in the request. "src=<api>" script tags are not able to add headers, effectively guarding against this type of attack.

6.2.2. XSRF

http://en.wikipedia.org/wiki/Cross-site_request_forgery
It is possible for a malicious website to guess the IP address and port number of a Privet-compatible device and try to call Privet API using an <iframe>, forms, or some other cross-website loading mechanism. Attackers would not be able to access the results of the request, but if the request would perform an action (eg printing), they could trigger it.

To prevent this attack, we require the following protection:

Leave /privet/info API open to XSRF
/privet/info API MUST NOT perform any actions on the device
Use /privet/info API to receive x-privet-token
All other APIs MUST check for a valid x-privet-token in "X-Privet-Token" header.
x-privet-token SHOULD be valid for only 24 hours.

Even if an attacker is able to execute the /privet/info API, they would not be able to read x-privet-token from the response and therefore would not be able to call any other API.

It is strongly recommended to generate the XSRF token using the following algorithm:

XSRF_token = base64( SHA1(device_secret + DELIMITER + issue_timecounter) + DELIMITER + issue_timecounter )

XSRF Token Generation Elements:

DELIMITER is a special character, usually ':'
issue_timecounter is a number of seconds since some event (epoch for timestamp) or device boot time (for CPU counters). issue_timecounter is constantly increasing when the device is up and running (see token verification below).
SHA1 - hash function using SHA1 algorithm
base64 - base64 encoding
device_secret - secret specific to the device. Device secret MUST be updated on every restart.

Recommended ways to generate device secret:

Generate a new UUID on every restart
Generate a 64 bit random number on every restart

The device is not required to store all of the XSRF tokens it has issued. When the device needs to verify a XSRF token for validity, it should base64-decode the token. Get the issue_timecounter from the second half (cleartext), and try to produce SHA1 hash of device_secret + DELIMITER + issue_timecounter where issue_timecounter is from the token. If the newly generated SHA1 matches the one in the token, device must now check if the issue_timecounter is within the validity period from (24 hours) of the current time counter. To do so, device takes the current time counter (CPU counter for example) and subtracts issue_timecounter from it. The result MUST be the number of seconds since token issue.

Important: This is the recommended way to implement XSRF protection. Clients of the Privet specification shall not try to understand XSRF token, instead they shall treat is as a blackbox. Figure 6.2.3 illustrates a recommended way to implement the X-Privet-Token and verification of a typical request.

6.2.3 X-Privet Token Generation and Verification Sequence Diagram

6.3. Workflow diagrams

This section will illustrate a workflow in different cases.

6.3.1. Printer out of the box workflow

6.3.2. Registered printer startup

6.3.3 XMPP notifications handling workflow

6.3.4. Check printer settings workflow