Subject: [grobj] FW: [Fwd: Re: Problem statement] - 3rd out of 7

From: Sheng Jiang <[email-masked]>
Date: Thu, 28 Jan 2010 17:30:50 +0800

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 3rd out of 7.

Regards,

Sheng

> -----Original Message-----
> From: Simon Perreault [mailto:[email-masked]] 
> Sent: Thursday, January 21, 2010 8:22 AM
> 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?
> 
> Thanks,
> Simon
> -- 
> DNS64 open-source   --> http://ecdysis.viagenie.ca
> STUN/TURN server    --> http://numb.viagenie.ca
> vCard 4.0           --> http://www.vcarddav.org