[grobj] FW: [Fwd: Re: Problem statement] - 4th 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 4th out of 7.

Regards,

Sheng

> -----Original Message-----
> From: Dan Wing [mailto:[e-mail]] 
> Sent: Thursday, January 21, 2010 9:54 AM
> To: 'Simon Perreault'; 'Sheng Jiang'
> Cc: 'Brian E Carpenter'
> Subject: RE: [Fwd: Re: [grobj] Problem statement]
> 
>  
> 
> > -----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).
> 
> 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.
> 
> IMHO.
> 
> -d
>