Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C881111096 for ; Tue, 13 May 2014 21:22:21 +0000 (UTC) Received: (qmail 32720 invoked by uid 500); 13 May 2014 19:35:41 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 32675 invoked by uid 500); 13 May 2014 19:35:41 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 32667 invoked by uid 99); 13 May 2014 19:35:41 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 May 2014 19:35:41 +0000 Received: from localhost (HELO mail-oa0-f50.google.com) (127.0.0.1) (smtp-auth username jross, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 May 2014 19:35:41 +0000 Received: by mail-oa0-f50.google.com with SMTP id i7so984690oag.9 for ; Tue, 13 May 2014 12:35:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.22.227 with SMTP id h3mr44715516obf.36.1400009740620; Tue, 13 May 2014 12:35:40 -0700 (PDT) Received: by 10.60.79.230 with HTTP; Tue, 13 May 2014 12:35:40 -0700 (PDT) In-Reply-To: References: <53723859.1090508@redhat.com> <537248DA.4040402@redhat.com> Date: Tue, 13 May 2014 15:35:40 -0400 Message-ID: Subject: Re: AMQP 1.0 connection property names From: Justin Ross To: "users@qpid.apache.org" Cc: dev@activemq.apache.org Content-Type: multipart/alternative; boundary=001a11c2fd6c459bd504f94d2bc8 --001a11c2fd6c459bd504f94d2bc8 Content-Type: text/plain; charset=UTF-8 On Tue, May 13, 2014 at 3:25 PM, Robbie Gemmell wrote: > > > > > Out of curiosity, is there any interest in offering the command line (a > la > > "process_command_line")? The arguments passed to a process can often be > > used to distinguish it from others quickly. > > > > That might open up some issues, requiring consideration if anything on the > command line needs sanitized. > You're right. We can't assume the information in the command line is safe to put on the wire. --001a11c2fd6c459bd504f94d2bc8--