Re: Field Information

Oh clarify:


the mib-depot link should only be there IF the oid was found inside an
SNMP packet of course.




On 5/11/06, ronnie sahlberg <[email protected]> wrote:
> ACK.
>
> A feature to link hf fields to URLs would be very very useful and
> should not be limited to only OIDs.
>
>
> It would be nice with a generic api where one could link arbitrary
> hf_fields and/or values to arbitrary URLs.
>
> Would something similar to the PROTO_ITEM_SET_GENERATED macro be a
> better solution here?
> PROTO_ITEM_SET_URL ?
> To explicitely set the URL for a specific field somewhere  (for
> example to send  them to
> http://wiki.ethereal.com/SMB2/How_ImpersonatingLevel_Really_works_and_what_it_means
> )
>
>
> It might also be useful with a generic framework how to handle URLs
> for fields where there is no explicit PROTO_ITEM_SET_URL
>
> I.e.
> IF there is a PROTO_.. for this field THEN
>     go to that URL
> FI
> then also
> Switch(type){
> case FT_OID:
>  send them to alvestrand...oidvalue
>        or send them to mib-depot
>
>
> That might require that you register multiple context specific entries
> for each field
> Maybe something like having the popup dialog showing
> "AlgorithmIdentifier"   that links to wiki.ethereal.com   due to PROTO_...
> "Relevant RFC" that links to www.rfc-editor.org  also explicitely set by
> PROTO_
>
> "Alvestrand OID repository"  since this is a FT_OID
> "Mib Depot" also since this is a FT_OID and it might give us the actual
> mib.
>
>
> with the two last entries since type was FT_OID and preferences are
> set to "If type==FT_OID  then add these two links"
>
>
>
> we should ofcourse first check with the people of those external sites
> if it is ok to link our app to their site by the default preferences
> sicne there are milions of ethereal users and it would be very rude to
> ethereal their websites. :-(
>
>
>
>
> On 5/10/06, Ulf Lamping <[email protected]> wrote:
> > Graeme Lunt wrote:
> > > I have just checked the change in to provide the "Field Information"
> > context
> > > menu item (18125).
> > > I've added the function to oid_resolv.[ch] rather than packet-ber.[ch]
> as
> > > you suggested.
> > > However this means the URL template is not (currently) configurable as
> I
> > > didn't know where "OID" preferences should appear. Any suggestions?
> > > For now the URL template is fixed to the www.alvestrand.no site (which
> > > contain links to the elibel site).
> > >
> > Hmmm, I'm a bit disappointed by your current solution as it is very
> > specialized. To quote my previous mail:
> >
> > "I would think to have a clean mechanism to set a specific help URL
> > corresponding to a protocol tree item is the more important part for
> now."
> >
> > Well, your implementation is the opposite:
> >
> > - "Field Information" suggests a general purpose mechanism, but it's
> > (currently?) limited in effect to the FT_OID fields so for most Ethereal
> > users pretty useless
> > - No one else can add URLs in the way you've implemented it, as it would
> > require to add a new FT_... value (which would be a very bad idea only
> > for this reason)
> > - the "Field" in "Field Information" is just duplicated information ->
> > better: "Related Information"?
> > >
> > > I have another change (which I haven't checked in) that introduces a
> new
> > > field type for URIs (FT_URI) . This allows the new "Field Information"
> > menu
> > > item to then bring up the indicated location. My particular interest is
> > the
> > > URI form of a GeneralName which is used in a number of X.509
> certificate
> > > extensions.
> > >
> > > But is a URI field type a sensible addition?
> > >
> > I don't see a need for a FT_URI. This would make it impossible to attach
> > a URL to an existing proto_item (e.g. a FT_UINT8). A better idea might
> > be to use a FI_URI, working much like the FI_GENERATED flags. Or am I
> > wrong here and this should really be dealt like the FT_NUM?
> >
> > So the way you've implemented it, the whole thing is pretty much
> incomplete.
> >
> > Regards, ULFL
> > _______________________________________________
> > Ethereal-dev mailing list
> > [email protected]
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
>