[grobj] FW: [Fwd: Re: Problem statement] - 6th out of 7

[Sheng Jiang <[e-mail]>]

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 6th out of 7.

Regards,

Sheng

> -----Original Message-----
> From: Sheng Jiang [mailto:[e-mail]] 
> Sent: Friday, January 22, 2010 6:53 AM
> To: Dan Wing
> Cc: 'Simon Perreault'; 'Brian E Carpenter'
> Subject: Re: [Fwd: Re: [grobj] Problem statement]
> 
> At the end of this email.
> 
> Sheng
> >
> >> -----Original Message-----
> >> From: Simon Perreault [mailto:[e-mail]]
> >> Sent: Wednesday, January 20, 2010 4:22 PM
> >> To: Sheng Jiang
> >> Cc: Brian E Carpenter; Dan Wing
> >> Subject: Re: [Fwd: Re: [grobj] Problem statement]
> >>
> >> Sheng,
> >>
> >> Thanks for your comments. I reply inline below.
> >>
> >>
> >> Brian,
> >>
> >> I just noticed that there is new text in the introduction 
> mentioning 
> >> ICE and "SuperICE". Thank you for that. I think it is needed to 
> >> understand GROBJ's role.
> >>
> >>
> >> On 01/20/2010 05:08 PM, Sheng Jiang wrote:
> >>> Can we forget about ALL at the beginning stage? We should 
> focus on 
> >>> necessary information for most cases we count so far and
> >> then make the
> >>> GROBJ extensiable for further use. If we can agree on this,
> >> we can sit
> >>> down discussion what the nessary information is and in 
> which cases.
> >>
> >> Yes. I don't think this change would affect the protocol 
> at all. It's 
> >> just a mindset change about how to use GROBJ, not what a GROBJ is.
> >>
> >>>> I don't understand R3. How can we be sure that such a
> >> Reference item
> >>>> "can be
> >>>> used to find a path to the referred entry"? In my
> >> understanding, an IP
> >>>> address
> >>>> doesn't fit this requirement because we often cannot find
> >> a path (or
> >>>> we find the
> >>>> wrong path) for e.g. RFC1918 addresses.
> >>>
> >>> Again, we cannot sure at all. From the view of the 
> constructor of a 
> >>> GROBJ, it just selects the most useful item from its 
> pwespective. We 
> >>> make the best efforts, it may not work out at the end.
> >>
> >> That's also my understanding. That's why I don't understand R3. ;)
> >>
> >>>> I don't understand why R4 is needed, and I cannot imagine
> >> a protocol
> >>>> that would
> >>>> pass this test.
> >>>
> >>> My understanding for this R4 is that we are going to 
> define a single 
> >>> universal format. And the discription of its options is
> >> independent from
> >>> network situations.
> >>
> >> I agree with the "universal format" idea, although I would 
> prefer to 
> >> say that a GROBJ is a "generic" format. The 
> "generalization" of ICE 
> >> is what interests me.
> >>
> >> What puzzles me is why you would want to forward this at all. Sure 
> >> the forwardee will be able to interpret the content, since it's a 
> >> generic format, but will he be able to use it as the 
> forwarder could? 
> >> The reachability of the reference items contained in it 
> will probably 
> >> be different when going from the forwarder to the forwardee.
> >>
> >> Anyway, I think the idea of R4 would be better captured if 
> it simply 
> >> said that a GROBJ is a free-standing protocol, embeddable, but not 
> >> necessarily embedded, into another.
> >>
> >> Side question: will it have a MIME type?
> >
> > I am one of the dis-believers in the "unified GROBJ 
> format", because 
> > someone coding in XML will naturally prefer XML; coding in 
> ASN.1 will 
> > prefer ASN.1, coding in A/V pairs will prefer A/V pairs (which is 
> > essentially what SDP, and thus ICE, are using for their 
> encoding), and 
> > so on.
> >
> > Sure, a MIME type could be defined.  I wonder if it would 
> contain A/V 
> > pairs, though, as application/sdp does, or if it would 
> contain XML.  
> > Or something else, like a base64 version of some binary protocol.
> >
> > I differ from both Brian and Sheng on this point, but I 
> don't see much 
> > value in having One Unified Format for GROBJ; rather, an extensible 
> > XML format (for XML protocols) can be a template used for other 
> > protocols (one might imagine a gaming application or 
> something wanting 
> > to use GROBJ, and wanting a really tight binary encoding.  
> Maybe even 
> > with some compression using Huffman-like encoding of common GROBJ 
> > stuff, or zip, or what-have-you to send the fewest bits over the 
> > wire).
> 
> 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.
> 
> 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. 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.
> 
> Cheers,
> 
> Sheng
>