Hi! I think there is a good idea to add InstantMessenger (ICQ, Jabber, Skype, etc) contact field in person, organization, irt objects. Is there any support? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hi, Max Tulyev wrote:
Hi!
I think there is a good idea to add InstantMessenger (ICQ, Jabber, Skype, etc) contact field in person, organization, irt objects.
Is there any support?
uhm, actually, i doubt that. The idea sucks a little, somehow :-) I'd rather support something like a SIP-URI as additional contact, because that's at least some kind of well-accepted standard right now, in contrast to all the myriads of IM protocols. For SIP there's INOC-DBA already, so it's proven to be useful. If at all, i'd support something like that as addtional contact - IM doesn't make sense IMHO. ...but on a second thought, why a SIP address if there's phone: and ENUM... Bottom lime: No real support from me for that. Reason: The back of my head itches when i think about it. No good sign. Or is there any reason why one would want to use IM for RIPE-releated stuff i might find useful? BTW: There's IRC, too :-) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
On 11.08.2007 at 16:38, Sascha Lenz wrote:
I think there is a good idea to add InstantMessenger (ICQ, Jabber, Skype, etc) contact field in person, organization, irt objects. I'd rather support something like a SIP-URI as additional contact,
So why not go completely abstract and support an URI field, like URI: <role> <URI> [optional] Where <role> is a set of peviously defined words. This would also allow easy extension later. e.g. URI: abuse im:icq:1234567890 URI: sales sip:sales@isp.net URI: info http://www.myisp.net/info/ Cheers Hendrik -- Hendrik T. Voelker HTV5-RIPE EMEA Registrar Team Verizon Deutschland GmbH Sebrathweg 20 D-44149 Dortmund GERMANY http://www.verizonbusiness.com/de/ tel +49-231-972-1565 fax +49-231-972-2587 PubKey 1024D/92479A5D EC1B 76F2 D69D 11C6 2611 5CD1 5269 9351 9247 9A5D
Hi,
So why not go completely abstract and support an URI field, like
URI: <role> <URI> [optional]
Where <role> is a set of peviously defined words. This would also allow easy extension later.
e.g.
URI: abuse im:icq:1234567890 URI: sales sip:sales@isp.net URI: info http://www.myisp.net/info/
That would indeed make putting contact info in the db very flexible. I don't think we should put the role in the URI field, because there already is a role object in the db, and two ways to specify a role will probably cause a bit of a mess. I think adding the URI field to the irt, role and person objects would be enough to structure the information. Otherwise I think this a good idea to consider. - Sander
On 13 Aug 2007, at 09:59, Sander Steffann wrote:
I don't think we should put the role in the URI field, because there already is a role object in the db,
One word: two concepts, IIUC. Hendrik's idea of giving a hint as to the appropriate use of the URL seems to me both useful, and to have nothing to do with the existing 'role' object. Use of a different word to describe this hint in the URI field would perhaps make things clearer, thus: URI: <purpose (or whatever)> <URI> [optional] [multiple] A 'role' object could then carry several URL fields, each for a different purpose [function/scope/aspect: pick a fav and stick with it] /Niall
On Mon, Aug 13, 2007 at 10:31:10AM +0100, Niall O'Reilly wrote:
existing 'role' object. Use of a different word to describe this hint in the URI field would perhaps make things clearer, thus:
URI: <purpose (or whatever)> <URI> [optional] [multiple]
hmm, why not go with a generic "attribute:" field then and stick all semantics in a free form optional label? -Peter
Peter, free text already is using now - it is "remarks" field. Only aim in formalizing syntax is allow scripts to be made for easy work with that. Peter Koch wrote:
On Mon, Aug 13, 2007 at 10:31:10AM +0100, Niall O'Reilly wrote:
existing 'role' object. Use of a different word to describe this hint in the URI field would perhaps make things clearer, thus:
URI: <purpose (or whatever)> <URI> [optional] [multiple]
hmm, why not go with a generic "attribute:" field then and stick all semantics in a free form optional label?
-Peter
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hi Peter,
On Mon, Aug 13, 2007 at 10:31:10AM +0100, Niall O'Reilly wrote:
existing 'role' object. Use of a different word to describe this hint in the URI field would perhaps make things clearer, thus:
URI: <purpose (or whatever)> <URI> [optional] [multiple]
hmm, why not go with a generic "attribute:" field then and stick all semantics in a free form optional label?
Well, I think the semantics are clear for this: Make one field type to put contact information in, without having to make a different field type for every type of communication. You still have the 'how to contact someone' semantics, without fixing it to one type of communication. The alternative (if we want different types of contact information) is to add a "sip:" field, an "icq:" field, a "jabber:" field, a "skype:" field, etc. I personally would prefer a single field with a flexible uri than all these different types. As long as the semantics of the field remain 'how to contact someone' ofcourse. - Sander
Hi, Sander Steffann wrote:
existing 'role' object. Use of a different word to describe this hint in the URI field would perhaps make things clearer, thus:
URI: <purpose (or whatever)> <URI> [optional] [multiple] hmm, why not go with a generic "attribute:" field then and stick all semantics in a free form optional label?
Well, I think the semantics are clear for this: Make one field type to put contact information in, without having to make a different field type for every type of communication.
You still have the 'how to contact someone' semantics, without fixing it to one type of communication. The alternative (if we want different types of contact information) is to add a "sip:" field, an "icq:" field, a "jabber:" field, a "skype:" field, etc.
I personally would prefer a single field with a flexible uri than all these different types. As long as the semantics of the field remain 'how to contact someone' ofcourse.
like i mentioned before, i probably would support a more "standard" thing like SIP, and a generic "uri:" option woulnd't be too bad. I can't say anything against it, no problems. Why not. The idea is somewhat appealing to me, although i still think, phone+email is enough for everyone :-) But i'm totally against anything like "im:" or even "icq: .. skype:.." This still sounds stupid. If at all, we should go with the generic version to make everyone happy. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
HI Bear in mind that any contact attribute needs to be parsable to ensure the syntax of the allowable URIs is correct. Otherwise we will end up with even more bad data in the database. Verifying contact data has been talked about on numerous occasions. If this is introduced at some point in the future is it possible to verify different types of URI? Currently "phone:" is mandatory and "e-mail:" is optional. Suggestions to reverse this have been resisted in the past. The main argument being that many people feel that a phone number should always be available as a last or quick option to contact someone. Another argument is that many people do not want to enter a valid e-mail address because of the risk of spam. The same may apply to IM. These concerns need to be taken into account if you are to introduce new methods of contact. Also expressing mandatory and optional methods in a single attribute could be more difficult. On a more general point, the RIPE NCC receives many complaints about invalid contact data now. Do we want to increase the diversity of contact data when the quality of what we have is so poor? Denis Walker Database Group RIPE NCC Sascha Lenz wrote:
Hi,
Sander Steffann wrote:
existing 'role' object. Use of a different word to
describe this
hint in the URI field would perhaps make things clearer, thus:
URI: <purpose (or whatever)> <URI> [optional] [multiple]
hmm, why not go with a generic "attribute:" field then and stick all semantics in a free form optional label?
Well, I think the semantics are clear for this: Make one field type to put contact information in, without having to make a different field type for every type of communication.
You still have the 'how to contact someone' semantics, without fixing it to one type of communication. The alternative (if we want different types of contact information) is to add a "sip:" field, an "icq:" field, a "jabber:" field, a "skype:" field, etc.
I personally would prefer a single field with a flexible uri than all these different types. As long as the semantics of the field remain 'how to contact someone' ofcourse.
like i mentioned before, i probably would support a more "standard" thing like SIP, and a generic "uri:" option woulnd't be too bad. I can't say anything against it, no problems. Why not. The idea is somewhat appealing to me, although i still think, phone+email is enough for everyone :-)
But i'm totally against anything like "im:" or even "icq: .. skype:.." This still sounds stupid. If at all, we should go with the generic version to make everyone happy.
SIP would be a good generic form of contact, I agree. Perhaps, taking things one step further the RIPE NCC could set up an INOC-DBA thing among its members, by providing the actual sip phones and setting up a SIP server, like registro.br does for anyone who is issued an ASN by them in Brazil. It being a "closed" set of phones (the device, or SIP sw, needs to be registered with the server, it addresses most of the spam problem and it ties together the set of people who would benefit from operational coordination capabilities) Joao Damas On 13 Aug 2007, at 05:30, Sascha Lenz wrote:
Hi,
Sander Steffann wrote:
existing 'role' object. Use of a different word to describe this hint in the URI field would perhaps make things clearer, thus:
URI: <purpose (or whatever)> <URI> [optional] [multiple] hmm, why not go with a generic "attribute:" field then and stick all semantics in a free form optional label? Well, I think the semantics are clear for this: Make one field type to put contact information in, without having to make a different field type for every type of communication. You still have the 'how to contact someone' semantics, without fixing it to one type of communication. The alternative (if we want different types of contact information) is to add a "sip:" field, an "icq:" field, a "jabber:" field, a "skype:" field, etc. I personally would prefer a single field with a flexible uri than all these different types. As long as the semantics of the field remain 'how to contact someone' ofcourse.
like i mentioned before, i probably would support a more "standard" thing like SIP, and a generic "uri:" option woulnd't be too bad. I can't say anything against it, no problems. Why not. The idea is somewhat appealing to me, although i still think, phone +email is enough for everyone :-)
But i'm totally against anything like "im:" or even "icq: .. skype:.." This still sounds stupid. If at all, we should go with the generic version to make everyone happy.
-- ====================================================================== == = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ====================================================================== ==
On 13 Aug 2007, at 21:43, Joao Damas wrote:
SIP would be a good generic form of contact, I agree. Perhaps, taking things one step further the RIPE NCC could set up an INOC- DBA thing among its members, by providing the actual sip phones and setting up a SIP server, like registro.br does for anyone who is issued an ASN by them in Brazil. It being a "closed" set of phones (the device, or SIP sw, needs to be registered with the server, it addresses most of the spam problem and it ties together the set of people who would benefit from operational coordination capabilities)
Why would it be more advantageous to have a RIPE NCC only system, rather than join the existing INOC-DBA or registro.br systems? Regards, Leo Vegoda
There is no reason why those systems can't inter-operate (establish a SIP relationship) but I wonder if either registro.br or nic.br would take on the burden of adding all of the RIPE NCC membership onto their systems. the RIPE NCC has established contact procedures with its members that would make it easier for both the system administrator (the NCC or some party if contracts to) and the users to keep things working. Joao On 13 Aug 2007, at 23:04, Leo Vegoda wrote:
On 13 Aug 2007, at 21:43, Joao Damas wrote:
SIP would be a good generic form of contact, I agree. Perhaps, taking things one step further the RIPE NCC could set up an INOC- DBA thing among its members, by providing the actual sip phones and setting up a SIP server, like registro.br does for anyone who is issued an ASN by them in Brazil. It being a "closed" set of phones (the device, or SIP sw, needs to be registered with the server, it addresses most of the spam problem and it ties together the set of people who would benefit from operational coordination capabilities)
Why would it be more advantageous to have a RIPE NCC only system, rather than join the existing INOC-DBA or registro.br systems?
Regards,
Leo Vegoda
Max, On Sat, Aug 11, 2007 at 04:56:53PM +0300, Max Tulyev wrote:
I think there is a good idea to add InstantMessenger (ICQ, Jabber, Skype, etc) contact field in person, organization, irt objects.
Is there any support?
I think this idea makes sense, if there are support roles that actually use IM. Does anyone IM (and I include IRC here) for general support though? -- Shane
Shane, A lot of companies around me does. I see the reasons to do that: 1. A lot of people have written English much better than spoken. 2. International (and somewhere even intercity) calls are expensive. 3. You always have history. You can show it or see again after a while. You can copy-paste something. 4. It is convenient. It is much more interactive e-mail, but less interactive than phone call. You can do something else when talking via IM to somebody. Shane Kerr wrote:
Max,
On Sat, Aug 11, 2007 at 04:56:53PM +0300, Max Tulyev wrote:
I think there is a good idea to add InstantMessenger (ICQ, Jabber, Skype, etc) contact field in person, organization, irt objects.
Is there any support?
I think this idea makes sense, if there are support roles that actually use IM.
Does anyone IM (and I include IRC here) for general support though?
-- Shane
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
1. A lot of people have written English much better than spoken. 2. International (and somewhere even intercity) calls are expensive. 3. You always have history. You can show it or see again after a while. You can copy-paste something. 4. It is convenient. It is much more interactive e-mail, but less interactive than phone call. You can do something else when talking via IM to somebody.
some jabber software supports reasonable security. i.e. well-written clients properly check the server's cert and to c2s encryption to the server. a few really good clients will do e2e crypto using gpg keys or whatever. the gang of us who maintain our racks in westin and ashburn use jabber. i think of it as just another path. when things go badly, which paths will work and which not is often different than one expects. randy
Randy Bush wrote: [...]
the gang of us who maintain our racks in westin and ashburn use jabber.
Fair enough, but do you publicly advertise that poc? Or - the other way 'round - what are the spam protection capabilities of these mechanisms *if* made available publicly?
i think of it as just another path. when things go badly, which paths will work and which not is often different than one expects.
randy
Wilfried.
the gang of us who maintain our racks in westin and ashburn use jabber. Fair enough, but do you publicly advertise that poc?
of course. you will note that i am sufficiently old fashioned that whois gives you direct contact info
Or - the other way 'round - what are the spam protection capabilities of these mechanisms *if* made available publicly?
you think it is ripe's business to specify that? i think of it as none of your damned business. randy
Max Tulyev wrote:
Hi!
I think there is a good idea to add InstantMessenger (ICQ, Jabber, Skype, etc) contact field in person, organization, irt objects.
Is there any support?
At first glance from tjhis end: NO. How about using the remarks filed for a while, and then let's see who is in a position to publicly advertise just another path of (potentially) intrusive push communiation? Wilfried.
A lot of people does. I can even do some script for analyze and answer you with percentage, if I have access to db with person objects. Wilfried Woeber, UniVie/ACOnet wrote:
Max Tulyev wrote:
Hi!
I think there is a good idea to add InstantMessenger (ICQ, Jabber, Skype, etc) contact field in person, organization, irt objects.
Is there any support?
At first glance from tjhis end: NO.
How about using the remarks filed for a while, and then let's see who is in a position to publicly advertise just another path of (potentially) intrusive push communiation?
Wilfried.
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Max Tulyev wrote:
A lot of people does.
yes, but wilfred does not. so don't waste your time. randy
Hi, On Sun, Aug 12, 2007 at 11:54:53AM -1000, Randy Bush wrote:
Max Tulyev wrote:
A lot of people does. yes, but wilfred does not. so don't waste your time.
This is not how RIPE policy making works - and you know that, so please don't play the bitter old man... Wilfried has voiced some concerns that people should think about, before putting yet another potentially unused thing into the database that the community and NCC gets to maintain for the next century. While we, in our team, also use IM (IRC) fairly extensively, personally I would *not* want to publish this "globally", as I have some worries about the contacts being misused for IM SPAM. (Which is why Wilfried was asking you whether you have anti-spam measures, and which, but that question seems to have been misunderstood). Max: this topic is controversial (obviously :) ), so the normal approach is to bring it to discussion on this list (which you did) or on the RIPE meeting (easier to get feedback quickly), and if you think "enough people like it", formulate a more formal proposal how this could look like and give it to the DB WG for discussion + decision... Gert Doering -- Internet User -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
participants (13)
-
Denis Walker -
Gert Doering -
Hendrik T Voelker -
Joao Damas -
Leo Vegoda -
Max Tulyev -
Niall O'Reilly -
Peter Koch -
Randy Bush -
Sander Steffann -
Sascha Lenz -
Shane Kerr -
Wilfried Woeber, UniVie/ACOnet