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

[IS4 <[e-mail]>]

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.

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
>> [e-mail]
>>
>>> On 10/09/2023 5:28 PM MDT Martin J. Dürst <[e-mail]> 
>>> 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, [e-mail] mailto:[e-mail]
>>>> Author/Change Controller:
>>>>       * Collin Paran, [e-mail] mailto:[e-mail]
>>>> 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 `[e-mail]` mailing 
>>>> list and other relevant forums as appropriate.
>>>>
>>>> Thank you for your time and consideration.
>>>>
>>>> Warm regards,
>>>>
>>>> Collin Paran
>>>> [e-mail]
>>>>
>>>>
>>>> _______________________________________________
>>>> Uri-review mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/uri-review
>> _______________________________________________
>> Uri-review mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/uri-review
>