IETF Logo Mail Archive

Re: [MMUSIC] comments on draft-even-mmusic-application-token-01

Martin Thomson <martin.thomson@gmail.com> Sun, 27 October 2013 20:59 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DFE21E805F for <mmusic@ietfa.amsl.com>; Sun, 27 Oct 2013 13:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.939
X-Spam-Level:
X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_54=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OoalHuADb7P for <mmusic@ietfa.amsl.com>; Sun, 27 Oct 2013 13:59:55 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id BB15311E82AA for <mmusic@ietf.org>; Sun, 27 Oct 2013 13:59:54 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id b13so5705436wgh.3 for <mmusic@ietf.org>; Sun, 27 Oct 2013 13:59:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tdlnx3yebf7j6s7b8+qzfQILu5R/8j480DvRNMxFmL8=; b=t20rfe4w6Zm21kIfKKR55OZXmmVEVVCQqipKADYe/sL+QGITzWhr7QNWKE6QwZUK4U HCuOkHp4CCuzTDLmgfmcAAM+sNnsMDC19i/9AqTzNloig3FI+PT9AIP6KJ58rAb1De40 ndYYOnwsJvUmFv6IcflEqifPt7X80UqBq1I/0lm2sdb6YDGlIgqj0UW4Qysb0YOHD784 xPXMrPOTnXiLBb/ENo5+QMZcFvQp75ZvH2VrYkstBtYqd79snA2KfS37VgZWCNSmIT3K f5YvAgYuNzRWCJtdy8/rHN1x2ZubKS4MaKWR2VEcQnRiFr5N2mAFMNpLGdjBGsgHzUJz mtHg==
MIME-Version: 1.0
X-Received: by 10.180.37.114 with SMTP id x18mr531036wij.64.1382907587945; Sun, 27 Oct 2013 13:59:47 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Sun, 27 Oct 2013 13:59:47 -0700 (PDT)
In-Reply-To: <526D5CDD.40805@alum.mit.edu>
References: <526D5CDD.40805@alum.mit.edu>
Date: Sun, 27 Oct 2013 13:59:47 -0700
Message-ID: <CABkgnnVekG9bDbO7mvNPcKHH1w3JmvKTcT2K=D1-ERW-vr2GLA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: text/plain; charset="UTF-8"
Cc: Jonathan Lennox <jonathan@vidyo.com>, IETF MMUSIC WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Oct 2013 20:59:56 -0000

In addition to absent colons, the examples use a variety of uppercase
and lowercase characters.  Consistency would be helpful, unless the
intent is to highlight the fact that ABNF permits these to be in mixed
case.  (RFC 4566 is silent on the subject, so I assume that a=appid is
equivalent to a=ApPId, following RFC 5234; I'd rather that weren't the
case, but that seems to be the intent at least).

I'm not sure about the assertion regarding 1-1 correspondence between
appid and SSRC.  Putting the fact that SSRC can change aside, I
believe that the intent is to label the source, which can manifest as
multiple SSRCs.

Editorial: This document needs a serious proofread.  The spelling
seems right, but I'm continually being distracted by poor grammar as I
read through.  Doublespacing all the examples is annoying too.

On 27 October 2013 11:35, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> Hi. Doing my pre-meeting reading. A few comments on this. Otherwise it looks
> good to me.
>
> Many examples use a=appid and a=recv-appid without the colon.
>
> Section 3.1.3:
>
>       appid-attribute = "recv-appID:" token
>
>       ; The base definition of "attribute" is in [RFC4566].
>
>       ; (It is the content of "a=" lines.)
>
> The comments are spurious here - there is no attribute.
>
> ISTM it would be helpful to have an explicit specification of how this
> relates to RTP. IIUC, its something like the following:
>
> - an RTP session MAY have one or more appid tokens
> - at any point in time each appid token maps to at most
>   one stream (SSRC) within the session.
> - *new* appid:ssrc mappings MAY be initialized via SDP
> - new appid:ssrc mappings MAY be initialized via receipt
>   of the new RTPC SDES message or header extension
> - existing appid:ssrc mappings MAY be updated via
>   receipt of the new RTCP SDES message or header extension.
>
> I'm not sure about what is supposed to happen if a new O/A defines a mapping
> in conflict with an existing one. I *think* it probably is to be ignored.
>
>         Thanks,
>         Paul
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

v2.23.0 | Report a Bug | By Email