Hi folks, Wednesday (13 July 2005)
Here are my proposed edits for IPP Mailto last call comments.
In a separate note, I'll forward the 2003 IESG last call comments on IPP
Notifications in general (applies to all the specs). I'm still looking
for Ned Freed's individual comments on IPP Mailto (Ned wrote the MIME
RFCs and was our IPP IETF Application Area Director at the time).
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
------------------------------------------------------------------------
[global edits to all sections]
* Replace 'domain.com' with 'example.com'.
* Replace 'RFC 1521' or '[RFC1521]' inline with '[RFC2045]' (obsoletes).
* Replace 'RFC 2822' inline with '[RFC2822].
------------------------------------------------------------------------
[edits to section 'Contact Info' in boilerplate]
* Delete errroneous reference to 'additional media names'???
------------------------------------------------------------------------
[edits to section 4 'General Information']
[table 1 - question 9]
* Append to end of Delivery Method Realization text
(see section 10 'Security Considerations')
------------------------------------------------------------------------
[edits to section 5.2.1 'notify-recipient-uri (uri)']
[para 1]
* Append this new last sentence:
The syntax and security considerations for the 'mailto' URL scheme
are normatively defined in [RFC2368] (which is currently under
revision in [RFC2368bis]).
------------------------------------------------------------------------
[edits to section 10 'Security Considerations']
[para 2]
* Replace references to [ipp-not-req] or [ipp-req] with [RFC3997].
[para 5 and 6]
* Append two new paragraphs (per IESG members and Ned Freed comments):
A Printer that supports this Delivery Method SHOULD implement
configurable security policies to address issues raised in section 7
of [RFC2821], section 5 of [RFC2822], and section 7 of [RFC2368],
for example:
(a) Constraining the value of "notify-recipient-uri" to use the same
domain as the Subscribing Client (value of "notify-user-data");
(b) Restricting the value of "notify-recipient-uri" to disallow
delivery to distribution lists (i.e., mail reflectors).
A Printer that supports this Delivery Method SHOULD default to a
conservative security policy (e.g., same domain restriction).
------------------------------------------------------------------------
[edits to section 11.1 'Normative References']
* In [RFC2565] and [RFC2910], replace 'R. Tuner' with 'R. Turner'.
* Add normative reference to [RFC2045] - see below
[RFC2045] - move from 'Informative References' for sections 6.1.6, 6.1.7
------------------------------------------------------------------------
[additions to section 11.2 'Informative References']
* Delete informative reference to [RFC2045] - see above
* Delete informative reference to [RFC2046] - unused in specification
* Add informative reference to [RFC2368bis] for section 4
[RFC2368bis]
M. Duerst, L. Masinter, "The mailto URI scheme",
<draft-duerst-mailto-bis-xx.txt> (work-in-progress).
* Add informative reference to [RFC3997] for section 10
[RFC3997]
T. Hastings, R. K. deBry, H. Lewis, "Internet Printing Protocol
(IPP): Requirements for IPP Notifications", RFC 3997, March 2005.
------------------------------------------------------------------------