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

[[e-mail]]

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