Subject: [lemonade] FW: Review of Lemonade Streaming Draft

From: "Eric Burger" <[email-masked]>
Date: Thu, 19 Jul 2007 13:28:45 -0700

If you have comments or questions, send them directly to Paul, as he is
not a list subscriber.

Paul - Thanks!!! -- Eric

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2007 7:07 PM
To: Eric Burger
Subject: Re: Review of Lemonade Streaming Draft

Eric,

OK, you twisted my arm enough to go read this draft. 
(draft-ietf-lemonade-streaming-02). You didn't tell me where to send
this. So I guess I will just send it to you for now. If you want me to
send it to sipping and/or lemonade just let me know. Or feel free to
just forward this to some wg lists if you wish.

As a general comment, this looks like a useful capability to have.

Beyond that I have some specific comments about parts of the draft. But
please take these with a grain of salt, because I know *nothing* of any
of the work done by the lemonade wg. I did consult a couple of the
referenced documents along the way, but only briefly.

Section 2.1:

>    However, it should be noted that this document proposes an
extension
>    to the SIP Parameter Registry [9], in order to accommodate passing
a
>    content transfer encoding parameter to the Announcement Service.
>    Additionally two new attributes to the MSCML <audio> tag are
>    proposed, to carry content type and content transfer encoding
>    information.

I don't find any IANA considerations to actually cause the SIP Parameter
Registry to be updated for these parameters. Without those, this is just
wishful thinking.

Much later, in section 2.7:

>    The <audio> tag in RFC 4722 has no attributes that specify the
>    content-type or content-transfer-encoding of the media to be
played.
>    Therefore this document proposes two new attributes for this
purpose,
>    namely a "contenttype" attribute, and a "contenttransferencoding"
>    attribute.  The syntax of these attributes is identical to the
syntax
>    of their counterparts in MIME [10].

Is that sufficient to get a normative extension to RFC 4722? While I
didn't check what the procedures are, I doubt this is enough.

Later in section 2.1:

>    3.  Client connects to a SIP Media Server using the Announcement
>        Service as specified in RFC 4240 [1], or the IVR Service as
>        specified in RFC 4722 [13], and passes the URLAUTH authorized
URL
>        to the media server.

Related to that, from 4722:

>    In general, a media server offers services to SIP UACs, such as
>    Application Servers, Feature Servers, and Media Gateway
Controllers.
>    See the IPCC Reference Architecture [12] for definitions of these
>    terms.  It is unlikely, but not prohibited, for end-user SIP UACs
to
>    have a direct signaling relationship with a media server. 

So if I understand, this is in fact one of the unlikely cases where an
end-user UAC will have a direct relationship with a media server.

If these things are designed with the expectation that they can't be
reached by end users then they are likely to be blocked from access by
firewalls, etc. So it may be a significant deployment issue to make this
proposal work. Is that something worth highlighting?

Yet further in 2.1:

>    4.  Media Server connects to the IMAP Server specified in the
>        referenced URL, and uses the IMAP URLFETCH [2] command to
>        retrieve the message part.

>    It should be noted that the proposed mechanism makes several
>    assumptions about the mobile device, as well as the network
services,
>    namely:
...
>    o  Media Server(s) used by the mobile device support the IMAP URL
[4]
>       scheme for the announcement and/or IVR services

Related to the above, from 4722:

>    Attributes of <audio>:
> 
>    o  url - required, no default value: The URL of the content to be
>       retrieved and played.  The target may be a local or remote (NFS)
>       "file://" scheme URL or an "http://" or "https://" scheme URL.

Note there is no schema for the <audio> element in 4722. Is it
extensible to other url schemes? Is some further extension to 4722
required to support the use of the IMAP URL scheme?

Section 2.6 - SDP example:

Is there a reason why the mail client is offering sendrecv for video
rather than just recvonly? Does it actually want to transmit video? (I
can see why sendrecv is useful for audio, so that DTMF can be
transmitted, but is that actually true for the annc server, or only for
the IVR server?)

Security Considerations:

The security considerations around use of URLAUTH URL seem very scary to
me. While the security considerations section addresses this issue I
wonder if it is strong enough. I question if the mechanism can ever be
used with safety.

	Thanks for the intro to Lemonade,
	Paul

Eric Burger wrote:
> No problem.  The idea is to get a non-LEMONADE perspective, 
> especially, though, we do want a SIP perspective.
> 
> See LEMONADE isn't that hard - it is exactly as you guess, a 
> convention for streaming an object from a message store to a SIP
device.
> 
> The SIP perspective would be great.  The document is almost in WGLC, 
> in that the IMAP parameters for retrieving the object will be split 
> into a different document.  Otherwise, the document is good to go.
> 
> I would focus on the SIP stuff, but if a nit or two jumps out at you, 
> feel free to bring it up.
> 
> Thanks!
> 
> 
> On 7/16/07 10:22 AM, "Paul Kyzivat" <[email-masked]> wrote:
> 
>> Eric,
>>
>> Sorry - I overlooked the request. I don't follow lemonade at all, so 
>> its strange territory for me. I just took a peek, and I guess you are

>> proposing that an email client may receive an attachment via 
>> streaming via sip. Sounds like a reasonable idea as long as it is
optional.
>> Exactly what are you looking for in a review? Just a sip perspective 
>> on this document from a different WG? Is this WGLC stuff? Nits?
>>
>>         Thanks,
>>         Paul
>>
>> Eric Burger wrote:
>>> Pretty, pretty please?  :-)
>>>
>>>
>>> ------ Forwarded Message
>>>> From: Eric Burger <[email-masked]>
>>>> Date: Wed, 27 Jun 2007 17:40:02 -0400
>>>> To: Paul Kyzivat <[email-masked]>
>>>> Cc: Neil Cook <[email-masked]>, Glenn Parsons 
>>>> <[email-masked]>
>>>> Conversation: Review of Lemonade Streaming Draft
>>>> Subject: FW: Review of Lemonade Streaming Draft
>>>>
>>>> Paul -
>>>>
>>>> Pretty please? 
>>>>
>>>> Can you give
>>>> draft-ietf-lemonade-streaming-02
>>>> a look?
>>>>
>>>> Thanks.
>>>> --
>>>> - Eric
>>>>
>>>>> ------ Forwarded Message
>>>>> From: "DRAGE, Keith (Keith)" <[email-masked]>
>>>>> Date: Fri, 22 Jun 2007 04:32:06 -0700
>>>>> To: Eric Burger <[email-masked]>, <[email-masked]>, 
>>>>> <[email-masked]>
>>>>> Cc: Glenn Parsons <[email-masked]>, Alexey Melnikov 
>>>>> <[email-masked]>
>>>>> Conversation: Review of Lemonade Streaming Draft
>>>>> Subject: RE: Review of Lemonade Streaming Draft
>>>>>
>>>>> Would Paul Kyzivat be at least one obvious candidate?
>>>>>
>>>>> While we are looking for someone, I did have a quick look in the 
>>>>> document.
>>>>>
>>>>> 1)      It is not clear from the document but I assume that you
are
>>>>> creating a new SIP/SIPS URI parameter and adding it to the 
>>>>> registry created in RFC 3969. At the moment, it is not clear which

>>>>> registry you are adding to.
>>>>>
>>>>> Could I suggest you look at draft-ietf-sip-gruu for a template for

>>>>> the text you need.
>>>>>
>>>>> 2)      I would also suggest using different subsections of the
IANA
>>>>> section for changes to each separate registry.
>>>>>
>>>>> 3)      In the text, where you refer to this parameter, can you
always
>>>>> use it in conjunction with the words "URI paramter" to make it
clear.
>>>>>
>>>>> 4)      Where you use the term "header" in the document in
relation to
>>>>> SIP, can I suggest you look at the definitions of the terms 
>>>>> "header" and "header field" in RFC 3261, for each occurrence, and 
>>>>> substitute as appropriate. Note that I was unsure in some cases 
>>>>> whether you were referring to the MIME header or the SIP header or
both.
>>>>>
>>>>> 5)      Format responses as in RFC 3261, i.e. "200 (OK) response",
not
>>>>> "200 OK response". Also not "an unsuccessful
>>>>>    response code of 404"
>>>>>
>>>>> 6)      Some instances of "SIP INFO message" which I believe
should be
>>>>> "SIP INFO request".
>>>>>
>>>>> 7)      I assume RFC 4722 is the real INFO usage here, and that
>>>>> presumably defines whether one should wait for a previous response

>>>>> to INFO before sending a new one (i.e. does out of sequence 
>>>>> delivery of the message bodies matter).
>>>>>
>>>>> Regards
>>>>>
>>>>> Keith
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email-masked]
>>>>>> [mailto:[email-masked]] On Behalf Of Eric Burger
>>>>>> Sent: Sunday, June 17, 2007 3:46 PM
>>>>>> To: [email-masked]; [email-masked]
>>>>>> Cc: Glenn Parsons; Alexey Melnikov
>>>>>> Subject: Review of Lemonade Streaming Draft
>>>>>>
>>>>>> We would be eternally grateful if you could identify one or two 
>>>>>> reviewers to give a look at:
>>>>>>      
>>>>>>
>>>>>> I would have been a logical choice, but I am the primary
contributor.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>> ------ End of Forwarded Message
>>> ------ End of Forwarded Message
>>>
>>>
>>> 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.
>>>
> 
> 
> 
> 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.

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.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Neil Cook <[email-masked]>
Date: Tue, 24 Jul 2007 20:55:28 +0200

Paul,

thanks also for reviewing the draft, I answer some of your questions/ 
comments below...

> Registry to be updated for these parameters. Without those, this is  

Another draft is currently being developed that updates the URLAUTH  
extension, and thus removes the need for these SIP Parameter  
attributes. So they will disappear in the next version of the draft.

> didn't check what the procedures are, I doubt this is enough.

See above. Same comment, i.e. they will disappear, as we are solving  
the problem within the Lemonade WG.

> proposal work. Is that something worth highlighting?

You're right. This is something I have thought about, but haven't  
explicitly put in the draft. I will do so.

> required to support the use of the IMAP URL scheme?

Well I did assume that, because there is no schema, that support for  
additional URL schemes would be an implementation-specific thing. It  
didn't occur to me that there would need to be an extension to  
support additional URL schemes. I don't think the protocol requires  
it as is.

> transmitted, but is that actually true for the annc server, or only  

It's an example bug - video only needs to be recvonly, and audio only  
needs to be sendrecv for IVR.

> wonder if it is strong enough. I question if the mechanism can ever be

Well that is a good question :) However, the whole notion of whether  
pawn-ticket URLs are secure enough to be deployed is perhaps outside  
the scope of this document. The document is really just making use of  
a feature from an existing RFC.

Neil.

> and  affiliated entities,  that may be confidential,  proprietary,