IPP> IPP Mailto last call comments

IPP> IPP Mailto last call comments

McDonald, Ira imcdonald at sharplabs.com
Wed Jul 13 22:20:13 EDT 2005


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.

------------------------------------------------------------------------



More information about the Ipp mailing list