[grobj] Referrals

Hi everybody,

This list has been pretty quiet. However, there is an intention to
move forward before IETF 78. It seems pretty clear that we need
a very precise problem statement to act as the basis for an agreed
requirements analysis.

So, this is a renewed call for comments on the problem statement
aspect of draft-carpenter-grobj-reqts-00. Then we can try to
distil a separate problem statement draft out of it.

The previous discussion is of course archived at
http://www.ietf.org/mail-archive/web/grobj/current/maillist.html

Please ask anyone you think might be interested to join this list.

    Brian Carpenter

On 2010-01-28 22:34, Sheng Jiang wrote:
> FYI, there were some private discussion regarding to the new GROBJ problem
> statement draft. Resend it to the grobj maillist with permission. Wish to
> light wider discussion.
> 
> There are 7 emails in this thread. This is 7th out of 7.
> 
> Regards,
> 
> Sheng
> 
>> -----Original Message-----
>> From: Dan Wing [mailto:dwing@cisco.com] 
>> Sent: Friday, January 22, 2010 7:30 AM
>> To: 'Sheng Jiang'
>> Cc: 'Simon Perreault'; 'Brian E Carpenter'
>> Subject: RE: [Fwd: Re: [grobj] Problem statement]
>>
>>> When I said "One Unified Format", I did not mean a single 
>> format. What 
>>> I mean is a Unified framework, which any applications can 
>> look at it 
>>> and at least understand this is useful for it or not.
>> Ok.
>>
>>> It just likes that we draft a table. We define: first 
>> column is name, 
>>> second is age, third is professional, blabla. That is a 
>> unified table.
>>> You fill it in different language, English, France, 
>> Chinese... oh, I 
>>> guess, we need to add a zero column before name - language (maybe 
>>> expressed in number).
>>>
>>> Then, the table is unified and reusable. It gets meanings among 
>>> different languages. The table can work when people speack 
>> different 
>>> languages. No need to redesign another or multiple tables for the 
>>> similar purpose. Otherwise, A, we may get multiple tables 
>> to make it 
>>> different to understand each other, B, the experience 
>> cannot be passed 
>>> among different languages, a new language or org may starts 
>> from zero 
>>> and consider every detail by itself.
>>>
>>>> We don't have many application "A" (e.g., XMPP) talking to 
>>>> application "B" (e.g., SIP) today.  There's lots of reasons
>>> for that.
>>>> Incompatible referrals is only one reason -- and a small reason, 
>>>> really; referrals, to date, have been simple.  Yet, there 
>> still is 
>>>> not a lot of application-A talking to application-B using 
>> referrals.
>>>> So having a unique format, which is a natural for each 
>> application, 
>>>> is not harmful.
>>> I agree what you said: applicants rarely talk to each other now. 
>>> However, this is not about APP-A talk to APP-B using GROBJ. 
>>> It is when
>>> APP-B designs its traversal/referral function/protocol, it reuses 
>>> APP-A's traversal/referral experience.
>> Sounds great.
>>
>>> That's the whole motivation of
>>> GROBJ here: to avaid APP-B to start its own ICE design from 
>> zero. With 
>>> GROBJ, APP-B designers just fill a framework with their favorite 
>>> language and follow a set of rules, then things can work 
>> out for them.
>>> They don't need to read and fully understand hundred pages of ICE 
>>> document. They can easily make their applications, client a 
>> of APP-B 
>>> and client b of APP-B, connect to each other directly.
>> Ok.
>>
>> Thanks.
>> -d
>>
>>
>>> Cheers,
>>>
>>> Sheng
> 
> _______________________________________________
> grobj mailing list
> grobj@ietf.org
> https://www.ietf.org/mailman/listinfo/grobj
> 