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

Regards,

Sheng

> -----Original Message-----
> From: Sheng Jiang [mailto:[e-mail]] 
> Sent: Friday, January 22, 2010 6:16 AM
> To: Simon Perreault
> Cc: Brian E Carpenter; Dan Wing
> Subject: Re: [Fwd: Re: [grobj] Problem statement]
> 
> 
> 
> Simon Perreault write:
> > 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 guess we all share the same understanding here. The 
> description may need to reword here. Brian?
> 
> >>> 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.
> 
> en... This is a real good question. I don't have very clear 
> answer. I have cases in my mind for one hop forwarding. See A 
> want something from B, then B said, I don't have it, but you 
> can get it from C. And B forward a GROBJ of C to A.
> 
> I am not sure the above case can be extended to multi hop 
> forwarding. It become iteration. B tells A, C may know where 
> to get your content (let's say the really answer is on D). 
> Then, it is A talk to C directly to know it should talk to D later.
> 
> Unless the GROBJ is distributed with some certain 
> information, for example, "if you want information of Avatar, 
> go this GROBJ", there is no motivation/benefit to forward it 
> more than once.
> 
> > 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.
> 
> Agree.
> 
> > Side question: will it have a MIME type?
> 
> Will discuss this in reply for Dan's email.
> 
> Sheng
>