Re: [ppsp] next step of tracker document

zhangyunfei <zhangyunfei@chinamobile.com> Mon, 10 September 2012 08:15 UTC

Return-Path: <zhangyunfei@chinamobile.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CE921F8567 for <ppsp@ietfa.amsl.com>; Mon, 10 Sep 2012 01:15:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.623
X-Spam-Level:
X-Spam-Status: No, score=-98.623 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLtOmKQmTfvs for <ppsp@ietfa.amsl.com>; Mon, 10 Sep 2012 01:15:59 -0700 (PDT)
Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5A90321F84EF for <ppsp@ietf.org>; Mon, 10 Sep 2012 01:15:57 -0700 (PDT)
Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 378BBE50E; Mon, 10 Sep 2012 16:15:57 +0800 (CST)
Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 2CD04E520; Mon, 10 Sep 2012 16:15:57 +0800 (CST)
Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012091016155463-21745 ; Mon, 10 Sep 2012 16:15:54 +0800
Date: Mon, 10 Sep 2012 16:15:47 +0800
From: zhangyunfei <zhangyunfei@chinamobile.com>
To: 'Xiajinwei' <xiajinwei@huawei.com>, ppsp <ppsp@ietf.org>
References: <A8219E7785257C47B75B6DCE682F8D2F2BFC8660@SZXEML511-MBS.china.huawei.com>
X-Priority: 3 (Normal)
X-Mailer: Foxmail 7.0.1.85[cn]
Mime-Version: 1.0
Message-ID: <2012091016154731655619@chinamobile.com>
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-10 16:15:54, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-10 16:15:56, Serialize complete at 2012-09-10 16:15:56
Content-Type: multipart/alternative; boundary="----=_001_NextPart178628145136_=----"
X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19174.005
X-TM-AS-Result: No--35.091-7.0-31-10
X-imss-scan-details: No--35.091-7.0-31-10;No--35.091-7.0-31-10
X-TM-AS-User-Approved-Sender: No;No
X-TM-AS-User-Blocked-Sender: No;No
Subject: Re: [ppsp] next step of tracker document
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: zhangyunfei <zhangyunfei@chinamobile.com>
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ppsp>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Sep 2012 08:16:00 -0000

Hi Jinwei,
    For point1, when you mention peer IP address is optional to identify the peer. Do you mean it's *feasible* or a *suitable candidate*? If it were the case, I agree with you at this point.
   For  point2, the consensus in last IETF on this draft should be "concentrating on the message* if I don't remember wrong. Regarding the encoding part, you can ask Wes and Fabio for more comments.

Thanks.
BR
Yunfei 



zhangyunfei

From: Xiajinwei
Date: 2012-09-10 15:51
To: ppsp@ietf.org
Subject: [ppsp] next step of tracker document
Hi all,
 
I notice there are two concerns in tracker document from IETF 84 meeting minutes, in order to accelerate the processing of this document, I’d like to show my understanding firstly. Hope we can push this work forward and get consensus as soon as possible.
 
1, Peer ID is global unique to identify the Peer, from this point of view, the Peer IP address is optional to identify the Peer. IMO it could be useful in a closed swarm scenario, in which the peers (both leech and seed) are behind the NAT and they can share the media content in the local domain (e.g., enterprise inside). If I am right, I suggest some text should be given to describe this scenario.
 
2, Encoding xml or binary experiences a long discussion, different person have different preference. One compromise is encoding and decoding XML in binary, the related context is specified in W3C Efficient XML Interchange Working Group or in ISO/IEC 23001-Part 1 ”Binary MPEG format for XML”. Therefore, encoding both XML and HTTP in binary format are implementation options. The draft can have a couple of paragraphs providing those options in terms of implementation notes.
 
Any comments?
 
Thank you!
 
 
Jinwei