Subject: [vwrap] Activity for charter: Proxies, Gateways, BSD, GPL...

From: Dzonatas Sol <[email-masked]>
Date: Wed, 11 May 2011 13:22:22 -0700

I'm fascinated with XML2RFC editor more for arithmetic simulation than 
just virtual land farms. They both can lead into accessible arithmetic 
computation. This has been quite the mushroom piece, yet there is no 
easy way to just hand people the experience of the requirements between 
BSD code and GPL code, and present all the ramifications with given 
experience, and how to navigate back the peace in standards.

I "think" we should limit VWRAP to proxies and gateways. With that, we 
should also assume original assets are not transferred upon request. If 
not, how to achieve that goal.

Note: BSD versus GPL debates are out of scope (and so is any anxiety 
induction of the same effect).

As Morgaine pointed out, there is disparity between the groups, so 
without prejudice I picked these two in order for us to straw-man the 
flow between IETF-VWRAP-BSD and IETF-VWRAP-GPL, and document that flow 
with XML2RFC. We are not dumb about this, so please no .

The flow of BSD to GPL is easier than GPL to BSD. I don't think that is 
as obvious, however ICANN's recent move to allow trademarks to overtake 
.net domains does provide useful means to accomplish that goal even 
within RFC nature.

Simply, for example, we can proxy or gateway the email address 
"agent@region©site™" to [email-masked] by default from ICANN's 
spawned flow. This provides backwards compatibility with plain text RFCs 
and forward compatibility with XML2RFC.

If we also include arithmetic atomicals formatter (or such arithmetic 
patterns) that 3D games have taken for granted then we can cancel 
anxiety in the above two flows.

Imagine two media regions. The first media region allows only BSD 
content with ambiguous context. The second media region allows only GPL 
context with default GPL content.

Content-Type: Message; license=...

If we write XML2RFC.NET then we can quantize the fallacies of the 
proxies and gateways between the two media types, and achieve similar 
affect of the previous charter. We need some kind of default intent for 
non-arithmetic flows that do not apply to the above for the first 
obvious fallacy, which may be summarized as for polymerization of 
outstanding license issues.

No date set for this kind of milestone. I figure any BSD to GPL proxy 
and can default the "Expiration:" date with exceptions upon trademarks.

Does that make the economy easier?

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 11 May 2011 16:06:49 -0700

I should also note here something that may be unfamiliar in context 
versus content in accessibility issues. There are now not only kinetic 
devices that can view and gather motion data as there are also external 
headgear devices that sense areas of brain activity data. Those devices 
are one the consumer market now. The point here is the capability to 
communicate in other forms of speech or mime without spoken words, and, 
yes, we can achieve independence.

Let me know if that sounds quantum far.

On 05/11/2011 01:22 PM, Dzonatas Sol wrote:
> easy way to just hand people the experience of the requirements 
> between BSD code and GPL code, and present all the ramifications with 
> given experience, and how to navigate back the peace in standards.
>
> should also assume original assets are not transferred upon request. 
> If not, how to achieve that goal.
>
> The flow of BSD to GPL is easier than GPL to BSD. I don't think that 
> is as obvious, however ICANN's recent move to allow trademarks to 
> overtake .net domains does provide useful means to accomplish that 
> goal even within RFC nature.
>
> spawned flow. This provides backwards compatibility with plain text 
> RFCs and forward compatibility with XML2RFC.
>
> content with ambiguous context. The second media region allows only 
> GPL context with default GPL content.
>
> affect of the previous charter. We need some kind of default intent 
> for non-arithmetic flows that do not apply to the above for the first 

--

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 11 May 2011 18:34:02 -0700

Others questioned me about this activity off-list.

Please, considered that people do not like to explain the full scale of 
disability issues over and over to every incidence of new layman that 
have not experienced such disabilities themselves (or aware of their 
own). People write standards for engineering quality, and it seems 
people often get that process backwards.

This is why I suggest the XML2RFC.NET as an example to help in this 
issue. We can use our own viewers and tools to lexically analyze 
standards and the process. We don't assume one size fits all, so I use 
the oxymoron "poly-scale" as something exists that best fits meaning on 
any scale.

Somehow, I get the common complaint that two monomers do not belong in 
physical simulations. I disagree because this is the ordinary world and 
not some metaphysical game.

On 05/11/2011 04:06 PM, Dzonatas Sol wrote:
> devices that can view and gather motion data as there are also 
> external headgear devices that sense areas of brain activity data. 
> Those devices are one the consumer market now. The point here is the 
> capability to communicate in other forms of speech or mime without 
> spoken words, and, yes, we can achieve independence.
>
>> I'm fascinated with XML2RFC editor more for arithmetic simulation 
>> than just virtual land farms. They both can lead into accessible 
>> arithmetic computation. This has been quite the mushroom piece, yet 
>> there is no easy way to just hand people the experience of the 
>> requirements between BSD code and GPL code, and present all the 
>> ramifications with given experience, and how to navigate back the 
>> peace in standards.
>>
>> I "think" we should limit VWRAP to proxies and gateways. With that, 
>> we should also assume original assets are not transferred upon 
>> request. If not, how to achieve that goal.
>>
>> flow between IETF-VWRAP-BSD and IETF-VWRAP-GPL, and document that 
>> flow with XML2RFC. We are not dumb about this, so please no .
>>

--