IPP Mail Archive: IPP> IPP Mailto last call comments

IPP Mail Archive: IPP> IPP Mailto last call comments

IPP> IPP Mailto last call comments

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Wed Jul 13 2005 - 22:20:13 EDT

  • Next message: McDonald, Ira: "IPP> FW: IESG review comments on IPP Notifications specs - May 2003"

    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).

    - 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@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

        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

        T. Hastings, R. K. deBry, H. Lewis, "Internet Printing Protocol
        (IPP): Requirements for IPP Notifications", RFC 3997, March 2005.


    This archive was generated by hypermail 2b29 : Wed Jul 13 2005 - 22:19:51 EDT