Re: [Uri-review] Request for Review and Registration of New URI Scheme "ai"

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Thu, 04 January 2024 04:15 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A56C14F701 for <uri-review@ietfa.amsl.com>; Wed, 3 Jan 2024 20:15:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEwbI6K-XwCT for <uri-review@ietfa.amsl.com>; Wed, 3 Jan 2024 20:15:30 -0800 (PST)
Received: from JPN01-TYC-obe.outbound.protection.outlook.com (mail-tycjpn01on2095.outbound.protection.outlook.com [40.107.114.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C6EC14F6E8 for <uri-review@ietf.org>; Wed, 3 Jan 2024 20:15:30 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kemyq8g7uBtWHqLcy8iN7dojJac7xI1DPXkfMkO8P+BLb1T6Dd8/usmSyop5RHfMAnp019QXxZW0Vzj/gNYxwVILYDTTlNK2GpmMhx41OPCsGI04J9OlYKgQL6CMEFW57G13UXzyMlIqNg6HN+cs00qe7w3hHSf9Hm8SAV5sRajOYrVhOP0UUE6QFC0pstRnYrm33orGheqGvtUXuWIlDY8KDlnwhrx8EdkGt3V349SgiO2tIEfn48bGJQqg4hLWomxjH+Kz9kBBeHU3LmPzoTLhuOV8lDlBhHerGmiNoEEiSijkTosJfj7f75fcVXxDkwEOmuj4hhEiYWDnU/9T7Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8o7umsZfOS07U13uZh1xFnziZ1S52OlKXIbk6BWDGFs=; b=XSHNpJyzux2BNtLf4hD29aHf3u8PLcpKe/XQXGxP96SCLGQArj0UD4j+c7ts1KfvEDty6Bb+9XdU0YsBNofamJP5EPLd6DuFy436KzQwPUvTRGNRjEdarqxpVkg+eQHC0/BeZusnh7K83efd3D/C3jjrpb6c0cqRPbMiWy2nt1MVXxDXyhtrROVXen20B7vMVnNv8195S6ZCeFI67kf7oK5MVrzT3n6E8/ySiDCTk+yZdT+y4crxddS5t+9M4x5DCwDeZ18B/xVtlHR/2TaiTXSaozs3MRJbpPA4GwDQIQBtLaQmFtOZP6AIItVLaOFETtVjEInn3a1MhZvhLJ/1AA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8o7umsZfOS07U13uZh1xFnziZ1S52OlKXIbk6BWDGFs=; b=ZBVM9ufRgvNzcRv9rVlrdiSPcvYAQkF8GE1waulIxO2mQBNoq4ouWMx3y/yZE4EPbVNBPgKuGNQN+ji4vR5PbexWSGjSBG6BIUZy3igN117kMGE76NE9Umi5tvdM4OjFW3TLRYDbM5xh2dpkM4HIx7CmWZ6wdq47Lzxxcg8E5GU=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=it.aoyama.ac.jp;
Received: from TYWPR01MB10208.jpnprd01.prod.outlook.com (2603:1096:400:1e4::12) by OSZPR01MB9394.jpnprd01.prod.outlook.com (2603:1096:604:1d8::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7159.14; Thu, 4 Jan 2024 04:15:27 +0000
Received: from TYWPR01MB10208.jpnprd01.prod.outlook.com ([fe80::be8e:ac0a:bdd3:9291]) by TYWPR01MB10208.jpnprd01.prod.outlook.com ([fe80::be8e:ac0a:bdd3:9291%6]) with mapi id 15.20.7159.013; Thu, 4 Jan 2024 04:15:27 +0000
Message-ID: <fc6a134a-1438-4bea-a637-93065bf28fdc@it.aoyama.ac.jp>
Date: Thu, 04 Jan 2024 13:15:24 +0900
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: IS4 <is4.site@gmail.com>, uri-review@ietf.org
References: <2047091996.519294.1696656878248@privateemail.com> <93ee3113-0ab2-7124-678b-cc523571e613@it.aoyama.ac.jp> <1258868613.683466.1696903560871@privateemail.com> <d6e20b29-f03b-4a7d-eddb-feee1dedcaf7@ninebynine.org> <8ee73eae-1b2f-4f3f-ba39-3d78cac8d12b@gmail.com>
From: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
In-Reply-To: <8ee73eae-1b2f-4f3f-ba39-3d78cac8d12b@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: TYCP301CA0020.JPNP301.PROD.OUTLOOK.COM (2603:1096:400:381::13) To TYWPR01MB10208.jpnprd01.prod.outlook.com (2603:1096:400:1e4::12)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: TYWPR01MB10208:EE_|OSZPR01MB9394:EE_
X-MS-Office365-Filtering-Correlation-Id: 858708a2-a97a-4739-3ae6-08dc0cdbc7f6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: WXGlhjLMhUEjMhZDXmvAQmEBja6Ri7uiSzXk6WLSfJwIHJZ75iXCYwZZ67e7BB3jQ20xGoy6lGG0oQsJWQF3J+M7heetJnQ+zsKtzleOM3w5WBg9C5p+gF1im2JfgOGiJKTgfqV0bJjyjDDt4blNkYM6J27dBEouIzXlwmOjF8crKofJHPY11jkVl+8Dbk8gU+XpykHpn0NgjnFwF7mJOjJnkN9VfCz1UnQzxwJQBiSZR6TARoNY79QRkJxma+R2mOwI14HV3+k8YFIN4vLWgjJzUnZuYR8w+j8zwas5dRniaBD940LDLW7q9TCQOhUYsWN15c7ypfovFCh6Fcaxy+H6D5+dyCi+/L6ZG7UMx5WzsuC6kMhMAKmerAJCqH4WrBIvkeA7TKEJ/eKU2b0V5/kIaJddV4u9EUnSq++D3qasP0b8D10fsF9jFlLkcmJJMWYyuiaKB4cMmLShi/jZfTBqdFHGuqmHr3zGlf0OcRzXakZleKiptoYfy59eScFBeyJS3wlpVMoE0tzLfAVWfSs56QWa18mnCZnAxgdUA11CYCi764ZX2gTgelVReIBR1GsxNTXeTd55tdYUVsebnSKrCwngRTd5HXzWLNsJyVTFYhlSVaECxuEglprUmzXQytkc4RDHxsW+1ryL+nrWMpKH39dii0vEbAOvwZ4E+9TCS1EIiJP+B9gXCB48Vjfx
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYWPR01MB10208.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(136003)(39840400004)(396003)(346002)(376002)(366004)(230273577357003)(230173577357003)(230922051799003)(64100799003)(186009)(451199024)(1800799012)(36916002)(6666004)(316002)(478600001)(966005)(786003)(8936002)(8676002)(6486002)(66946007)(66556008)(66476007)(53546011)(2616005)(6512007)(6506007)(83380400001)(26005)(66574015)(41320700001)(2906002)(5660300002)(30864003)(41300700001)(38100700002)(66899024)(86362001)(31696002)(31686004)(45980500001)(43740500002); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: gGVuXy4jlIsZNXoogTJ0KfQnoiJxd+CLx45aj+8QilH6FZFqlT+oBfcJs2N3fBV8FMVqoWHOlYh90ZUKNR6JjFVwTxixC8IjGDd5FjrONLJe2kdyU+yHbrOA8xc/8gUjCZlTDLfN5Di1qV4V61mOlI1WxfXcvdRYgTKvXA7vAO7I/kgDdDIJC6DDzwie39forjUmip3krsug/GBGj+0aOuDBpJLU0IRIM6wtozpxEKLpYvXefmGUtdAtt/ilFZbS4tzRnvS944e8VOi5fZiAhm52lLuIAL7ytjF8M4No1V3AHmHPLg3ir6422UL2Lxrcdg2NBqxQdiz2d1QXkf/jSUR6BC/VLB8sAcPbr+LYj/Y7chACfS93s66WDRBMYwnYPDL9AEkDRVXanHRxquC30AO+Mhk582QTVIAIsANOhoVNYPfqxzPgWjwsLNTRk+b1SFsO6kt0R743afCZ/aQKPYKNSsqKssyxTy5NKQNSS4Ytv/eDzpJhwczYUiT7ZwmSlG3tt9e8EPDSCsvZsKydZNhrHCKL7jV74lvMgaOJhfG3KLLFTzmtGXEeQ5YJI9iZgWHrYL9p6zfkB4RDfPgFpCKqWLuUzEwQLcInL8D2X3ouC0HlCuKLyKVBkn6RMIW8nWFa+Rptfl7sTfrMZfd9LaLckNGfOMNFW3ewxyTyvCafN+gRSEkcKpyhPXQhXgI9xnQv3UGsaLKKOBdfrVUpe9XMmyAx4X8mbRoBKDBwef6YqWJRygh4kRixu12vblGQBq7AIiAVhMDr29vpIqW9/8fB/8FVglf4CZAQyJfvHgZzlrr7nlnElFHsv+ZcTsHPWsEAzclebhvxtwP1WDcYUJdeUuEA80dLEgvhOKFEEAptFa213NtrPThkKKtrT3Afzp4D5VTSWNcHe+zWR+uO//VEniIl00eQPnuJqaVvhCEsDsGQ9E55KQlvPTUz2tuCTew5OcI/B61F0sGD+9Dc8VTa5JrBPFAXzFrnk7L4Rnp2uNoARc3q26SC+5fKgm0mDE0rnGWbzJ7aQncUmzy1oMhHEljI4T4ATwHZLFPRy/73/Hopb8v5SAzrCua81s0B8i1fQcrD2mxpl1k5kaOIPb6lgtNPVmIIgulmtJSbhMSN1SiPthjwDU1PwwWWDwsfqq96r8LoYaod8f3F7KPTFUf+9WHYQt/VDdx/AZQMV3OHDwIW6V0ty32IwYv+Su8I3GbOmZThmz6voVOe5UCYuAKJxXqlc3inOenFlRlmPVwSRhWpQE6rZvxl2YvArCXfcQxLCUvt2eznJzPI+Mos6tZzDCrMU/TH/pgU191qS9wW3kThqAWri/TS7EHhA4V41/KC/eNQEiV41Vt79cDMJtLmw/L4m7euiMcWTn96sfWwSSi9cAGM/4fEOs+JJH9zx6Sx1ZgJ99KVBIuEyC3jHlw/Aq/svxs7hOEydyHfwVodpgJ11S7dvIbuxKQL15zs+UOfHXFj6AcseLzI7E4hu4v4fotjeAoqNtcV1j8fBf68Bf4GGKvrF1eEIWGqVDeFZ1lnW9wtvs2m0lR1JoqiSlUNtJGj1FJdzefrm5jXZuj7ctUZ+eHUCgI+e0bVsi5+
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: 858708a2-a97a-4739-3ae6-08dc0cdbc7f6
X-MS-Exchange-CrossTenant-AuthSource: TYWPR01MB10208.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jan 2024 04:15:27.2975 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Lvm7Tc8OurOg0FXE0orfPYIISsXu9oNeQIlkKhn83dIvnFzsxXYrSfZo5t3uoL+K6nr/IhS+0oZUx0YwVk/XLQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSZPR01MB9394
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/nzp9AFGd8cECE4ub8tCa7mlY3dQ>
Subject: Re: [Uri-review] Request for Review and Registration of New URI Scheme "ai"
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review/>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jan 2024 04:15:35 -0000

Hello IS4,

On 2024-01-01 05:16, IS4 wrote:
> Hello,
> 
> with all due respect to Collin (and pardon me if I am mistaken), I have 
> the feeling his responses were written partially or fully by GPT (based 
> on my experience, but https://gptzero.me/ has the same feeling) which 
> might explain why they are written in a bit generic style and it is hard 
> (at least to me) to understand the content.
> 
> That being said, I do find value in AI-related URI schemes, and I can 
> imagine some that would fit the purpose of URIs better, such as for 
> generative AI. As an example:
> 
> text.gen:?prompt=Give+me+a+list+of+10+reasons+why+URI+schemes+are+good&model=gpt-4
> 
> img.gen:?prompt=cat+sitting+on+a+table&model=stable-diffusion-v2
> 
> This clearly indicates the actual resource identified by the URI, which 
> is the text/image generated by a particular model. If a compatible 
> software is installed, it could automatically load the prompt and other 
> parameters and generate the output, or allow the user to tweak it. It 
> could be used in a "source URI" metadata attribute for images or 
> documents to encode how they were generated.

I'm not at all an AI expert (or even much of a user), but I thought I'd 
give GPTZero a try. Grabbing the text most close by, the above 
three-sentence paragraph, GPTZero gave an assessment of "3/3 sentences 
are likely AI generated.". Now (pardon me if I am mistaken), that would 
either indicate that you also used an AI system to generate (part of) 
your mail, or that GPTZero isn't really all that reliable :-).

On substance, I still don't see in what way accessing AI generators is 
in any way different from accessing e.g. the weather report. The later 
is also generated automatically, there are many parameters (location, 
date/time, Celsius/Fahrenheit,...), and HTTP has no problem transmitting 
it either as HTML for human consumption or in some other format. And the 
output format can easily be indicated by the Accept: HTTP header field.

Regards,   Martin.


> The issue is finding a common ground for every generative AI situation 
> that there is. The prompt is the shared parameter, but it may not be a 
> single string but a collection of strings or even structured messages 
> (e.g. with OpenAI chat-based roles "user", "system", "assistant"), there 
> may be a "negative prompt" too to adjust the weights in the opposite 
> direction, both of which are affected by a particular tokenization or 
> preprocessing mechanism, which might be bypassed if the tokens are 
> provided directly instead of text as the prompt. The model has to be 
> identified somehow too, not only the actual technology (GPT, Stable 
> Diffusion) but also the encoded weights (one common way is through a 
> hash, e.g. urn:sha256:...), and then there is the myriad of 
> technology-specific parameters, or even other external resources 
> necessary for generating the proper output (such as images or masks for 
> img2img). Maybe this is the right time to come up with a baseline 
> scheme, but it would definitely have to be very extensible to be 
> considered in future technologies.
> 
> I have started a discussion for Stable Diffusion 
> <https://github.com/AUTOMATIC1111/stable-diffusion-webui/discussions/14405> to see if there is a need for such a scheme in the first place.
> 
> IS4
> 
> On 24.10.2023 17:12, Graham Klyne wrote:
>> Hi Collin,
>>
>> I'm struggling to understand what is being proposed.  I have some 
>> questions, which somewhat overlap with concerns raised by Ted and Martin:
>>
>> 1. Would the intended goals be better served by a MIME content type 
>> registration, since the proposal seems to be about the nature of the 
>> data transmitted rather than the means of transmission?  I am really 
>> not sure; e.g., see (4) below.  For example, considering "The `ai` 
>> scheme is aimed at enabling real-time or near-real-time communication 
>> for streaming data among generative Artificial Intelligence (A.I.) 
>> applications and protocols.", I'm wondering if the existing ws: 
>> protocol coupled with new content-types specific to AI models might 
>> serve your needs.  With reference to "novel communication paradigms", 
>> I am also wondering if elements of RTSP might be applicable.
>>
>> 2. Why does this need to be a URI?  In what contexts might it be used 
>> where some other URI scheme might also be used?  If there are none, 
>> isn't it just a private-use string that happens to look like a URI?
>>
>> 3. What resource is actually identified by such a URI?  Most URI 
>> schemes are associated with some kind of mechanism (executable or 
>> administrative or something else) that associates a URI with some 
>> resource that it denotes.  Some schemes are associated with particular 
>> wire protocols (http, https, ftp, ws, etc.), where the identified 
>> resource is something that can be interacted with using said 
>> protocol.  Other schemes are associated by some non-executable 
>> mechanism, such as administrative delegation (e.g. urn) or as a 
>> constructed unique identifier (e.g. ni). In thinking about these 
>> questions, a touchstone I sometimes use is: what do I expect to happen 
>> if this URI is dereferenced (e.g., when used as an @href link in an 
>> HTML document, and the link is clicked)? Commonly, what one expects is 
>> that some representation of the identified resource may be returned.
>>
>> 4. What kinds of interaction with identified resources are possible or 
>> expected?  Are there interactions that are specific to AI applications 
>> that aren't allowable or implementable using existing schemes?
>>
>> There don't need to be definitive answers to these questions, but I 
>> find it helps to think about such issues to understand how a new URI 
>> scheme might sit with the wider World Wide Web architecture.
>>
>> #g
>>
>>
>> On 10/10/2023 03:06, Collin Paran wrote:
>>> Ted and Martin,
>>>
>>> I sincerely appreciate the detailed feedback from both of you! Your 
>>> insights are invaluable in refining the "ai" URI scheme proposal to 
>>> ensure it aligns with established guidelines and serves its intended 
>>> purpose effectively. I have taken the time to review a few of the 
>>> concerns raised and provided responses below:
>>>
>>> 1. General Data vs. AI Data:
>>>      - I understand the point Martin has raised regarding the 
>>> universality of protocols like HTTP and WS, which are agnostic to the 
>>> type of data they carry. The primary motivation behind proposing a 
>>> specific URI scheme for AI data is to facilitate specialized 
>>> communication needs of generative AI applications, especially with 
>>> the advent of AI photonic compute and laser-based communications 
>>> which could offer novel communication paradigms.
>>>
>>> 2. Applicability Beyond AI:
>>>      - I agree with the suggestion that if a new protocol surfaces 
>>> from the AI communication needs, it should not be limited to AI but 
>>> should be useful for other applications as well. I will reconsider 
>>> the naming of the URI scheme to reflect a broader scope.
>>>
>>> 3. Authority Information:
>>>      - The initial proposal lacked authority information, which is 
>>> crucial for identifying the party making the data available and 
>>> ensuring data from multiple parties can be accommodated. I will work 
>>> on including authority information in the URI scheme to address this 
>>> concern.
>>>
>>> 4. Scheme Name:
>>>      - The suggestion to consider a more descriptive or unique scheme 
>>> name like "wsai:" or "aiws:" is well taken. I will explore 
>>> alternative naming options that encapsulate the essence of the 
>>> protocol while not being overly restrictive to AI.
>>>
>>> 5. Grammar and Security Considerations:
>>>      - As earlier mentioned in response to Ted's feedback, I will 
>>> work on providing ABNF definitions for the various components of the 
>>> URI scheme, and outline the security considerations as required by 
>>> RFC 7595.
>>>
>>> 6. Engagement with the Community:
>>>      - I am open to further discussions and feedback from the 
>>> community to ensure the proposal meets the necessary standards and 
>>> caters to the intended use cases effectively. I'm committed to making 
>>> any necessary revisions based on the community's feedback.
>>>
>>> 7. Registry and Token Standardization:
>>>      - In line with Ted's feedback, I'm considering the establishment 
>>> or adoption of registries for common models, actions, and AI types to 
>>> foster common understanding and ensure the URI scheme serves its 
>>> purpose effectively.
>>>
>>> I am looking forward to further discussions on the mailing list and 
>>> appreciate the time and effort you both have put into reviewing the 
>>> proposal and providing insightful feedback.
>>>
>>> Thanks again.
>>>
>>> Respectfully,
>>>
>>> Collin
>>> collin@professai.com
>>>
>>>> On 10/09/2023 5:28 PM MDT Martin J. Dürst <duerst@it.aoyama.ac.jp> 
>>>> wrote:
>>>>
>>>>   Hello Collin, others,
>>>>
>>>> A few more comments on top of Ted's, written in a somewhat more direct
>>>> style.
>>>>
>>>> It's unclear to me why AI data is in any way special. Protocols such as
>>>> HTTP or WS don't care what data they carry, and data shouldn't care 
>>>> what
>>>> protocols it's been carried by. As an example, Web Sockets is used (I
>>>> guess) for search results, for stock price data, for gaming data, 
>>>> and so
>>>> on, but there's no need for anything other than a ws: scheme. Same 
>>>> for http.
>>>>
>>>> On the other hand, if AI would surface the need for a new protocol,
>>>> there's no need to limit this to AI; there's a high chance that such a
>>>> protocol may be useful for other applications, too. In that case, the
>>>> scheme name "ai" would be inappropriate.
>>>>
>>>> Your scheme proposal doesn't contain any kind of authority information
>>>> (that would usually be some domain name). So it's unclear how data 
>>>> could
>>>> be made available by multiple parties, or how the party making the data
>>>> available could be identified. This is different both from
>>>> "type-of-generative-ai" and from "specific-model".
>>>>
>>>> [Of course, it might be the case that this is only intended for the use
>>>> by a single party providing data, but that's not what URI schemes 
>>>> are for.]
>>>>
>>>> If indeed there is a need for an application-specific URI scheme for 
>>>> AI,
>>>> that may not be limited to your proposal. It would therefore be
>>>> premature to use such a short scheme name for this specific proposal;
>>>> maybe "wsai:" or "aiws:" or something along these lines would be more
>>>> appropriate (assuming that there's a need for an application-specific
>>>> URI scheme at all, which I strongly doubt (see my first point)).
>>>>
>>>> Regards,   Martin.
>>>>
>>>> On 2023-10-07 14:34, Collin Paran wrote:
>>>>> Dear IANA and URI Review Mailing List Members,
>>>>>
>>>>> I am writing to request a review and registration of a new URI 
>>>>> Scheme, "ai", designed for facilitating communication in generative 
>>>>> A.I. applications. The scheme is inspired by WebSockets and allows 
>>>>> the passing of JSON data for streaming words, video data, or images 
>>>>> between generative A.I. entities.
>>>>>
>>>>> Please find below the URI Scheme Registration Template as per the 
>>>>> guidelines provided in RFC 4395.
>>>>>
>>>>> URI Scheme Name: ai
>>>>>
>>>>> Status: Provisional
>>>>>
>>>>> URI Scheme Syntax:
>>>>>       * 
>>>>> `ai://<type-of-generative-ai>/<specific-model>/<action>?<parameters>`
>>>>> URI Scheme Semantics:
>>>>>       * The `ai` scheme is aimed at enabling real-time or 
>>>>> near-real-time communication for streaming data among generative 
>>>>> Artificial Intelligence (A.I.) applications and protocols.
>>>>> Encoding Considerations:
>>>>>       * UTF-8 encoding for multilingual support and binary format 
>>>>> for multimedia data encapsulated in JSON objects.
>>>>> Applications/Protocols that use this URI scheme name:
>>>>>       * Generative A.I. applications and protocols requiring 
>>>>> real-time or near-real-time communication for streaming data.
>>>>> Interoperability Considerations:
>>>>>       * Compatibility with existing WebSocket implementations and a 
>>>>> standard JSON format for data communication.
>>>>> Security Considerations:
>>>>>       * Usage of Artificial Intelligence Secure (AIS) which is also 
>>>>> interoperable with wss (WebSocket Secure) for encrypted 
>>>>> communication and authentication mechanisms for authorized access.
>>>>> Contact:
>>>>>       * Collin Paran, collin@professai.com mailto:collin@professai.com
>>>>> Author/Change Controller:
>>>>>       * Collin Paran, collin@professai.com mailto:collin@professai.com
>>>>> References:
>>>>>       * Pending public release.
>>>>> I am looking forward to receiving feedback from the community and I 
>>>>> am open to making any necessary revisions to ensure the `ai` scheme 
>>>>> aligns with the established guidelines and standards. I am also 
>>>>> eager to engage in discussions on the `uri-review@ietf.org` mailing 
>>>>> list and other relevant forums as appropriate.
>>>>>
>>>>> Thank you for your time and consideration.
>>>>>
>>>>> Warm regards,
>>>>>
>>>>> Collin Paran
>>>>> collin@professai.com
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Uri-review mailing list
>>>>> Uri-review@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/uri-review
>>> _______________________________________________
>>> Uri-review mailing list
>>> Uri-review@ietf.org
>>> https://www.ietf.org/mailman/listinfo/uri-review
>>
> 
> _______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review