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

[Graham Klyne <[e-mail]>]

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

-- 
Graham Klyne
mailto:[e-mail]
http://www.ninebynine.org
Mastodon: @[e-mail]
GitHub/Skype: @gklyne