Hi Smith,
The "three sisters" (and various other names) are the three parallel
and order-dependent arrays in RFC 2911: "printer-uri-supported",
"uri-authentication-supported", and "uri-security-supported".
The later collection attribute "printer-xri-supported" in RFC 3380
was copied from SLP and LDAP Printer Schema to allow an admin
to "get it right" and do atomic updates of the "three sisters". See
definition and examples of usage on pages 26-28 of RFC 3380.
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 Thu, Dec 18, 2014 at 4:12 PM, Kennedy, Smith (Wireless Architect) <
smith.kennedy at hp.com> wrote:
>> Hi Ira,
>> - Editorial - Revised section 6.2.4 No Client Authentication for 'ipps'
> URI to remove all references to downgrade (from TLS to straight TCP),
> explicitly mention the IPP "three sisters" relevant attributes, and
> add example of LDAP Printer Schema [RFC3712] for directory protocols,
> per Sandra Murphy and Mike Sweet.
>> Just to satisfy my own curiosity, what are the “three sisters”?
>> Smith
>> /**
> Smith Kennedy
> Wireless Architect - Client Software - IPG-PPS
> Hewlett-Packard Co.
> */
>>>> On 2014-12-18, at 1:50 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>> Hi,
>> This version has editorial changes requested by IESG reviewers in early
> December,
> when it was approved for publication as a standards-track RFC.
>> I've just posted another Internet-Draft of IPP over HTTPS Transport
> Binding and
> 'ipps' URI Scheme to:
>>>ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-18-20141218.txt> - plaintext Internet-Draft format (warning - contains explicit formfeed
> characters)
>>>ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-18-20141218.log> - plaintext change log (removed from body of spec)
>>>ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-18-20141218.pdf> - PDF of plaintext w/ line numbers (review *this* one)
>> This document has already been accepted and posted to the IETF I-D
> repository.
>> This document is parallel to, but does not update or obsolete, RFC 3510.
>> Comments?
>> Cheers,
> - Ira
>> --------------------------------
>> Change History
>> 18 December 2014 - draft-mcdonald-ipps-uri-scheme-18.txt
>> - Editorial - Revised section 1 Introduction to expand bullet (a)
> to update sections 4, 5, and 8.2 of [RFC2910] to explicitly add new
> standard scheme of 'ipps' for IPP Printers,
> per Sandra Murphy.
>> - Editorial - Revised section 1 Introduction to expand bullet (b)
> to update sections 4.1.6 and 4.4.1 of [RFC2911] to explicitly add new
> standard scheme of 'ipps' for IPP Printers,
> per Sandra Murphy.
>> - Editorial - Revised section 1 Introduction to delete bullet (c)
> reference to updating PWG IPP 2.0 [PWG5100.12] (will be covered by a new
> PWG version of [PWG5100.12] in 2015 to move to full IEEE Standard),
> per Spencer Dawkins, Adrian Farrel, Barry Leiba, Sandra Murphy, Pete
> Resnick, Robert Sparks, and other reviewers.
>> - Editorial - Revised section 1.2 Rationale for this Document bullet (1)
> about flawed implementations of HTTP Upgrade [RFC2817] to add
> "although this is not due to specification defects in [RFC2817] itself",
> per Pete Resnick.
>> - Editorial - Revised section 1.2 Rationale for this Document bullet (2)
> and section 6.1.2 Layers of Attacks bullet (a)
> to replace [STD7] with [TCPROAD] for normative TCP reference,
> per Barry Leiba and Spencer Dawkins.
>> Editorial - Revised section 2.1 Printing Terminology definition of IPP
> Client to change "a downstream IPP Printer" to simply "an IPP Printer",
> since discussion of forwarding and "fan-out" of print jobs [RFC3998] is
> out-of-scope in this specification,
> per Sandra Murphy and Mike Sweet.
>> Editorial - Revised section 2.1 Printing Terminology definition of IPP
> Printer to change "an upstream IPP Client or IPP Printer" to simply
> "an IPP Client", since discussion of forwarding and "fan-out" of print
> jobs [RFC3998] is out-of-scope in this specification,
> per Sandra Murphy and Mike Sweet.
>> - Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme to
> mention general caution about IPP Printer URI lengths greater than 255
> octets for both 'ipp' [RFC3510] and 'ipps' schemes,
> per Sandra Murphy.
>> - Editorial - Revised section 4.3 Associated Port for 'ipps' URI Scheme
> to delete (confusing) last paragraph about listening on port 443,
> per Pete Resnick and Mike Sweet.
>> - Editorial - Revised section 4.5 Examples of 'ipps' URI to delete
> (confusing) example about use of port 443,
> per Pete Resnick and Mike Sweet.
>> - Editorial - Revised section 4.5 Examples of 'ipps' URI actual examples
> to align with IPP Everywhere [PWG5100.14], IPP FaxOut Service
> [PWG5100.15], and IPP Scan Service [PWG5100.17] best practice,
> per Mike Sweet.
>> - Editorial - Revised section 6.1.1 Targets of Attacks bullet (d) to add
> "for example, to steal the data" (i.e., theft of data in transit),
> per Kathleen Moriarty.
>> - Editorial - Revised section 6.2.4 No Client Authentication for 'ipps'
> URI to remove all references to downgrade (from TLS to straight TCP),
> explicitly mention the IPP "three sisters" relevant attributes, and
> add example of LDAP Printer Schema [RFC3712] for directory protocols,
> per Sandra Murphy and Mike Sweet.
>> - Editorial - Revised section 6.3 TLS Version Requirements to add
> informative reference to IETF UTA TLS BCP
> "Recommendations for Secure Use of TLS and DTLS",
> per Kathleen Moriarty.
>> - Editorial - Revised section 7 Acknowledgments to add other IETF and
> PWG reviewers.
>> - Editorial - Revised section 8.1 Normative References
> to delete unused [RFC7232], [RFC7233], [RFC7234], and [RFC7235],
> per ID-Nits.
>> - Editorial - Revised section 8.1 Normative References
> to delete [STD7] for normative TCP reference,
>> - Editorial - Revised section 8.2 Informative References
> to add missing [IPPREG] (IANA IPP Registry),
> per ID-Nits.
>> - Editorial - Revised section 8.2 Informative References to add
> LDAP Printer Schema [RFC3712] for update to section 6.2.4 above,
> per Sandra Murphy and Mike Sweet.
>> - Editorial - Revised section 8.2 Informative References to add
> IPP FaxOut Service [PWG5100.15] and IPP Scan Service [PWG5100.17],
> per Mike Sweet.
>> - Editorial - Revised section 8.2 Informative References to add
> [TCPROAD] for informative TCP reference,
> per Barry Leiba and Spencer Dawkins.
>> - Editorial - Revised section Authors' Addresses to update Mike Sweet's
> contact info.
>>>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20141218/ae050427/attachment.html>