Subject: [APPS-REVIEW] Review of draft-rosenberg-sip-app-media-tag-01
From: Julian Reschke <[email-masked]>
To: [email-masked]
Date: Thu, 26 Jul 2007 16:05:35 +0200
List-Id: Applications Review List <apps-review.ietf.org>

Hi,

I have read draft-rosenberg-sip-app-media-tag-01 
(<http://www.ietf.org/internet-drafts/draft-rosenberg-sip-app-media-tag-01.txt>). 
Saying "reviewed" would be overstating things, because I have no 
knowledge whatsoever of SIP.

That being said, here are two comments:

Editorial: I think the RFC Editor prefers symbolic references nowadays. 
Also, RFC4735 reserves media types for use in examples; maybe these 
should be used here.

Content: was it considered to allow this mechanism for any media type, 
instead of restricting it to "application"?

Such as

;+sip.mediatypes="application/greatgame,application/wboard,example/foo"

instead of

            ;+sip.app-subtype="greatgame,wboard"

?

Best regards, Julian

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Wed, 25 Jul 2007 11:28:01 -0500
From: Chris Newman <[email-masked]>
To: [email-masked]
Subject: [APPS-REVIEW] Re: Last Call comment: draft-rosenberg-sip-app-media-tag-01.txt

Can someone review this document considering Ted's concern?

                - Chris

Ted Hardie wrote on 7/24/07 18:34 -0500:

> During the discussion of this draft in today's sipping meeting,
> Jonathan's description of the document made me realize that
> the problem this describes is more general than the solution
> described.  A broader solution that encompasses other potential
> uses of content negotiation seems to me in order.  I would be
> willing to review and contribute to such  a generalization.
>
> I've cc'ed this to the APPs discuss list, to see if there are others
> on that list who similarly believe that this problem
> is larger and the solution could be as well.  I also encourage
> the APPs ADs to request review from APPs review team members
> with a background in content negotiation.
>
> 			regards,
> 				Ted Hardie
>
>
>

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Tue, 24 Jul 2007 19:44:19 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Cc: Mark Crispin <[email-masked]>
Subject: [APPS-REVIEW] Review of draft-crispin-collation-unicasemap-04.txt

Hi,
As requested I have reviewed draft-crispin-collation-unicasemap-04.txt on 
behalf of the Apps Area Review team.

Overall the document appears to be technically sound.

There are a couple of clarifications I would suggest:

Section 1, Para 1:

"All input is valid." - it is not clear that this refers to the validity 
test in 4790 as opposed to input to the tests described in the previous 
sentence. Suggested alternative: "The validity test operation always 
returns a valid result."

Even with that change, later the spec states that "strings in other 
character sets and/or encodings can not be used with this collation" so 
wouldn't those return an invalid response if used in the validity test? 
Same for invalid UTF-8 sequences?

Section 1, Para 5:
I would like to see a informative reference pointing to the current 
UnicodeData.txt file rather than just having the generic [UNICODE] 
reference.

Section 5, Para 6:
"The resulting two titlecased canonicalized UTF-8 strings are then treated 
as in i;octet for equality and ordering."

shouldn't that also mention substring? Suggested alternative:

"The resulting two titlecased canonicalized UTF-8 strings are then treated 
as in i;octet for equality, substring and ordering operations."

Other than that looks good. This should proceed to publication asap as it 
is needed by a lot of apps.

-- 
Cyrus Daboo

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Tue, 24 Jul 2007 08:25:23 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: [APPS-REVIEW] Apps review dinner Monday -- photos
Cc: 

--==========8BFFEC7DC928B4F24C25==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Here are the photos from my camera.  Looks like the waitress tried to leave Eric 
out, and succeeded almost completely.

Barry

--==========8BFFEC7DC928B4F24C25==========
Content-Type: image/jpeg; name="IMG_1427.JPG"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="IMG_1427.JPG"; size=265717

--==========8BFFEC7DC928B4F24C25==========
Content-Type: image/jpeg; name="IMG_1428.JPG"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="IMG_1428.JPG"; size=227857

--==========8BFFEC7DC928B4F24C25==========
Content-Type: image/jpeg; name="IMG_1429.JPG"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="IMG_1429.JPG"; size=223090

--==========8BFFEC7DC928B4F24C25==========
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

--==========8BFFEC7DC928B4F24C25==========--

From: Kurt Zeilenga <[email-masked]>
Subject: Re: [APPS-REVIEW] Apps review dinner tonight (Monday)
Date: Mon, 23 Jul 2007 19:12:58 -0500
To: Eric Burger <[email-masked]>
Cc: [email-masked]

On Jul 23, 2007, at 5:00 PM, Eric Burger wrote:

> It is very easy to get to the Vermillion.  Go north on State  
> Street, past the Chicago river.  Second left is West Hubbard.   
> Vermillion is #10.

http://maps.google.com/maps?li=d&hl=en&f=d&saddr=10+W+Hubbard+St, 
+Chicago,+IL+60610+(Vermilion) 
&iwstate1=dir:from&geocode=17869093339801792851,41.890067,-87.628371&iwl 
oc=1&dq=vermillion&cid=41890067,-87628371,6102758675892345252

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

From: Lisa Dusseault <[email-masked]>
Subject: Re: [APPS-REVIEW] Apps review dinner tonight (Monday)
Date: Mon, 23 Jul 2007 18:19:36 -0500
To: Eric Burger <[email-masked]>
Cc: [email-masked]

--===============1043840278==
Content-Type: multipart/alternative; boundary=Apple-Mail-28-767145942

--Apple-Mail-28-767145942
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

I count 13 RSVPs.

Lisa

On Jul 23, 2007, at 5:00 PM, Eric Burger wrote:

> I have made reservations for ten people, in case we co-opt some  
> more folks.  I do need to know if we will have more defections,  
> however.
>
> I will be leaving from the main reception area at 8:10pm sharp.
>
> It is very easy to get to the Vermillion.  Go north on State  
> Street, past the Chicago river.  Second left is West Hubbard.   
> Vermillion is #10.
>
> For those going to the social tomorrow night, that is just two  
> blocks beyond House of Blues.
>
>
>
>
>
> On 7/23/07 8:35 AM, "Lisa Dusseault" <[email-masked]> wrote:
>
>> Eric recommended a Tapas place for dinner tonight, yum.  I'm  
>> planning to walk there, leaving shortly after ECRIT ends,  
>> expecting to get there before 8:30.
>>
>> I have RSVPs from Dave Crocker, Barry Leiba, John Klensin, Kurt  
>> Zeilenga, Chris, Eric and myself.   It's not a closed invite list  
>> in the slightest,  but let me know about additional people so we  
>> can have a rough number idea for the restaurant.
>>
>> Lisa
>>
>> Begin forwarded message:
>> From: Eric Burger <[email-masked] <mailto:[email-masked]> >
>> Date: July 22, 2007 8:33:41 PM CDT
>> To: Lisa Dusseault <[email-masked]  
>> <mailto:[email-masked]> >
>> Subject: Dinner Monday
>>
>> 3/4-mile up N. State: Vermillion
>> http://www.thevermilionrestaurant.com <http:// 
>> www.thevermilionrestaurant.com/> /
>> http://www.frommers.com/destinations/chicago/D54779.html
>> Figure $25 - $35pp
>>
>>
>> _______________________________________________
>> APPS-REVIEW mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/apps-review
>
>
> Notice: This email message, together with any attachments, may  
> contain information of BEA Systems, Inc., its subsidiaries and  
> affiliated entities, that may be confidential, proprietary,  
> copyrighted and/or legally privileged, and is intended solely for  
> the use of the individual or entity named in this message. If you  
> are not the intended recipient, and have received this message in  
> error, please immediately return this by email and then delete it.

--Apple-Mail-28-767145942
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">I count 13 RSVPs.<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Lisa</DIV><DIV><BR><DIV><DIV>=
On Jul 23, 2007, at 5:00 PM, Eric Burger wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"> <FONT =
face=3D"Verdana, Helvetica, Arial"><SPAN style=3D"font-size:12.0px">I =
have made reservations for ten people, in case we co-opt some more =
folks. =A0I do need to know if we will have more defections, =
however.<BR> <BR> I will be leaving from the main reception area at =
8:10pm sharp.<BR> <BR> It is very easy to get to the Vermillion. =A0Go =
north on State Street, past the Chicago river. =A0Second left is West =
Hubbard. =A0Vermillion is #10.<BR> <BR> For those going to the social =
tomorrow night, that is just two blocks beyond House of Blues.<BR> <BR> =
<BR> <BR> <BR> <BR> On 7/23/07 8:35 AM, "Lisa Dusseault" &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt; =
wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE type=3D"cite"><FONT =
face=3D"Verdana, Helvetica, Arial"><SPAN style=3D"font-size:12.0px">Eric =
recommended a Tapas place for dinner tonight, yum.=A0 I'm planning to =
walk there, leaving shortly after ECRIT ends, expecting to get there =
before 8:30.<BR> <BR> I have RSVPs from Dave Crocker, Barry Leiba, John =
Klensin, Kurt Zeilenga, Chris, Eric and myself.=A0 =A0It's not a closed =
invite list in the slightest,=A0 but let me know about additional people =
so we can have a rough number idea for the restaurant.=A0=A0<BR> <BR> =
Lisa<BR> <BR> Begin forwarded message:<BR> <B>From: </B><FONT =
color=3D"#001ED2">Eric Burger &lt;</FONT><FONT color=3D"#0020E2"><A =
href=3D"mailto:[email-masked]">[email-masked]</A></FONT> <A =
href=3D"mailto:[email-masked]">&lt;mailto:[email-masked]&gt;</A> <FONT =
color=3D"#001ED2">&gt;<BR> </FONT><B>Date: </B><FONT =
color=3D"#001ED2">July 22, 2007 8:33:41 PM CDT<BR> </FONT><B>To: =
</B><FONT color=3D"#001ED2">Lisa Dusseault &lt;</FONT><FONT =
color=3D"#0020E2"><A =
href=3D"mailto:[email-masked]">[email-masked]</A></FONT>=
 <A =
href=3D"mailto:[email-masked]">&lt;mailto:[email-masked]=
&gt;</A> <FONT color=3D"#001ED2">&gt;<BR> </FONT><B>Subject: <FONT =
color=3D"#001ED2">Dinner Monday<BR> </FONT></B><FONT =
color=3D"#001ED2"><BR> 3/4-mile up N. State: Vermillion<BR> </FONT><A =
href=3D"http://www.thevermilionrestaurant.com">http://www.thevermilionrest=
aurant.com</A> <A =
href=3D"http://www.thevermilionrestaurant.com/">&lt;http://www.thevermilio=
nrestaurant.com/&gt;</A> <FONT color=3D"#001ED2">/<BR> </FONT><A =
href=3D"http://www.frommers.com/destinations/chicago/D54779.html">http://w=
ww.frommers.com/destinations/chicago/D54779.html</A><BR> <FONT =
color=3D"#001ED2">Figure $25 - $35pp<BR> </FONT><BR> <BR> <HR =
align=3D"CENTER" size=3D"3" width=3D"95%"></SPAN></FONT><FONT =
size=3D"2"><FONT face=3D"Monaco, Courier New"><SPAN =
style=3D"font-size:10.0px">_______________________________________________=
<BR> APPS-REVIEW mailing list<BR> <A =
href=3D"mailto:[email-masked]">[email-masked]</A><BR> <A =
href=3D"https://www1.ietf.org/mailman/listinfo/apps-review">https://www1.i=
etf.org/mailman/listinfo/apps-review</A><BR> =
</SPAN></FONT></FONT></BLOCKQUOTE><FONT size=3D"2"><FONT face=3D"Monaco, =
Courier New"><SPAN style=3D"font-size:10.0px"><BR> </SPAN></FONT></FONT> =
  <BR> Notice:  This email message, together with any attachments, may =
contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  =
affiliated entities,  that may be confidential,  proprietary,  =
copyrighted  and/or legally privileged, and is intended solely for the =
use of the individual or entity named in this message. If you are not =
the intended recipient, and have received this message in error, please =
immediately return this by email and then delete =
it.</BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-28-767145942--

--===============1043840278==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

--===============1043840278==--

Date: Mon, 23 Jul 2007 17:00:03 -0500
Subject: Re: [APPS-REVIEW] Apps review dinner tonight (Monday)
From: Eric Burger <[email-masked]>
To: Lisa Dusseault <[email-masked]>, <[email-masked]>
Cc: 

--===============1667161256==
Content-type: multipart/alternative;
	boundary="B_3268054807_2286809"

--B_3268054807_2286809
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable

I have made reservations for ten people, in case we co-opt some more folks.
I do need to know if we will have more defections, however.

I will be leaving from the main reception area at 8:10pm sharp.

It is very easy to get to the Vermillion.  Go north on State Street, past
the Chicago river.  Second left is West Hubbard.  Vermillion is #10.

For those going to the social tomorrow night, that is just two blocks beyon=
d
House of Blues.

On 7/23/07 8:35 AM, "Lisa Dusseault" <[email-masked]> wrote:

> Eric recommended a Tapas place for dinner tonight, yum.=A0 I'm planning t=
o walk
> there, leaving shortly after ECRIT ends, expecting to get there before 8:=
30.
>=20
> I have RSVPs from Dave Crocker, Barry Leiba, John Klensin, Kurt Zeilenga,
> Chris, Eric and myself.=A0 =A0It's not a closed invite list in the slight=
est,=A0 but
> let me know about additional people so we can have a rough number idea fo=
r the
> restaurant.=A0=A0
>=20
> Lisa
>=20
> Begin forwarded message:
> From: Eric Burger <[email-masked] <mailto:[email-masked]> >
> Date: July 22, 2007 8:33:41 PM CDT
> To: Lisa Dusseault <[email-masked] <mailto:[email-masked]=
et> >
> Subject: Dinner Monday
>=20
> 3/4-mile up N. State: Vermillion
> http://www.thevermilionrestaurant.com <http://www.thevermilionrestaurant.=
com/>
> /
> http://www.frommers.com/destinations/chicago/D54779.html
> Figure $25 - $35pp
>=20
>=20
>=20
> _______________________________________________
> APPS-REVIEW mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/apps-review

Notice:  This email message, together with any attachments, may contain inf=
ormation  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entiti=
es,  that may be confidential,  proprietary,  copyrighted  and/or legally p=
rivileged, and is intended solely for the use of the individual or entity n=
amed in this message. If you are not the intended recipient, and have recei=
ved this message in error, please immediately return this by email and then=
 delete it.
--B_3268054807_2286809
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [APPS-REVIEW] Apps review dinner tonight (Monday)</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12.0px'>I=
 have made reservations for ten people, in case we co-opt some more folks. =
&nbsp;I do need to know if we will have more defections, however.<BR>
<BR>
I will be leaving from the main reception area at 8:10pm sharp.<BR>
<BR>
It is very easy to get to the Vermillion. &nbsp;Go north on State Street, p=
ast the Chicago river. &nbsp;Second left is West Hubbard. &nbsp;Vermillion =
is #10.<BR>
<BR>
For those going to the social tomorrow night, that is just two blocks beyon=
d House of Blues.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
On 7/23/07 8:35 AM, &quot;Lisa Dusseault&quot; &lt;[email-masked]&g=
t; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN ST=
YLE=3D'font-size:12.0px'>Eric recommended a Tapas place for dinner tonight,=
 yum.=A0 I'm planning to walk there, leaving shortly after ECRIT ends, expe=
cting to get there before 8:30.<BR>
<BR>
I have RSVPs from Dave Crocker, Barry Leiba, John Klensin, Kurt Zeilenga, C=
hris, Eric and myself.=A0 =A0It's not a closed invite list in the slightest=
,=A0 but let me know about additional people so we can have a rough number =
idea for the restaurant.=A0=A0<BR>
<BR>
Lisa<BR>
<BR>
Begin forwarded message:<BR>
<B>From: </B><FONT COLOR=3D"#001ED2">Eric Burger &lt;</FONT><FONT COLOR=3D"=
#0020E2">[email-masked]</FONT> <a href=3D"mailto:[email-masked]">&lt;mail=
to:[email-masked]&gt;</a> <FONT COLOR=3D"#001ED2">&gt;<BR>
</FONT><B>Date: </B><FONT COLOR=3D"#001ED2">July 22, 2007 8:33:41 PM CDT<BR=
>
</FONT><B>To: </B><FONT COLOR=3D"#001ED2">Lisa Dusseault &lt;</FONT><FONT C=
OLOR=3D"#0020E2">[email-masked]</FONT> <a href=3D"mailto:ldusseaul=
[email-masked]">&lt;mailto:[email-masked]&gt;</a> <FONT COLOR=3D"#=
001ED2">&gt;<BR>
</FONT><B>Subject: <FONT COLOR=3D"#001ED2">Dinner Monday<BR>
</FONT></B><FONT COLOR=3D"#001ED2"><BR>
3/4-mile up N. State: Vermillion<BR>
</FONT><a href=3D"http://www.thevermilionrestaurant.com">http://www.theverm=
ilionrestaurant.com</a> <a href=3D"http://www.thevermilionrestaurant.com/">=
&lt;http://www.thevermilionrestaurant.com/&gt;</a> <FONT COLOR=3D"#001ED2">=
/<BR>
</FONT><a href=3D"http://www.frommers.com/destinations/chicago/D54779.html"=
>http://www.frommers.com/destinations/chicago/D54779.html</a><BR>
<FONT COLOR=3D"#001ED2">Figure $25 - $35pp<BR>
</FONT><BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2">=
<FONT FACE=3D"Monaco, Courier New"><SPAN STYLE=3D'font-size:10.0px'>_______=
________________________________________<BR>
APPS-REVIEW mailing list<BR>
[email-masked]<BR>
https://www1.ietf.org/mailman/listinfo/apps-review<BR>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT SIZE=3D"2"><FONT FACE=3D"Monaco, Co=
urier New"><SPAN STYLE=3D'font-size:10.0px'><BR>
</SPAN></FONT></FONT>
</BODY>
</HTML>

<br>
Notice:  This email message, together with any attachments, may contain inf=
ormation  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entiti=
es,  that may be confidential,  proprietary,  copyrighted  and/or legally p=
rivileged, and is intended solely for the use of the individual or entity n=
amed in this message. If you are not the intended recipient, and have recei=
ved this message in error, please immediately return this by email and then=
 delete it.
--B_3268054807_2286809--

--===============1667161256==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

--===============1667161256==--

Date: Mon, 23 Jul 2007 14:00:21 -0500
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: [APPS-REVIEW] Apps review dinner tonight (Monday)
Cc: 
Reply-To: [email-masked]

Sorry.  I have a schedule conflict.  Have to go to a different dinner.

(Could have made Wed night for Apps, but lost that one.)

d/

Alexey Melnikov wrote:
> Lisa Dusseault wrote:
> 
>> Eric recommended a Tapas place for dinner tonight, yum.  I'm planning 
>> to walk there, leaving shortly after ECRIT ends, expecting to get 
>> there before 8:30.
>>
>> I have RSVPs from Dave Crocker, Barry Leiba, John Klensin, Kurt 
>> Zeilenga, Chris, Eric and myself.   It's not a closed invite list in 
>> the slightest,  but let me know about additional people so we can have 
>> a rough number idea for the restaurant. 
> 
> I will be coming as well.
> 
> 
> 
> _______________________________________________
> APPS-REVIEW mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/apps-review
> 

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Mon, 23 Jul 2007 20:37:53 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [APPS-REVIEW] Apps review dinner tonight (Monday)
Cc: [email-masked]

Lisa Dusseault wrote:

> Eric recommended a Tapas place for dinner tonight, yum.  I'm planning 
> to walk there, leaving shortly after ECRIT ends, expecting to get 
> there before 8:30.
>
> I have RSVPs from Dave Crocker, Barry Leiba, John Klensin, Kurt 
> Zeilenga, Chris, Eric and myself.   It's not a closed invite list in 
> the slightest,  but let me know about additional people so we can have 
> a rough number idea for the restaurant. 

I will be coming as well.

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

To: [email-masked]
From: Lisa Dusseault <[email-masked]>
Date: Mon, 23 Jul 2007 08:35:26 -0500
Cc: 
Subject: [APPS-REVIEW] Apps review dinner tonight (Monday)

--===============0944039886==
Content-Type: multipart/alternative; boundary=Apple-Mail-24-732096611

--Apple-Mail-24-732096611
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Eric recommended a Tapas place for dinner tonight, yum.  I'm planning  
to walk there, leaving shortly after ECRIT ends, expecting to get  
there before 8:30.

I have RSVPs from Dave Crocker, Barry Leiba, John Klensin, Kurt  
Zeilenga, Chris, Eric and myself.   It's not a closed invite list in  
the slightest,  but let me know about additional people so we can  
have a rough number idea for the restaurant.

Lisa

Begin forwarded message:
From: Eric Burger <[email-masked]>
Date: July 22, 2007 8:33:41 PM CDT
To: Lisa Dusseault <[email-masked]>
Subject: Dinner Monday

3/4-mile up N. State: Vermillion
http://www.thevermilionrestaurant.com/
http://www.frommers.com/destinations/chicago/D54779.html
Figure $25 - $35pp

--Apple-Mail-24-732096611
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Eric =
recommended a Tapas place for dinner tonight, yum.=A0 I'm planning to =
walk there, leaving shortly after ECRIT ends, expecting to get there =
before 8:30.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">I have RSVPs from Dave Crocker, Barry Leiba, John =
Klensin, Kurt Zeilenga, Chris, Eric and myself.=A0 =A0It's not a closed =
invite list in the slightest,=A0 but let me know about additional people =
so we can have a rough number idea for the restaurant.=A0=A0</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Lisa</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Begin forwarded message:</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><B>From: </B><FONT class=3D"Apple-style-span" =
color=3D"#001ED2">Eric Burger &lt;</FONT><A =
href=3D"mailto:[email-masked]"><FONT class=3D"Apple-style-span" =
color=3D"#0020E2">[email-masked]</FONT></A><FONT =
class=3D"Apple-style-span" color=3D"#001ED2">&gt;</FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><B>Date: </B><FONT class=3D"Apple-style-span" =
color=3D"#001ED2">July 22, 2007 8:33:41 PM CDT</FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><B>To: </B><FONT class=3D"Apple-style-span" =
color=3D"#001ED2">Lisa Dusseault &lt;</FONT><A =
href=3D"mailto:[email-masked]"><FONT class=3D"Apple-style-span" =
color=3D"#0020E2">[email-masked]</FONT></A><FONT =
class=3D"Apple-style-span" color=3D"#001ED2">&gt;</FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><B>Subject: </B><FONT class=3D"Apple-style-span" =
color=3D"#001ED2"><B>Dinner Monday</B></FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
min-height: 14px; "><FONT class=3D"Apple-style-span" =
color=3D"#001ED2"><BR></FONT></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT =
class=3D"Apple-style-span" color=3D"#001ED2">3/4-mile up N. State: =
Vermillion</FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"http://www.thevermilionrestaurant.com/">http://www.thevermilionres=
taurant.com</A><FONT class=3D"Apple-style-span" =
color=3D"#001ED2">/</FONT></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"http://www.frommers.com/destinations/chicago/D54779.html">http://w=
ww.frommers.com/destinations/chicago/D54779.html</A></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT class=3D"Apple-style-span" =
color=3D"#001ED2">Figure $25 - $35pp</FONT></DIV><DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><BR =
class=3D"khtml-block-placeholder"></DIV></BODY></HTML>=

--Apple-Mail-24-732096611--

--===============0944039886==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

--===============0944039886==--

Date: Wed, 18 Jul 2007 15:16:53 +0300
From: Miguel Garcia <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [APPS-REVIEW] Re: Review of draft-ietf-mmusic-file-transfer-mech-03

Hi Peter:

Thank you for taking your time to review the draft. We will address your
comments in the next version of the document.

See some inline discussion.

Peter Saint-Andre wrote:
> Review of: draft-ietf-mmusic-file-transfer-mech-03
> By:        Peter Saint-Andre
> Date:      2007-07-09
> 
> Eric Burger has asked me (as a member of Apps-Review team) to review the
> I-D referenced above. Please note that such reviews have no special
> weight within the Internet Standards Process. In completing this review,
> I have attempted to follow some relevant guidelines as well as examples
> of previous reviews, such as:
> 
> http://www.rfc-editor.org/rfc-editor/reviewer.guide.txt
> http://www1.ietf.org/mail-archive/web/apps-review/current/msg00019.html
> http://www1.ietf.org/mail-archive/web/apps-review/current/msg00028.html
> http://www1.ietf.org/mail-archive/web/apps-review/current/msg00029.html
> 
> Overall the document appears to be technically sound. Please take the
> following comments in the spirit of suggestions.
> 
> 1. The document contains numerous typographical and grammatical errors,
> which detract from the specification. I am sure that most of these From [email-masked] Thu Jul 19 08:32:42 2007
Date: Wed, 18 Jul 2007 15:16:53 +0300
From: Miguel Garcia <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked], [email-masked],
	[email-masked], [email-masked]
Subject: [APPS-REVIEW] Re: Review of draft-ietf-mmusic-file-transfer-mech-03

Hi Peter:

Thank you for taking your time to review the draft. We will address your
comments in the next version of the document.

See some inline discussion.

Peter Saint-Andre wrote:
> Review of: draft-ietf-mmusic-file-transfer-mech-03
> By:        Peter Saint-Andre
> Date:      2007-07-09
> 
> Eric Burger has asked me (as a member of Apps-Review team) to review the
> I-D referenced above. Please note that such reviews have no special
> weight within the Internet Standards Process. In completing this review,
> I have attempted to follow some relevant guidelines as well as examples
> of previous reviews, such as:
> 
> http://www.rfc-editor.org/rfc-editor/reviewer.guide.txt
> http://www1.ietf.org/mail-archive/web/apps-review/current/msg00019.html
> http://www1.ietf.org/mail-archive/web/apps-review/current/msg00028.html
> http://www1.ietf.org/mail-archive/web/apps-review/current/msg00029.html
> 
> Overall the document appears to be technically sound. Please take the
> following comments in the spirit of suggestions.
> 
> 1. The document contains numerous typographical and grammatical errors,
> which detract from the specification. I am sure that most of these would
>  be discovered by the RFC Editor team. However, in order to lighten
> their load and reduce the number of AUTH48 changes, I would suggest
> completing a thorough copy-edit before WGLC or IETF Last Call.

Ok. We'll do. If you happen to have some detailed changes that you
propose, please send them to me.

> 
> 2. The bullet list of requirements in Section 1 contains the normative
> term MUST. However, that term is reserved for normativity with regard to
> protocol implementations, not specification requirements. For details,
> see draft-peterson-informational-normativity.

Fixed

> 
> 3. In Section 1.1, the alternative of the SIP content indirection
> mechanism (RFC 4483) is considered. Although the document provides a
> list of difference between SIP content indirection and the defined file
> transfer mechanism, the document does not provide a clear set of
> guidelines to user agent developers in determining when it might be
> preferable to use SIP content indirection and when it might be
> preferable to use the defined file transfer mechanism.

Well, the draft can only briefly compare both mechanisms, and let
implementors decide which one to use or implement, depending on the
requirements the have. I have added the following sentence at the end of
the paragraph the compares the two mechanisms:

         The
	level of requirements in implementations decides which solution
	meets the requirements.

> 
> 4. In Section 1.1, the specification does not clearly explain why MSRP
> (draft-ietf-simple-message-sessions) is the preferred transport
> protocol. Furthermore, although the specification mentions that it is
> possible to use similar protocols in place of MSRP, the specification
> does not provide guidelines for choosing or developing such protocols.
> Such guidelines would be helpful to those who might re-use (or gateway
> to) the defined file transfer mechanism.

Fixed. I have added at the end of the indented text in Section 1.1:

             Essentially, such protocol should be able to
	    be negotiated on an SDP offer/answer exchange (<xref
	    target="RFC3264">RFC 3264 </xref>) and be able to carry
	    MIME objects between two endpoints.

> 5. Section 4 mentions that the transfer of multiple simultaneous files
> would require one SDP (RFC 4566) m= line per file. Might this result in
> large SDP descriptions in certain scenarios?

Yes. The issue is not new, there have been concerns in the MMUSIC WG
with respect the size of SDP, but not due to this draft, but due to the
long list of SDP extensions, which in many cases are needed. Well,
probably the solution to address these concerns (or relieve them) is to
use SIP and TCP. Although this won't solve the issue, perhaps it
mitigates the side effects.

Again, the size of SDP is an issue with or without this draft.

> 
> 6. Section 4 asserts that use of the defined file transfer mechanism to
> transfer multiple files "will not lead to excessive use of transport
> resources" because "multiple MSRP media streams can share a single
> transport layer connection". It strikes me that this assertion may not
> be realistic in deployments, depending on the number and size of files
> being transferred.

Why do you think this is not realistic? It is a common way of operation
in MSRP. There is the concept of a logical MSRP session and the concept
of a TCP connection. It is possible to instantiate several MSRP logical
sessions that share the same TCP connection.

I would say that a direct TCP connection between two endpoints could
share file transfer of several simultaneous files and instant message.
The same would apply for a TCP connection established towards an MSRP
relay.

> 
> 7. According to the ABNF in Section 6, there is no limit to the length
> of the filename string. Might this lead to excessively large SDP
> descriptions?

As indicated later, SDP is large with or without this draft. I don't
dare to put a limit, because this limit depends on mostly the operating
system. There is text suggesting to sanitize the received file name,
including cropping the name. But onwould
>  be discovered by the RFC Editor team. However, in order to lighten
> their load and reduce the number of AUTH48 changes, I would suggest
> completing a thorough copy-edit before WGLC or IETF Last Call.

Ok. We'll do. If you happen to have some detailed changes that you
propose, please send them to me.

> 
> 2. The bullet list of requirements in Section 1 contains the normative
> term MUST. However, that term is reserved for normativity with regard to
> protocol implementations, not specification requirements. For details,
> see draft-peterson-informational-normativity.

Fixed

> 
> 3. In Section 1.1, the alternative of the SIP content indirection
> mechanism (RFC 4483) is considered. Although the document provides a
> list of difference between SIP content indirection and the defined file
> transfer mechanism, the document does not provide a clear set of
> guidelines to user agent developers in determining when it might be
> preferable to use SIP content indirection and when it might be
> preferable to use the defined file transfer mechanism.

Well, the draft can only briefly compare both mechanisms, and let
implementors decide which one to use or implement, depending on the
requirements the have. I have added the following sentence at the end of
the paragraph the compares the two mechanisms:

         The
	level of requirements in implementations decides which solution
	meets the requirements.

> 
> 4. In Section 1.1, the specification does not clearly explain why MSRP
> (draft-ietf-simple-message-sessions) is the preferred transport
> protocol. Furthermore, although the specification mentions that it is
> possible to use similar protocols in place of MSRP, the specification
> does not provide guidelines for choosing or developing such protocols.
> Such guidelines would be helpful to those who might re-use (or gateway
> to) the defined file transfer mechanism.

Fixed. I have added at the end of the indented text in Section 1.1:

             Essentially, such protocol should be able to
	    be negotiated on an SDP offer/answer exchange (<xref
	    target="RFC3264">RFC 3264 </xref>) and be able to carry
	    MIME objects between two endpoints.

> 5. Section 4 mentions that the transfer of multiple simultaneous files
> would require one SDP (RFC 4566) m= line per file. Might this result in
> large SDP descriptions in certain scenarios?

Yes. The issue is not new, there have been concerns in the MMUSIC WG
with respect the size of SDP, but not due to this draft, but due to the
long list of SDP extensions, which in many cases are needed. Well,
probably the solution to address these concerns (or relieve them) is to
use SIP and TCP. Although this won't solve the issue, perhaps it
mitigates the side effects.

Again, the size of SDP is an issue with or without this draft.

> 
> 6. Section 4 asserts that use of the defined file transfer mechanism to
> transfer multiple files "will not lead to excessive use of transport
> resources" because "multiple MSRP media streams can share a single
> transport layer connection". It strikes me that this assertion may not
> be realistic in deployments, depending on the number and size of files
> being transferred.

Why do you think this is not realistic? It is a common way of operation
in MSRP. There is the concept of a logical MSRP session and the concept
of a TCP connection. It is possible to instantiate several MSRP logical
sessions that share the same TCP connection.

I would say that a direct TCP connection between two endpoints could
share file transfer of several simultaneous files and instant message.
The same would apply for a TCP connection established towards an MSRP
relay.

> 
> 7. According to the ABNF in Section 6, there is no limit to the length
> of the filename string. Might this lead to excessively large SDP
> descriptions?

As indicated later, SDP is large with or without this draft. I don't
dare to put a limit, because this limit depends on mostly the operating
system. There is text suggesting to sanitize the received file name,
including cropping the name. But on the sending size, I don't dare to
place a limit. There are no limits in any of the other text fields in
SIP or SDP either.

> 
> 8. The date-param attributes all include timezone offsets. Might it be
> better (i.e., simpler to implement) if the document specified the use of
> UTC instead?

Is it simpler? I don't know, I thought it would be simpler to send the
file with the local time.

Also: whenever is possible, we have tried to express in SDP what is
otherwise available in MIME headers. The date-param is an example of it.

So, if it is possible to use time zones with MIME headers, then we
shouldn't convert them in SDP.

> 
> 9. Section 6 contains the following sentence:
> 
>    Only one parameter of each type (creation, modification, or read)
>    MUST be present in a 'file-date' attribute.
> 
> I think you mean that a 'file-date' attribute MUST NOT contain more than
> one parameter of each type, since it is OPTIONAL to include any given
> parameter.

YES, thanks.

> 
> 10. In Section 7, the specification mentions that the 'attachment'
> disposition type indicates that presentation of a file to a human user
> should be contingent upon some action by the user. Does this enable a
> possible denial of service (DoS) attack against the user (by sending
> multiple file transfer requests requiring human intervention)?

No. Remember that the SDP offer is carried in an INVITE request, which
already requires human intervention. A DoS attack cannot be considered
an alert to the user.

Also, most e-mail readers allow to configure automatic actions, if the
user desires to do so.

> 
> 11. The only two modes allowed are "sendonly" and "recvonly" (see
> Section 8). Why is bidirectional file transfer not allowed?

Because it would be a mess with the file descriptions, in the offer an
answer. It won't be possible to distinguish what is being sent in which
direction.

On the other hand, there is no use case for bidirectional transfer: a
file is physically located in one endpoint and is going to move to the
other endpoint. There is never a file that moves in both directions. But
there could be one file in each endpoint that is to be transferred to
the other endpoint, in which case, the simplest and cleanest mechanism
is the two unidirectional file transfers.

> 
> 12. In Section 8.2.1, the specification suggests that whether the file
> shall be accepted or rejected will typically depend on explicit action
> by the file receiver. Here again there may be the potential for a DoS
> attack (e.g., by sending a large number of file transfer requests).

See point 10 above.

> 
> 13. In Section 8.2.2., user interaction is again suggested if the file
> selector points to multiple candidate files. Here again there may be the
> potential for a DoS attack (e.g., if the file selector specifies only a
> common media type, forcing the user to select from among a large number
> of candidate files).

See point 10 above.

> 
> 14. Section 8.3 states that "An SDP answer that MUST not downgrade the
> offered 'file-transfer' value." (BTW I think the word "that" is a typo
> and that you mean to say "MUST NOT".) The use of the term "downgrade"
> suggests that there is a possible attack here. What is the attack and
> how does the quoted text help to prevent it?

The wording is fixed as you suggested.

The word downgrade does not have any security connotations. Instead, it 
is a way of speaking to indicate which value has precedence over another 
one in an enumeration. This has been used in the past in SIP related 
RFCs, so it should be ok for a person familiar with SIP.

> 
> 15. Section 8.3 uses the phrase "SDP file". I think the phrase "SDP
> description" is more accurate and less confusing, especially in the
> context of a file transfer specification.

To be consistent with the rest of the specification, I have replace it 
with "SDP file description".

> 
> 16. Section 8.6 states that when chunking is used, MSRP does not require
> acknowledgements (200-class responses). Does this potentially result in
> a lossy transport? If not, why not? If so, how does tha the sending size, I don't dare to
place a limit. There are no limits in any of the other text fields in
SIP or SDP either.

> 
> 8. The date-param attributes all include timezone offsets. Might it be
> better (i.e., simpler to implement) if the document specified the use of
> UTC instead?

Is it simpler? I don't know, I thought it would be simpler to send the
file with the local time.

Also: whenever is possible, we have tried to express in SDP what is
otherwise available in MIME headers. The date-param is an example of it.

So, if it is possible to use time zones with MIME headers, then we
shouldn't convert them in SDP.

> 
> 9. Section 6 contains the following sentence:
> 
>    Only one parameter of each type (creation, modification, or read)
>    MUST be present in a 'file-date' attribute.
> 
> I think you mean that a 'file-date' attribute MUST NOT contain more than
> one parameter of each type, since it is OPTIONAL to include any given
> parameter.

YES, thanks.

> 
> 10. In Section 7, the specification mentions that the 'attachment'
> disposition type indicates that presentation of a file to a human user
> should be contingent upon some action by the user. Does this enable a
> possible denial of service (DoS) attack against the user (by sending
> multiple file transfer requests requiring human intervention)?

No. Remember that the SDP offer is carried in an INVITE request, which
already requires human intervention. A DoS attack cannot be considered
an alert to the user.

Also, most e-mail readers allow to configure automatic actions, if the
user desires to do so.

> 
> 11. The only two modes allowed are "sendonly" and "recvonly" (see
> Section 8). Why is bidirectional file transfer not allowed?

Because it would be a mess with the file descriptions, in the offer an
answer. It won't be possible to distinguish what is being sent in which
direction.

On the other hand, there is no use case for bidirectional transfer: a
file is physically located in one endpoint and is going to move to the
other endpoint. There is never a file that moves in both directions. But
there could be one file in each endpoint that is to be transferred to
the other endpoint, in which case, the simplest and cleanest mechanism
is the two unidirectional file transfers.

> 
> 12. In Section 8.2.1, the specification suggests that whether the file
> shall be accepted or rejected will typically depend on explicit action
> by the file receiver. Here again there may be the potential for a DoS
> attack (e.g., by sending a large number of file transfer requests).

See point 10 above.

> 
> 13. In Section 8.2.2., user interaction is again suggested if the file
> selector points to multiple candidate files. Here again there may be the
> potential for a DoS attack (e.g., if the file selector specifies only a
> common media type, forcing the user to select from among a large number
> of candidate files).

See point 10 above.

> 
> 14. Section 8.3 states that "An SDP answer that MUST not downgrade the
> offered 'file-transfer' value." (BTW I think the word "that" is a typo
> and that you mean to say "MUST NOT".) The use of the term "downgrade"
> suggests that there is a possible attack here. What is the attack and
> how does the quoted text help to prevent it?

The wording is fixed as you suggested.

The word downgrade does not have any security connotations. Instead, it 
is a way of speaking to indicate which value has precedence over another 
one in an enumeration. This has been used in the past in SIP related 
RFCs, so it should be ok for a person familiar with SIP.

> 
> 15. Section 8.3 uses the phrase "SDP file". I think the phrase "SDP
> description" is more accurate and less confusing, especially in the
> context of a file transfer specification.

To be consistent with the rest of the specification, I have replace it 
with "SDP file description".

> 
> 16. Section 8.6 states that when chunking is used, MSRP does not require
> acknowledgements (200-class responses). Does this potentially result in
> a lossy transport? If not, why not? If so, how does that influence the
> ability to transfer a complete file?

No, your interpretation is not correct. MSRP requiries the 200 OK as a 
mechanism to acknowledge a next hop delivery.

But read again what the text says:

When chunking, notice that MSRP does not require to wait for a 200-class 
response for a chunk before sending the following one. Therefore, it is 
valid to send pipelined MSRP SEND requests containing chunks of the same 
MSRP message (the file). Section 9.1 (Offerer sends a file to the 
Answerer)  contains an example of a file transfer using pipelined MSRP 
requests.

This comes from a common implementation error that we saw in several 
implementations: they were all waiting for receiving a 200 OK for a 
chunk before sending the next chunk. This made the transfer of a file 
waaaaay too long, and unacceptable from the user's point of view. So the 
text just tries to say that implementations can send all the chunks one 
after each other and then sit down to wait for the 200 responses for 
each chunk. This is far more efficient. Figure 3 shows way of operation 
with two chunks.

> 
> 17. Section 8.6 mentions a 'max-size' attribute for the file; does MSRP
> also include the ability to set a maximum chunk size?

No, it doesn't. There have been discussions in the SIMPLE mailing list 
with respect the need for it. The MSRP authors and myself do not see the 
need for it. Those who advocate for this need, IMHO, seemed to have 
artificial implementation constraints that wanted to solve by signaling 
  such constraint.

> 18. Section 8.7 states that compliant implementations MUST implement the
> multipart/mix MIME type but then goes on to describe the behavior of
> file receivers that do not support multipart MIME types; this is a bit
> confusing so perhaps the text could be clarified here.

Right... the idea is as follows:
- The mechanism in the draft is backwards compatible with endpoints that 
implement vanilla SDP and MSRP, but not the SDP extensions of the draft
- The use case that Section 8.7 consider is: The offerer implements the 
draft, so it implements MIME multipart and uses it. The answerer does 
not implement the draft, so it does not necessarily implements MIME 
multipart. The offer contains an icon, as a multipart attachment that 
makes the answerer to reject the offer. If the offer is repeated without 
an icon, and thus without a multipart, it will be understood by the 
answerer, although just the pure vanilla SDP, not the extensions defined 
by the draft.

I'll try to clarify the text.

> 
> 19. Section 8.7 states that if an icon (a.k.a. thumbprint) is sent as
> part of the signalling, the size of the icon in bytes should be limited;
> however, no suggested size limits are provided to guide developers. 8k
> perhaps?

The text is mostly copied from RFC 3261. There is no guidance with the 
icon size. I would like to see even smaller sizes than 8 k. I have been 
able to create readable icons with about 700 bytes. But it is hard to 
say a figure.

> 
> 20. The Security Considerations provide no information about the
> potential for denial of service attacks. See above. See also RFC 4732
> and Section 4.6 of RFC 3552.

ok, I will read these RFCs and see if there is something else that need 
to be added. In general, this is an extension to a number of existing 
protocols (mostly SDP, SDP/offer answer). So I don't believe we are 
introducing new security concerns above those introduced by these protocols.

> 
> 21. The Security Considerations provide no information about the
> potential for the transmission of viruses and other malware over the
> defined file transfer mechanism. Given that file transfer using other
> technologies (e.g., multipart MIME email messages or file attachments)
> commonly results in the transmission of malware, I think some text
> regarding this threat is in order.

OK, I have added the following text:

        Once a file has been transferred the file receiver must take
        care with it. Typically file transfer is a commonly used
        mechanism for transmitting computer virus, spyt influence the
> ability to transfer a complete file?

No, your interpretation is not correct. MSRP requiries the 200 OK as a 
mechanism to acknowledge a next hop delivery.

But read again what the text says:

When chunking, notice that MSRP does not require to wait for a 200-class 
response for a chunk before sending the following one. Therefore, it is 
valid to send pipelined MSRP SEND requests containing chunks of the same 
MSRP message (the file). Section 9.1 (Offerer sends a file to the 
Answerer)  contains an example of a file transfer using pipelined MSRP 
requests.

This comes from a common implementation error that we saw in several 
implementations: they were all waiting for receiving a 200 OK for a 
chunk before sending the next chunk. This made the transfer of a file 
waaaaay too long, and unacceptable from the user's point of view. So the 
text just tries to say that implementations can send all the chunks one 
after each other and then sit down to wait for the 200 responses for 
each chunk. This is far more efficient. Figure 3 shows way of operation 
with two chunks.

> 
> 17. Section 8.6 mentions a 'max-size' attribute for the file; does MSRP
> also include the ability to set a maximum chunk size?

No, it doesn't. There have been discussions in the SIMPLE mailing list 
with respect the need for it. The MSRP authors and myself do not see the 
need for it. Those who advocate for this need, IMHO, seemed to have 
artificial implementation constraints that wanted to solve by signaling 
  such constraint.

> 18. Section 8.7 states that compliant implementations MUST implement the
> multipart/mix MIME type but then goes on to describe the behavior of
> file receivers that do not support multipart MIME types; this is a bit
> confusing so perhaps the text could be clarified here.

Right... the idea is as follows:
- The mechanism in the draft is backwards compatible with endpoints that 
implement vanilla SDP and MSRP, but not the SDP extensions of the draft
- The use case that Section 8.7 consider is: The offerer implements the 
draft, so it implements MIME multipart and uses it. The answerer does 
not implement the draft, so it does not necessarily implements MIME 
multipart. The offer contains an icon, as a multipart attachment that 
makes the answerer to reject the offer. If the offer is repeated without 
an icon, and thus without a multipart, it will be understood by the 
answerer, although just the pure vanilla SDP, not the extensions defined 
by the draft.

I'll try to clarify the text.

> 
> 19. Section 8.7 states that if an icon (a.k.a. thumbprint) is sent as
> part of the signalling, the size of the icon in bytes should be limited;
> however, no suggested size limits are provided to guide developers. 8k
> perhaps?

The text is mostly copied from RFC 3261. There is no guidance with the 
icon size. I would like to see even smaller sizes than 8 k. I have been 
able to create readable icons with about 700 bytes. But it is hard to 
say a figure.

> 
> 20. The Security Considerations provide no information about the
> potential for denial of service attacks. See above. See also RFC 4732
> and Section 4.6 of RFC 3552.

ok, I will read these RFCs and see if there is something else that need 
to be added. In general, this is an extension to a number of existing 
protocols (mostly SDP, SDP/offer answer). So I don't believe we are 
introducing new security concerns above those introduced by these protocols.

> 
> 21. The Security Considerations provide no information about the
> potential for the transmission of viruses and other malware over the
> defined file transfer mechanism. Given that file transfer using other
> technologies (e.g., multipart MIME email messages or file attachments)
> commonly results in the transmission of malware, I think some text
> regarding this threat is in order.

OK, I have added the following text:

        Once a file has been transferred the file receiver must take
        care with it. Typically file transfer is a commonly used
        mechanism for transmitting computer virus, spyware, and other
        types of malware. File recipients should apply all possible
        security technologies (e.g., antivirus, antispaware, etc.) to
        dismiss the risk of damage at their host.

> 
> 22. The Security Considerations provide no information about the need to
> verify the identity of a sender before accepting an offer to transfer a
> file (e.g., in order to avoid file transfers from unknown or malicious
> users). This may be addressed at a lower layer or in another
> specification (e.g., in RFC 3264 or RFC 3261), but it would be helpful
> to make reference to the relevant specification here if possible. See
> also Section 2.1.3 of RFC 3552.

Certainly. It was obvious to me, perhaps we forgot it. I have added the 
following text:

        Prior to accepting a file transfer, the file receiver should
        first verify the identity of the file sender, and perhaps, only
        accept file transfers from trusted sources. Mechanisms to
        verify the identity of the file sender depend on the high-level
        protocol that carries the SDP, for example, <xref
        target="RFC3261">SIP </xref>.

> Thanks.

Once more, thank you very much for your review.

/Miguel

> 
> Peter
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Thu, 19 Jul 2007 09:21:04 +0300
From: Miguel Garcia <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [APPS-REVIEW] Re: Review of draft-ietf-mmusic-file-transfer-mech-03

> 
> 22. The Security Considerations provide no information about the need to
> verify the identity of a sender before accepting an offer to transfer a
> file (e.g., in order to avoid file transfers from unknown or malicious
> users). This may be addressed at a lower layer or in another
> specification (e.g., in RFC 3264 or RFC 3261), but it would be helpful
> to make reference to the relevant specification here if possible. See
> also Section 2.1.3 of RFC 3552.

Certainly. It was obvious to me, perhaps we forgot it. I have added the 
following text:

        Prior to accepting a file transfer, the file receiver should
        first verify the identity of the file sender, and perhaps, only
        accept file transfers from trusted sources. Mechanisms to
        verify the identity of the file sender depend on the high-level
        protocol that carries the SDP, for example, <xref
        target="RFC3261">SIP </xref>.

> Thanks.

Once more, thank you very much for your review.

/Miguel

> 
> Peter
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Thu, 19 Jul 2007 09:21:04 +0300
From: Miguel Garcia <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [APPS-REVIEW] Re: Review of draft-ietf-mmusic-file-transfer-mech-03

Hi Peter:

Just one more comment:

Peter Saint-Andre wrote:
>>> 4. In Section 1.1, the specification does not clearly explain why MSRP
>>> (draft-ietf-simple-message-sessions) is the preferred transport
>>> protocol. Furthermore, although the specification mentions that it is
>>> possible to use similar protocols in place of MSRP, the specification
>>> does not provide guidelines for choosing or developing such protocols.
>>> Such guidelines would be helpful to those who might re-use (or gateway
>>> to) the defined file transfer mechanism.
>> Fixed. I have added at the end of the indented text in Section 1.1:
>>
>>             Essentially, such protocol should be able to
>>         be negotiated on an SDP offer/answer exchange (<xref
>>         target="RFC3264">RFC 3264 </xref>) and be able to carry
>>         MIME objects between two endpoints.
> 
> And presumably use a reliable rather than lossy transport?

Yes, of course. I will add a reliable transport as well.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

ubject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/apps-review>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/apps-review>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Hi Peter:

Just one more comment:

Peter Saint-Andre wrote:
>>> 4. In Section 1.1, the specification does not clearly explain why MSRP
>>> (draft-ietf-simple-message-sessions) is the preferred transport
>>> protocol. Furthermore, although the specification mentions that it is
>>> possible to use similar protocols in place of MSRP, the specification
>>> does not provide guidelines for choosing or developing such protocols.
>>> Such guidelines would be helpful to those who might re-use (or gateway
>>> to) the defined file transfer mechanism.
>> Fixed. I have added at the end of the indented text in Section 1.1:
>>
>>             Essentially, such protocol should be able to
>>         be negotiated on an SDP offer/answer exchange (<xref
>>         target="RFC3264">RFC 3264 </xref>) and be able to carry
>>         MIME objects between two endpoints.
> 
> And presumably use a reliable rather than lossy transport?

Yes, of course. I will add a reliable transport as well.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

Date: Wed, 18 Jul 2007 12:10:48 -0600
From: Peter Saint-Andre <[email-masked]>
Organization: XMPP Standards Foundation
To: Miguel Garcia <[email-masked]>
Jabber-ID: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [APPS-REVIEW] Re: Review of draft-ietf-mmusic-file-transfer-mech-03

This is a cryptographically signed message in MIME format.

--===============1841823041==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=sha1; boundary="------------ms040606060607030204070701"

This is a cryptographically signed message in MIME format.

--------------ms040606060607030204070701
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Miguel:

Thanks for your attention to this review. A few additinoal comments inline.

Miguel Garcia wrote:

>> 1. The document contains numerous typographical and grammatical errors,
>> which detract from the specification. I am sure that most of these would
>>  be discovered by the RFC Editor team. However, in order to lighten
>> their load and reduce the number of AUTH48 changes, I would suggest
>> completing a thorough copy-edit before WGLC or IETF Last Call.
> 
> Ok. We'll do. If you happen to have some detailed changes that you
> propose, please send them to me.

I did not have time to complete a copy-edit while reviewing the
document, but if I find the time I will send along some proposed fixes.

>> 3. In Section 1.1, the alternative of the SIP content indirection
>> mechanism (RFC 4483) is considered. Although the document provides a
>> list of difference between SIP content indirection and the defined file
>> transfer mechanism, the document does not provide a clear set of
>> guidelines to user agent developers in determining when it might be
>> preferable to use SIP content indirection and when it might be
>> preferable to use the defined file transfer mechanism.
> 
> Well, the draft can only briefly compare both mechanisms, and let
> implementors decide which one to use or implement, depending on the
> requirements the have. I have added the following sentence at the end of
> the paragraph the compares the two mechanisms:
> 
>         The
>     level of requirements in implementations decides which solution
>     meets the requirements.

Fair enough. Let the market decide. :)

>> 4. In Section 1.1, the specification does not clearly explain why MSRP
>> (draft-ietf-simple-message-sessions) is the preferred transport
>> protocol. Furthermore, although the specification mentions that it is
>> possible to use similar protocols in place of MSRP, the specification
>> does not provide guidelines for choosing or developing such protocols.
>> Such guidelines would be helpful to those who might re-use (or gateway
>> to) the defined file transfer mechanism.
> 
> Fixed. I have added at the end of the indented text in Section 1.1:
> 
>             Essentially, such protocol should be able to
>         be negotiated on an SDP offer/answer exchange (<xref
>         target="RFC3264">RFC 3264 </xref>) and be able to carry
>         MIME objects between two endpoints.

And presumably use a reliable rather than lossy transport?

>> 5. Section 4 mentions that the transfer of multiple simultaneous files
>> would require one SDP (RFC 4566) m= line per file. Might this result in
>> large SDP descriptions in certain scenarios?
> 
> Yes. The issue is not new, there have been concerns in the MMUSIC WG
> with respect the size of SDP, but not due to this draft, but due to the
> long list of SDP extensions, which in many cases are needed. Well,
> probably the solution to address these concerns (or relieve them) is to
> use SIP and TCP. Although this won't solve the issue, perhaps it
> mitigates the side effects.
> 
> Again, the size of SDP is an issue with or without this draft.

Agreed. Probably the issue needs to be addressed elsewhere (e.g., an
implementor's guide to SIP/SDP development).

>> 6. Section 4 asserts that use of the defined file transfer mechanism to
>> transfer multiple files "will not lead to excessive use of transport
>> resources" because "multiple MSRP media streams can share a single
>> transport layer connection". It strikes me that this assertion may not
>> be realistic in deployments, depending on the number and size of files
>> being transferred.
> 
> Why do you think this is not realistic? It is a common way of operation
> in MSRP. There is the concept of a logical MSRP session and the concept
> of a TCP connection. It is possible to instantiate several MSRP logical
> sessions that share the same TCP connection.
> 
> I would say that a direct TCP connection between two endpoints could
> share file transfer of several simultaneous files and instant message.
> The same would apply for a TCP connection established towards an MSRP
> relay.

Yes, as I said this is probably more of a deployment issue than a
specification issue.

>> 7. According to the ABNF in Section 6, there is no limit to the length
>> of the filename string. Might this lead to excessively large SDP
>> descriptions?
> 
> As indicated later, SDP is large with or without this draft. I don't
> dare to put a limit, because this limit depends on mostly the operating
> system. There is text suggesting to sanitize the received file name,
> including cropping the name. But on the sending size, I don't dare to
> place a limit. There are no limits in any of the other text fields in
> SIP or SDP either.

OK.

>> 8. The date-param attributes all include timezone offsets. Might it be
>> better (i.e., simpler to implement) if the document specified the use of
>> UTC instead?
> 
> Is it simpler? I don't know, I thought it would be simpler to send the
> file with the local time.
> 
> Also: whenever is possible, we have tried to express in SDP what is
> otherwise available in MIME headers. The date-param is an example of it.
> 
> So, if it is possible to use time zones with MIME headers, then we
> shouldn't convert them in SDP.

Ah, I hadn't realized this was a re-use of MIME headers. Carry on. :)

>> 16. Section 8.6 states that when chunking is used, MSRP does not require
>> acknowledgements (200-class responses). Does this potentially result in
>> a lossy transport? If not, why not? If so, how does that influence the
>> ability to transfer a complete file?
> 
> No, your interpretation is not correct. MSRP requiries the 200 OK as a
> mechanism to acknowledge a next hop delivery.
> 
> But read again what the text says:
> 
> When chunking, notice that MSRP does not require to wait for a 200-class
> response for a chunk before sending the following one. Therefore, it is
> valid to send pipelined MSRP SEND requests containing chunks of the same
> MSRP message (the file). Section 9.1 (Offerer sends a file to the
> Answerer)  contains an example of a file transfer using pipelined MSRP
> requests.
> 
> This comes from a common implementation error that we saw in several
> implementations: they were all waiting for receiving a 200 OK for a
> chunk before sending the next chunk. This made the transfer of a file
> waaaaay too long, and unacceptable from the user's point of view. So the
> text just tries to say that implementations can send all the chunks one
> after each other and then sit down to wait for the 200 responses for
> each chunk. This is far more efficient. Figure 3 shows way of operation
> with two chunks.

OK.

>> 17. Section 8.6 mentions a 'max-size' attribute for the file; does MSRP
>> also include the ability to set a maximum chunk size?
> 
> No, it doesn't. There have been discussions in the SIMPLE mailing list
> with respect the need for it. The MSRP authors and myself do not see the
> need for it. Those who advocate for this need, IMHO, seemed to have
> artificial implementation constraints that wanted to solve by signaling
>  such constraint.

I agree. Mostly I was just curious.

>> 18. Section 8.7 states that compliant implementations MUST implement the
>> multipart/mix MIME type but then goes on to describe the behavior of
>> file receivers that do not support multipart MIME types; this is a bit
>> confusing so perhaps the text could be clarified here.
> 
> Right... the idea is as follows:
> - The mechanism in the draft is backwards compatible with endpoints that
> implement vanilla SDP and MSRP, but not the SDP extensions of the draft
> - The use case that Section 8.7 consider is: The offerer implements the
> draft, so it implements MIME multipart and uses it. The answerer does
> not implement the draft, so it does not necessarily implements MIME
> multipart. The offer contains an icon, as a multipart attachment that
> makes the answerer to reject the offer. If the offer is repeated without
> an icon, and thus without a multipart, it will be understood by the
> answerer, although just the pure vanilla SDP, not the extensions defined
> by the draft.
> 
> I'll try to clarify the text.

Great, thanks.

>> 19. Section 8.7 states that if an icon (a.k.a. thumbprint) is sent as
>> part of the signalling, the size of the icon in bytes should be limited;
>> however, no suggested size limits are provided to guide developers. 8k
>> perhaps?
> 
> The text is mostly copied from RFC 3261. There is no guidance with the
> icon size. I would like to see even smaller sizes than 8 k. I have been
> able to create readable icons with about 700 bytes. But it is hard to
> say a figure.

True -- probably it is hard to provide exact guidance on this issue.

>> 20. The Security Considerations provide no information about the
>> potential for denial of service attacks. See above. See also RFC 4732
>> and Section 4.6 of RFC 3552.
> 
> ok, I will read these RFCs and see if there is something else that need
> to be added. In general, this is an extension to a number of existing
> protocols (mostly SDP, SDP/offer answer). So I don't believe we are
> introducing new security concerns above those introduced by these
> protocols.
> 
>>
>> 21. The Security Considerations provide no information about the
>> potential for the transmission of viruses and other malware over the
>> defined file transfer mechanism. Given that file transfer using other
>> technologies (e.g., multipart MIME email messages or file attachments)
>> commonly results in the transmission of malware, I think some text
>> regarding this threat is in order.
> 
> OK, I have added the following text:
> 
>        Once a file has been transferred the file receiver must take
>        care with it. Typically file transfer is a commonly used
>        mechanism for transmitting computer virus, spyware, and other
>        types of malware. File recipients should apply all possible
>        security technologies (e.g., antivirus, antispaware, etc.) to
>        dismiss the risk of damage at their host.

Yes, that's better. Whether end users will be smart is another question,
but at least we can encourage implementors to do the right thing.

>> 22. The Security Considerations provide no information about the need to
>> verify the identity of a sender before accepting an offer to transfer a
>> file (e.g., in order to avoid file transfers from unknown or malicious
>> users). This may be addressed at a lower layer or in another
>> specification (e.g., in RFC 3264 or RFC 3261), but it would be helpful
>> to make reference to the relevant specification here if possible. See
>> also Section 2.1.3 of RFC 3552.
> 
> Certainly. It was obvious to me, perhaps we forgot it. I have added the
> following text:
> 
>        Prior to accepting a file transfer, the file receiver should
>        first verify the identity of the file sender, and perhaps, only
>        accept file transfers from trusted sources. Mechanisms to
>        verify the identity of the file sender depend on the high-level
>        protocol that carries the SDP, for example, <xref
>        target="RFC3261">SIP </xref>.

Better, thanks.

Peter

--------------ms040606060607030204070701
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040606060607030204070701--

--===============1841823041==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

--===============1841823041==--

Date: Mon, 09 Jul 2007 11:15:29 -0600
From: Peter Saint-Andre <[email-masked]>
Organization: XMPP Standards Foundation
To: [email-masked], [email-masked], [email-masked], [email-masked]
OpenPGP: id=7BBD0573; url=http://www.saint-andre.com/me/stpeter.asc
Jabber-ID: [email-masked]
Cc: [email-masked]
Subject: [APPS-REVIEW] Review of draft-ietf-mmusic-file-transfer-mech-03

This is a cryptographically signed message in MIME format.

--===============1484055933==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=sha1; boundary="------------ms090305070200080107020901"

This is a cryptographically signed message in MIME format.

--------------ms090305070200080107020901
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Review of: draft-ietf-mmusic-file-transfer-mech-03
By:        Peter Saint-Andre
Date:      2007-07-09

Eric Burger has asked me (as a member of Apps-Review team) to review the
I-D referenced above. Please note that such reviews have no special
weight within the Internet Standards Process. In completing this review,
I have attempted to follow some relevant guidelines as well as examples
of previous reviews, such as:

http://www.rfc-editor.org/rfc-editor/reviewer.guide.txt
http://www1.ietf.org/mail-archive/web/apps-review/current/msg00019.html
http://www1.ietf.org/mail-archive/web/apps-review/current/msg00028.html
http://www1.ietf.org/mail-archive/web/apps-review/current/msg00029.html

Overall the document appears to be technically sound. Please take the
following comments in the spirit of suggestions.

1. The document contains numerous typographical and grammatical errors,
which detract from the specification. I am sure that most of these would
 be discovered by the RFC Editor team. However, in order to lighten
their load and reduce the number of AUTH48 changes, I would suggest
completing a thorough copy-edit before WGLC or IETF Last Call.

2. The bullet list of requirements in Section 1 contains the normative
term MUST. However, that term is reserved for normativity with regard to
protocol implementations, not specification requirements. For details,
see draft-peterson-informational-normativity.

3. In Section 1.1, the alternative of the SIP content indirection
mechanism (RFC 4483) is considered. Although the document provides a
list of difference between SIP content indirection and the defined file
transfer mechanism, the document does not provide a clear set of
guidelines to user agent developers in determining when it might be
preferable to use SIP content indirection and when it might be
preferable to use the defined file transfer mechanism.

4. In Section 1.1, the specification does not clearly explain why MSRP
(draft-ietf-simple-message-sessions) is the preferred transport
protocol. Furthermore, although the specification mentions that it is
possible to use similar protocols in place of MSRP, the specification
does not provide guidelines for choosing or developing such protocols.
Such guidelines would be helpful to those who might re-use (or gateway
to) the defined file transfer mechanism.

5. Section 4 mentions that the transfer of multiple simultaneous files
would require one SDP (RFC 4566) m= line per file. Might this result in
large SDP descriptions in certain scenarios?

6. Section 4 asserts that use of the defined file transfer mechanism to
transfer multiple files "will not lead to excessive use of transport
resources" because "multiple MSRP media streams can share a single
transport layer connection". It strikes me that this assertion may not
be realistic in deployments, depending on the number and size of files
being transferred.

7. According to the ABNF in Section 6, there is no limit to the length
of the filename string. Might this lead to excessively large SDP
descriptions?

8. The date-param attributes all include timezone offsets. Might it be
better (i.e., simpler to implement) if the document specified the use of
UTC instead?

9. Section 6 contains the following sentence:

   Only one parameter of each type (creation, modification, or read)
   MUST be present in a 'file-date' attribute.

I think you mean that a 'file-date' attribute MUST NOT contain more than
one parameter of each type, since it is OPTIONAL to include any given
parameter.

10. In Section 7, the specification mentions that the 'attachment'
disposition type indicates that presentation of a file to a human user
should be contingent upon some action by the user. Does this enable a
possible denial of service (DoS) attack against the user (by sending
multiple file transfer requests requiring human intervention)?

11. The only two modes allowed are "sendonly" and "recvonly" (see
Section 8). Why is bidirectional file transfer not allowed?

12. In Section 8.2.1, the specification suggests that whether the file
shall be accepted or rejected will typically depend on explicit action
by the file receiver. Here again there may be the potential for a DoS
attack (e.g., by sending a large number of file transfer requests).

13. In Section 8.2.2., user interaction is again suggested if the file
selector points to multiple candidate files. Here again there may be the
potential for a DoS attack (e.g., if the file selector specifies only a
common media type, forcing the user to select from among a large number
of candidate files).

14. Section 8.3 states that "An SDP answer that MUST not downgrade the
offered 'file-transfer' value." (BTW I think the word "that" is a typo
and that you mean to say "MUST NOT".) The use of the term "downgrade"
suggests that there is a possible attack here. What is the attack and
how does the quoted text help to prevent it?

15. Section 8.3 uses the phrase "SDP file". I think the phrase "SDP
description" is more accurate and less confusing, especially in the
context of a file transfer specification.

16. Section 8.6 states that when chunking is used, MSRP does not require
acknowledgements (200-class responses). Does this potentially result in
a lossy transport? If not, why not? If so, how does that influence the
ability to transfer a complete file?

17. Section 8.6 mentions a 'max-size' attribute for the file; does MSRP
also include the ability to set a maximum chunk size?

18. Section 8.7 states that compliant implementations MUST implement the
multipart/mix MIME type but then goes on to describe the behavior of
file receivers that do not support multipart MIME types; this is a bit
confusing so perhaps the text could be clarified here.

19. Section 8.7 states that if an icon (a.k.a. thumbprint) is sent as
part of the signalling, the size of the icon in bytes should be limited;
however, no suggested size limits are provided to guide developers. 8k
perhaps?

20. The Security Considerations provide no information about the
potential for denial of service attacks. See above. See also RFC 4732
and Section 4.6 of RFC 3552.

21. The Security Considerations provide no information about the
potential for the transmission of viruses and other malware over the
defined file transfer mechanism. Given that file transfer using other
technologies (e.g., multipart MIME email messages or file attachments)
commonly results in the transmission of malware, I think some text
regarding this threat is in order.

22. The Security Considerations provide no information about the need to
verify the identity of a sender before accepting an offer to transfer a
file (e.g., in order to avoid file transfers from unknown or malicious
users). This may be addressed at a lower layer or in another
specification (e.g., in RFC 3264 or RFC 3261), but it would be helpful
to make reference to the relevant specification here if possible. See
also Section 2.1.3 of RFC 3552.

Thanks.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

--------------ms090305070200080107020901
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090305070200080107020901--

--===============1484055933==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

--===============1484055933==--