Subject: RE: is IDNA an OPES?

From: "Abbie Barbir" <[email-masked]>
Date: Wed, 5 Mar 2003 08:45:16 -0500

jfcm,

I would like you to really have a definition of the IDNA and then compare it
to see if it fits within our charter.

We have a very focused charter and we have to stick with it.

This is not to say that good ideas are not in IDNA.

After we complete the first set of deliverable, the time will arrive when we
need to recharter.
These ideas can be used in that activity.

thanks

abbie

> -----Original Message-----
> From: jfcm [mailto:[email-masked]] 
> Sent: Tuesday, March 04, 2003 7:21 PM
> To: [email-masked]
> Subject: is IDNA an OPES? 
> 
> 
> 
> I would like to know if you consider the IDNA process as an 
> OPES or not. It 
> changes data in the flow from the user's point of view. The 
> reason why I 
> ask is that the plug-in used to support IDNA may be used for 
> other purposes 
> as well (as a dispatcher), support OPES management and be a 
> candidate for 
> callout protocol - for example to support DNS like services. 
> An example is 
> the "go:" scheme ftp://ftp.rfc-editor.org/in-notes/rfc3368.txt
> jfc
> 
>

---

From: "Abbie Barbir" <[email-masked]>
Date: Fri, 7 Mar 2003 13:45:06 -0500

hi,

+1

abbie

> From: The Purple Streak, Hilarie Orman [mailto:[email-masked]] 
> Sent: Friday, March 07, 2003 1:21 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: is IDNA an OPES?
> 
> 
> 
> A proxy can be co-located with an application, using the same 
> protocol as if they were are different machines.  However, 
> this doesn't seem to be a preferred implementation method, 
> probably due to the overhead involved.  The more usual path 
> is that someone defines an API that can be implemented 
> through direct subroutine calls, and then extends this to 
> work with RPC's for remotely located services.  The advantage 
> being, of course, that one can write the callout service once 
> and have it run locally or remotely.
> 
> I think most browsers are already extensible, in their own 
> ways, and while it would be gratifying to have them switch to 
> using a standard method that is compatible with OPES servces, 
> I don't see much reason for that to happen.  Our focus for 
> the IETF is on services that benefit from running remotely - 
> because the services are more efficient when amortized over 
> many connections or some other engineering reason.  
> 
> Surely there are other kinds of services that could run 
> either remotely or locally, or services that are best run 
> locally, but these will have to grow and flourish without 
> diverting the attention of this WG.  It's fine to discuss 
> such possibilities, but keep in mind that they cannot be the 
> motivating examples for design decisions.
> 
> Hilarie
> 
> 
>

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 7 Mar 2003 14:47:50 -0700 (MST)

On Fri, 7 Mar 2003, jfcm wrote:

> >My understanding is that IDNAs make HTTP messages malformed.
>
> The IDNA has been designed so it does not do that.

Now I am confused: International domain names, as entered by users,
would make HTTP messages malformed because HTTP addresses are
ASCII-based, right? It is the proposed IDNA conversion that makes the
addresses well-formed for old protocols. Since you asked whether OPES
can be used to perform IDNA conversions, OPES would have to deal with
raw IDNAs as input, right? Raw IDNAs make HTTP messages malformed.
Malformed messages may not be able to reach OPES agents, even if those
agents can handle them. Yet, you are saying that there is no problem.

What am I missing?

Alex.