Re: [alto] Zaheduzzaman Sarker's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)

[Zaheduzzaman Sarker <[e-mail]>]

The new text looks good. Thanks

// Zahed

On Thu, 30 Nov 2023 at 02:03, <[e-mail]> wrote:

> Hi Zahed,
>
> Please see inline for the new text. If it works, I will submit a new
> revision with the proposed changes. Thanks for the helpful review!
>
> Best,
>
> Kai
>
>
> -----Original Messages-----
> *From:* "Zaheduzzaman Sarker" <[e-mail]>
> *Send time:* Wednesday, 11/29/2023 20:01:10
> *To:* [e-mail]
> *Cc:* "Kai GAO" <[e-mail]>, "The IESG" <[e-mail]>,
> [e-mail], [e-mail],
> [e-mail]
> *Subject:* Re: Re: [alto] Zaheduzzaman Sarker's Discuss on
> draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)
>
>
>
>
>
> On Wed, Nov 29, 2023 at 12:41 PM <[e-mail]> wrote:
>
>> Hi Zahed,
>>
>> Thanks for the comments! Please see the responses inline. I already have
>> the updates in place but would like to submit a new revision after you
>> review the proposed texts.
>>
>> Best,
>>
>> Kai
>>
>>
>> -----Original Messages-----
>> *From:* "Zaheduzzaman Sarker" <[e-mail]>
>> *Send time:* Tuesday, 11/28/2023 20:02:44
>> *To:* "Kai GAO" <[e-mail]>
>> *Cc:* "The IESG" <[e-mail]>, [e-mail],
>> [e-mail], [e-mail], "Kai Gao" <
>> [e-mail]>
>> *Subject:* Re: [alto] Zaheduzzaman Sarker's Discuss on
>> draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)
>>
>> Hello,
>>
>> Thanks for addressing the comments. The -19 version looks improved.
>>
>> Some more reflections below.
>>
>> //Zahed
>>
>> On Tue, Nov 21, 2023 at 4:09 PM Kai GAO <[e-mail]> wrote:
>>
>>> Hi Zaheduzzaman,
>>>
>>> We are sorry for the late reply -- the mail was blocked by the spam
>>> detector. Please see our responses inline.
>>>
>>> Best,
>>> Kai
>>>
>>> On Thu, Oct 26, 2023 at 6:56 PM Zaheduzzaman Sarker via Datatracker <
>>> [e-mail]> wrote:
>>>
>>>> Zaheduzzaman Sarker has entered the following ballot position for
>>>> draft-ietf-alto-new-transport-17: Discuss
>>>>
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>> introductory paragraph, however.)
>>>>
>>>>
>>>> Please refer to
>>>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>>>> for more information about how to handle DISCUSS and COMMENT positions.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> DISCUSS:
>>>> ----------------------------------------------------------------------
>>>>
>>>> Thanks for working on this specification.
>>>>
>>>> I have following points which I want to discuss further -
>>>>
>>>> - I understand this new transport is supposed to take advantages of
>>>> HTTP/2 and
>>>> HTTP/3 features and have backward compatibility with HTTP/1.x (x=1,
>>>> likely). My
>>>> take is, if I want to server ALTO server over HTTP2/ or HTTP/3 I would
>>>> use this
>>>> new transport. Now if I also want to also support HTTP1.x for whatever
>>>> reasons
>>>> then I have issue, should this new transport is sufficient to support
>>>> all the
>>>> HTTP versions up to HTTP/3? if yes, then why this does specification
>>>> not update
>>>> or even obsolete rfc8895? if the answer is NO, does that mean I need to
>>>> implement both this specification and rfc8895 for HTTP1.1? This
>>>> relation is not
>>>> explicitly defined in this current draft, which it should.
>>>>
>>>> [KAI] Thanks for the comment. Yes, the new transport is sufficient to
>>> support all HTTP
>>> versions up to HTTP/3. The relationship between new transport and
>>> RFC8895 is also
>>> raised by the IoT telechat review by Wesley Eddy. Our understanding is
>>> that new
>>> transport is not a replacement of ALTO/SSE, and these two extensions can
>>> be combined
>>> (see the introduction of -18 for more complete discussions).
>>>
>>
>> This looks better in -19 version. Thanks
>>
>>>
>>> - I am not convinced that incremental update actually reduces storage at
>>>> ALTO
>>>> server, how is that so? I don't think there is an strict requirement
>>>> that all
>>>> the ALTO clients need to be updated to the recent version to be
>>>> functional (as
>>>> described in this specification), that means unless the serve is sure
>>>> that all
>>>> the clients are updated to certain version it has to keep the update
>>>> versions.
>>>> As storage reduction is a motivation for the transport requirement this
>>>> motivation need to be well described to derive the requirement.
>>>>
>>>
>>> [KAI] The "reduced storage" is compared to the case where the server
>>> stores the contents
>>> of each version. It is a motivation to use incremental updates (which
>>> applies to RFC 8895
>>> as well) and we consider incremental updates as one motivation for the
>>> new transport.
>>> Does this make sense?
>>>
>>
>> The draft still just mentions this as a statement. I think it would be
>> better if it is clear that the comparison is done with the case where the
>> server stores the contents of the each version.
>>
>>
>> [KAI] Got it. The proposed text is:
>>
>> NEW:
>>       Incremental updates only maintain and transfer
>>       the "diff" upon changes.  Thus, it is more efficient than storing
>>       and transferring the full updates, especially when the change of
>>       an ALTO resource is minor.
>>
>
> LGTM.
>
>>
>>
>>
>>>
>>>
>>>> - I didn't find any explanation of how the "Concurrent, non-blocking
>>>> update
>>>> transmission" requirement is meet by the new transport. is this solved
>>>> by the
>>>> use of HTTP/3 with uses QUIC and does not have HOL blocking within a
>>>> connection? Or is this addressed by multiple concurrent HTTP connection
>>>> to the
>>>> ALTO server? This need to be understood better and we should define what
>>>> actually "Concurrent, non-blocking update transmission" means in this
>>>> context
>>>> of fetching updates.
>>>>
>>>>
>>> [KAI] The requirement basically requires that incremental updates can be
>>> transmitted
>>> at the same time (concurrent) and the transmission of one update will
>>> not be blocked
>>> by the transmission of another update. This can be realized by 1)
>>> multiple HTTP
>>> connections, or 2) HTTP/3 using multiple streams. This is compared with
>>> RFC 8895
>>> where SSE multiplexes the updates in a single sequence. You make a good
>>> point that
>>> we should clarify how this can be done with new transport. We will add a
>>> paragraph to
>>> Sec 2.1 and upload a revision soon.
>>>
>>>
>>>> - The encoding or data type of "updates graph (ug)" and "version" is not
>>>> defined. The example uses numeric numbers which is easy to understand
>>>> with
>>>> incremental values. However, unless and otherwise this data type is
>>>> defined
>>>> then it is up to the implementers to select that and which will lead to
>>>> interoperability issues. or may be I am missing something here, that is
>>>> why I
>>>> need to discuss the intention here.
>>>>
>>>>
>>> [KAI] The data type of the version tag (the one held by the client) is a
>>> string (JSONString)
>>> but the "version" used to compute the URLs is a sequence number
>>> (JSONNumber), both
>>> specified in Sec 6.2.
>>>
>>
>> do you mean "UpdatesGraphSummary" ? can we put the inline ref to the
>> section where version datatype is defined to avoid confusion?
>>
>>
>> [KAI] The proposed texts are added to the "Updates graph" and "Version"
>> entries in Sec 2.2.
>>
>> NEW: ... Encoding of a updates graph is specified in Section 6.1.
>>
>> NEW: ... Version is encoded as a JSONNumber, as specified in Section 6.1.
>>
>
> Better now.
>
>>
>>>
>>>> -  Here we are composing URIs from the ug , that tells me without proper
>>>> encoding on ug defined there might be some internationalization issues
>>>> (see
>>>> rfc6365). Has there been any thoughts or discussions on this encoding
>>>> and
>>>> potential issues?
>>>>
>>>>
>>> [KAI] Good point. According to RFC 7285 (the base ALTO protocol), the
>>> contents
>>> of the ALTO maps only allow ASCII characters. I think this document
>>> should have
>>> the same restrictions.
>>>
>>
>> have you mentioned this in -19 version? if not then please write the
>> restriction.
>>
>> [KAI] I checked the charset for JSON (e.g. RFC 4627). Seems that the
>> encoding is unicode (and UTF-8 by default). In that case, there is only one
>> potential risk that a tips-view-uri may contain international characters,
>> as other parts of the constructed URLs are all ASCII. In Sec 6.2, we
>> require tips-view-uri to follow RFC 3986 which only uses ASCII characters
>> for the URL. Our proposal is to add a text in Sec 6.2:
>>
>> NEW:
>>
>> The field [tips-view-uri] MUST contain only ASCII characters. If the
>> original URL contains international characters (e.g., in the domain name),
>> they MUST be properly encoded into the ASCII format (e.g., using the
>> "urlencode" function).
>>
>
> I think we need to hint on "who" is going to convert them using that
> function.
>
> [KAI] Makes sense. How about the following text?
>
> NEW:
>
> The field [tips-view-uri] MUST contain only ASCII characters. In case the
> original URL contains international characters (e.g., in the domain name),
> the ALTO server implementation MUST properly encode the URL into the ASCII
> format (e.g., using the "urlencode" function).
>
>
> //Zahed
>
>
>>
>>
>> //Zahed
>>
>>
>>
>>
>>>
>>>
>>>> and I am also supporting Roman's discuss.
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>>
>>>> I think my other AD colleagues have already identified nits and typos.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> alto mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/alto
>>>>
>>>