Hi Jensen,

On 15/12/2021 02:06, Jensen Zhang wrote:
Hi Alexey,

Thanks for your comments. Also thanks to Qin for your help. I will split the media-type registration into two separated subsections as well as address all your other comments and get back to you soon. For some of your comments, I have some further questions inline.
Answering below:

Thanks,
Jensen


On Wed, Dec 15, 2021 at 9:23 AM Qin Wu <[email protected]> wrote:

    Thanks Alex for valuable review and suggestion, I will ask leading
    author of draft-alto-request-routing-alto to implement the changes
    you suggested.

    -Qin

    *发件人:*Alexey Melnikov [mailto:[email protected]]
    *发送时间:*2021年12月15日4:22
    *收件人:*Qin Wu <[email protected]>;
    [email protected]
    *抄送:*[email protected]; Francesca Palombini
    <[email protected]>;
    [email protected]
    *主题:*Re: [media-types] application/alto-* Media Types Registration
    Request

    Hi  Qin,

    Overall this looks fine to me. A few comments below:

    On 03/12/2021 11:17, Qin Wu wrote:

        Hello,

        Here is the registration request of application/alto-* Media
        Types defined in section 7.1 of
        draft-ietf-alto-cdni-request-routing-alto:

        
https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/

        
https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-17.html

        I’ve included the details below.

        Note that this document has already entered into IESG review
        phase. Francesca Palombini kindly reminds us and the authors
        of this draft to

        send the media type registrations to the media-type mailing
        list for review before the document moves forward. Thanks
        Francesca.

        -Qin (on behalf of chairs)


              7.1.
              
<https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-17.html#section-7.1>application/alto-*
              Media Types
              
<https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-17.html#name-application-alto-media-type>

        This document updates the IANA Media Types Registry by
        registering two additional ALTO media types, listed in Table 1
        
<https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-17.html#TableMediaTypes>.

        /Table 1
        
<https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-17.html#table-1>:
        Additional ALTO Media Types.
        
<https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-17.html#name-additional-alto-media-types>/

        *Type*

                

        *Subtype*

                

        *Specification*

        application

                

        alto-cdni+json

                

        Section 3
        
<https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-17.html#cdnifci>
 of
        RFCthis

        application

                

        alto-cdnifilter+json

                

        Section 5
        
<https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-17.html#filteredcdnifci>
 of
        RFCthis

        Type name:

        application

        Subtype name:

        This document registers multiple subtypes, as listed in Table
        1
        
<https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-17.html#TableMediaTypes>.

    Existing media type registration template doesn’t allow
    registering multiple media types using the same template. So you
    will need to create multiple registrations.

    Having said that, a few minor comments below:

        Required parameters:

        n/a

        Optional parameters:

        n/a

        Encoding considerations:

        Encoding considerations are identical to those specified for
        the "application/json" media type. See [RFC8259
        
<https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-17.html#RFC8259>].

        Security considerations:

        Security considerations related to the generation and
        consumption of ALTO Protocol messages are discussed in Section
        15 of [RFC7285
        
<https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-17.html#RFC7285>].

        Interoperability considerations:

        This document specifies formats of conforming messages and the
        interpretation thereof.

    This section is for known interoperability concerns. If you don’t
    know of any, putting N/A here is probably the best.


Thanks for the suggestion. It has been done in version -18.

        Published specification:

        This document is the specification for these media types; see
        Table 1
        
<https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-17.html#TableMediaTypes>
 for
        the section documenting each media type.

        Applications that use this media type:

        ALTO servers and ALTO clients either stand alone or are
        embedded within other applications.

    Please add a reference to a document where ALTO is defined.
    Registration templates can be read by people who are not
    necessarily familiar with this technology.


Got it. Will add the reference to [RFC7285].

I've just realized that you are also missing "Fragment identifier considerations:" field after this one. (See RFC 6838) Having it as "N/A" is fine.

    Also when you split the registration template into 2 it would be
    good to have a sentence here explaining how the two formats differ.


Thanks for the suggestion. Could you kindly give us some further examples about what should be explained? Do we need to explain the different cases where the two subtypes should be used, or just explain the difference between the two registration forms?
The former. If I as an implementor read the registration, I need to decide whether or not I should implement processing of this particular media type.

        Additional information:

        Magic number(s):

        n/a

        File extension(s):

        This document uses the mime type to refer to protocol messages
        and thus does not require a file extension.

    I don’t think I agree with this statement, but not having a file
    extension is Ok. So just put “N/A” here.


OK. We will just put n/a here.


        Macintosh file type code(s):

        n/a

        Person & email address to contact for further information:

        See Authors' Addresses section.

        Intended usage:

        COMMON

        Restrictions on usage:

        n/a

        Author:

        See Authors' Addresses section.

        Change controller:

        Internet Engineering Task Force (mailto:[email protected]
        <mailto:[email protected]>).



        _______________________________________________

        media-types mailing list

        [email protected]

        https://www.ietf.org/mailman/listinfo/media-types

    _______________________________________________
    alto mailing list
    [email protected]
    https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to