|
1 | 1 | # Agent Integration Notes for SharpIpp |
2 | 2 |
|
3 | | -This file is the human-readable integration guide for AI/code agents working in this repository. |
4 | | -It summarizes verified specification coverage, highlights known parity gaps, and defines a safe workflow |
5 | | -for implementing missing IPP/PWG features. |
| 3 | +This file provides architectural pointers and development workflows for AI and code agents working in this repository. |
6 | 4 |
|
7 | | -## Scope and source of truth |
| 5 | +## Documentation & Specifications |
8 | 6 |
|
9 | | -- Primary runtime API surface: `SharpIpp/ISharpIppClient.cs` and `SharpIpp/ISharpIppServer.cs` |
10 | | -- Operation identifiers: `SharpIpp/Protocol/Models/IppOperation.cs` |
11 | | -- Request/response wiring: `SharpIpp/Mapping/Profiles/Requests` and `SharpIpp/Mapping/Profiles/Responses` |
12 | | -- Server dispatch: `SharpIpp/SharpIppServer.cs` |
13 | | -- Validation tests: |
14 | | - - unit: `SharpIpp.Tests.Unit` |
15 | | - - integration: `SharpIpp.Tests.Integration` |
16 | | -- Specification document corpus: `docs/Content/Specification` (includes RFCs and PWG specs through 5100.22-2025) |
| 7 | +To avoid duplication, full documentation is maintained in the [`docs`](docs) directory: |
| 8 | +- **Client Operations & Examples:** See [`docs/Content/Client/Operations.md`](docs/Content/Client/Operations.md) and individual operation guides in [`docs/Content/Client/`](docs/Content/Client/). |
| 9 | +- **Server Implementation:** See [`docs/Content/Server/index.md`](docs/Content/Server/index.md). |
| 10 | +- **Client Nuances & Best Practices:** See [`docs/Content/Client/ConfigurationAndBestPractices.md`](docs/Content/Client/ConfigurationAndBestPractices.md). |
| 11 | +- **Specification Corpus:** Full RFCs and PWG specifications (through PWG 5100.22-2025) are located in [`docs/Content/Specification/`](docs/Content/Specification/). |
17 | 12 |
|
18 | | -## Verified specification coverage snapshot |
| 13 | +## Core Source of Truth |
19 | 14 |
|
20 | | -- Legacy baseline remains RFC 2911 + CUPS operations (see `README.md`). |
21 | | -- Expanded spec corpus is present under DocFX, including: |
22 | | - - RFC 2911, RFC 8010, RFC 8011 |
23 | | - - PWG 5100.x families including 5100.5, 5100.7, 5100.18, and 5100.22 |
24 | | -- IPP System Service support from PWG 5100.22-2025 is broadly implemented in client models and mappings. |
| 15 | +- **Client Contract:** [`SharpIpp/ISharpIppClient.cs`](SharpIpp/ISharpIppClient.cs) and `SharpIppClient.*.cs` |
| 16 | +- **Server Contract & Dispatch:** [`SharpIpp/ISharpIppServer.cs`](SharpIpp/ISharpIppServer.cs) and [`SharpIpp/SharpIppServer.cs`](SharpIpp/SharpIppServer.cs) |
| 17 | +- **Operation Enumeration:** [`SharpIpp/Protocol/Models/IppOperation.cs`](SharpIpp/Protocol/Models/IppOperation.cs) |
| 18 | +- **Mapping Profiles:** `SharpIpp/Mapping/Profiles/Requests` and `SharpIpp/Mapping/Profiles/Responses` |
| 19 | +- **Tests:** `SharpIpp.Tests.Unit` and `SharpIpp.Tests.Integration` |
25 | 20 |
|
26 | | -## PWG 5100.22-2025 implementation notes |
| 21 | +## Agent Workflow for Spec-Parity Changes |
27 | 22 |
|
28 | | -Implemented and wired in the client contract include System Service operations such as: |
| 23 | +When adding or updating an IPP operation or attribute, implement parity end-to-end: |
29 | 24 |
|
30 | | -- `AllocatePrinterResourcesAsync`, `DeallocatePrinterResourcesAsync` |
31 | | -- `CreatePrinterAsync`, `DeletePrinterAsync`, `GetPrintersAsync`, `GetPrinterResourcesAsync` |
32 | | -- `GetSystemAttributesAsync`, `GetSystemSupportedValuesAsync`, `SetSystemAttributesAsync` |
33 | | -- `DisableAllPrintersAsync`, `EnableAllPrintersAsync`, `PauseAllPrintersAsync`, `ResumeAllPrintersAsync` |
34 | | -- `ShutdownOnePrinterAsync`, `StartupOnePrinterAsync`, `ShutdownAllPrintersAsync`, `StartupAllPrintersAsync` |
35 | | -- `RestartSystemAsync`, `RestartOnePrinterAsync` |
36 | | -- `RegisterOutputDeviceAsync` |
37 | | -- System/resource subscription operations (`CreateSystemSubscriptionsAsync`, `CreateResourceSubscriptionsAsync`, etc.) |
| 25 | +1. Confirm or add the operation ID in [`IppOperation.cs`](SharpIpp/Protocol/Models/IppOperation.cs). |
| 26 | +2. Create request and response model types in `SharpIpp.Models`. |
| 27 | +3. Add client contract method in [`ISharpIppClient`](SharpIpp/ISharpIppClient.cs) and implementation in `SharpIppClient.*.cs`. |
| 28 | +4. Add request/response AutoMapper profiles. |
| 29 | +5. Add server dispatch mapping in [`SharpIppServer.ReceiveRequestAsync`](SharpIpp/SharpIppServer.cs). |
| 30 | +6. Add unit and integration tests (mapping, validation, and round-trip tests). |
| 31 | +7. Update documentation in [`docs/Content/Client/`](docs/Content/Client/) and [`docs/Content/Client/Operations.md`](docs/Content/Client/Operations.md). |
38 | 32 |
|
39 | | -Additional 5100.22 model/mapping support verified: |
| 33 | +## Practical Guidance |
40 | 34 |
|
41 | | -- `ResourceStatusAttributes.ResourceUuid` |
42 | | -- strong typed collections for system/resource and power-policy/state objects |
43 | | -- collection mapping in `CollectionProfiles` and related response profiles |
44 | | - |
45 | | -## Agent workflow for spec-parity changes |
46 | | - |
47 | | -When adding or correcting a spec operation/attribute, treat parity as end-to-end: |
48 | | - |
49 | | -1. Add/confirm operation id in `IppOperation`. |
50 | | -2. Add request/response model types. |
51 | | -3. Add client contract method in `ISharpIppClient` and implementation in `SharpIppClient.*.cs`. |
52 | | -4. Add request/response profile wiring. |
53 | | -5. Add server dispatch mapping in `SharpIppServer.ReceiveRequestAsync`. |
54 | | -6. Add or update protocol attribute/profile mappings for any new fields. |
55 | | -7. Add tests: |
56 | | - - unit mapping tests |
57 | | - - unit client request-operation mapping tests |
58 | | - - integration request/response roundtrip tests |
59 | | -8. Update docs: |
60 | | - - `docs/Content/Client/Operations.md` |
61 | | - - any relevant specification or API pages |
62 | | - |
63 | | -## Practical guidance for agents |
64 | | - |
65 | | -- Prefer small, focused patches and keep naming aligned with existing IPP operation style. |
66 | | -- Preserve bidirectional mapping symmetry for new attributes. |
67 | | -- For enum arrays in IPP attributes, ensure both read and write mapping paths are covered. |
68 | | -- Do not assume DocFX pages are fully current; verify behavior from code + tests first. |
| 35 | +- Prefer small, focused patches and preserve naming consistency with existing IPP models. |
| 36 | +- Maintain bidirectional mapping symmetry (read and write) for all protocol attributes. |
| 37 | +- Verify behavior against unit and integration tests before finishing. |
0 commit comments