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

[IS4 <[e-mail]>]

Hello Martin
> 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 :-).
That's how statistical methods behave... still there is a difference 
between one flagged paragraph out of the whole text, and 100% text 
flagged. :-)
> 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.

You are right, there is no difference, which is why there already is 
"weather:" used in the wild (but not registered). Of course there is 
also "geo:" where you could easily link to Google Maps via HTTP instead, 
and a couple of others. The point of my idea was not to mask HTTP behind 
a new scheme, but to provide one that could be handled by an arbitrary 
compatible local application without any specific transport or content 
requirements. Right now you cannot link to a Stable Diffusion-generated 
resource since it runs locally on the computer as a web server on an 
arbitrary port, and there are also local GPT-based chatbots. Here HTTP 
is an app-specific/implementation detail.

IS4

> 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
>>>> [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
>>>
>>
>> _______________________________________________
>> Uri-review mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/uri-review