Good to know, thanks Mark for clarification. -Qin -----邮件原件----- 发件人: Mark Nottingham [mailto:mnot@xxxxxxxx] 发送时间: 2019年12月2日 9:10 收件人: Qin Wu <bill.wu@xxxxxxxxxx> 抄送: ops-dir@xxxxxxxx; last-call@xxxxxxxx; draft-nottingham-rfc7320bis.all@xxxxxxxx 主题: Re: Opsdir last call review of draft-nottingham-rfc7320bis-02 Hi Qin, Thanks for the review. Responses below. > On 29 Nov 2019, at 1:38 am, Qin Wu via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Qin Wu > Review result: Ready > > This document provides a good guidance on the specification of URI > substructure in standards. One key value of this document is to remove > constraints upon the structure of URIs and provide best current > practice on how to specify structure and semantics within URIs. I > believe it is ready for publication. > > Major issue: > Not found > > Minor issue: > I am curious why this bis document is not published through WG process > but through individual stream process. The sponsoring AD knows for sure, of course, but my understanding was that it was some combination of the original document being AD-sponsored, the changes being well-understood and non-controversial, and the relatively small amount of work. > If this document is published through > individual steam process with AD sponsored, should this document be > classified as informational? That doesn't follow; AD sponsored documents can and often are published as standards-track. > Where was this document initially discussed to build IETF consensus? > In which WG? In the ART area (e.g., art-discuss). > Is removing constraints on the structure of URIs causing a lot of > debate, e.g., the following constraints relaxation: “ Note that this > does not apply to Applications defining a structure of URIs paths > "under" a resource under control of the server. Because the prefix is > under control of the party deploying the application, collisions and > rigidity are avoided, and the risk of erroneous client assumptions is reduced.” It doesn't seem to be. > Try to look into the history of the relevant discussion. I'm pretty familiar with it. Cheers, -- Mark Nottingham https://www.mnot.net/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
