Subject: Re: [lemonade] New Version Notification for draft-ietf-lemonade-streaming-05

From: Eric Burger <[email-masked]>
Date: Fri, 16 May 2008 08:17:19 -0400

I was writing up the shepherd document for this draft, and I realized  
this conversation was off-list.  Most of the comments are purely  
editorial.  However, I would like work group consensus on the Section  
2.7 issue.

I would offer that as an Informational document, we change the  
sentence.  My opinion, CHAIR HAT OFF and AS A PARTICIPANT, is there is  
no requirement for a MUST here.  RFC 4240 does what it does.
OLD
If the IMAP server does not advertise
URLAUTH=BINARY in its capability string, then the media server SHOULD
return a suitable error code to the client.
NEW
If the IMAP server does not advertise
URLAUTH=BINARY in its capability string, then the media server
returns a suitable SIP error code to the client.

On the editorial front, there is a problem.  IMAP lines easily fold,  
and it is easy to determine from the C: and S: what is a line.  SIP  
lines do NOT fold on C: and S: boundaries.  Specifically, the SDP and  
MSCML examples must not fold.  Thus, something must change.  I would  
offer the following text in the Conventions section:

In IMAP examples, "C:" and "S:" indicate lines sent by the client and
server respectively.  If a single "C:" or "S:" label applies to
multiple lines, then the line breaks between those lines are for
editorial clarity only and are not part of the actual protocol
exchange.

In SIP examples, "C:" and "S:" indicate messages sent by the client and
server respectively.  For SIP examples, this document explicitly
indicates line folding by using a backslash (\) at the end of the
line.  Line breaks in a C: or S: block do not fold and are part of
the protocol.

On Apr 24, 2008, at 7:37 AM, Neil Cook wrote:

> Alexey,
>
> thanks for reviewing the draft, comments inline:
>
> Neil
>
> On 24 Apr 2008, at 12:22, Alexey Melnikov wrote:
>
> > Neil Cook wrote:
> >
> >> 2.5.  Media Negotiation and Transcoding
> >>
> > [...]
> >
> >>   Example SIP INVITE and SDP Media Negotiation
> >>
> >>   C: INVITE sip:[email-masked]; \
> >>   play=imap://[email-masked]/INBOX/;uid=24356/;section=1.2;\
> >>   expire=2006-12-19T16:39:\57-08:00;urlauth=anonymous:\
> >>   internal:238234982398239898a9898998798b987s87920; \
> >>   content-type=video/mpeg; \
> >>
> > Are all these '\' needed?
> >
>
> Well the SIP INVITE should all be on a single line, so the '\'
> characters are there to show that.
>
> > In section 2.7:
> >
> > You've changed the following text:
> >
> >>   A successful URLFETCH command will return the message part
> >> containing
> >>   the media to be streamed.  If the URLFETCH was unsuccessful,
> >> then the
> >>   media server MUST return a response code of 404 to the client
> >>   with an appropriate reason code.
> >>
> > to:
> >
> >>   A successful URLFETCH command will return the message part
> >> containing
> >>   the media to be streamed.  If the URLFETCH was unsuccessful,
> >> then the
> >>   media server SHOULD return an appropriate error code to the  
> client
> >>   with an appropriate reason code.
> >>
> > I think the new SHOULD is wrong, are there any cases when the media
> > server would not want to dislose URLFETCH failure to the client? I
> > think what you were trying to say is that the media server MUST
> > return an error code and it SHOULD be 404.
> >
>
> Well I've gone back and forwards on this one.
>
> I actually don't want to mandate the error code that the media server
> returns to the client, I think the media server should return
> whatever error code is appropriate in the circumstance.
>
> As far as mandating whether the media server MUST return an error
> code, well that is implicit in the SIP standard (since returning a
> 200 (OK) response indicates that the media server is ready to stream
> some content, which it clearly isn't), so I wanted to avoid repeating
> that.
>
> What I wanted to stress here was simply that the media server SHOULD
> return an error code that is *appropriate* to the failure (e.g. if
> it's a transient failure, return a transient error code, but if it
> will never work, return a permanent error).
>
> >>   Examples:
> >>
> >>   C: a001 LOGIN anonymous null
> >>   S: a001 OK LOGIN completed.
> >>   C: a002 URLFETCH (
> >>   "imap://[email-masked]/INBOX/;uid=24356/;section=1.2;
> >>   expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
> >>   internal:238234982398239898a9898998798b987s87920"  
> BODYPARTSTRUCTURE
> >>   BINARY )
> >>
> > Please delete the extra space before the closing ')'
> >
> Oops
>
> >>   S: * URLFETCH "imap://[email-masked]/INBOX/;uid=24356/;
> >>   section=1.2;expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
> >>   internal:238234982398239898a9898998798b987s87920"
> >>   (BODYPARTSTRUCTURE ("VIDEO" "MPEG" () NIL NIL "BINARY" 655350 ))
> >>   (BINARY ~{655350}
> >>   S: [ ~655350 octets of binary data, containing NUL octets ])
> >>   S: a002 OK URLFETCH completed.
> >>   C: a003 LOGOUT
> >>   S: a003 OK LOGOUT completed.
> >>
> >
> >
>
>

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

---

From: Eric Burger <[email-masked]>
Date: Fri, 16 May 2008 08:18:02 -0400

In SIP examples, "C:" and "S:" indicate messages sent by the client  
and
  server respectively.  For SIP examples, this document explicitly
  indicates line folding by using a backslash (\) at the end of the
  line.  Line breaks in a C: or S: block do not fold and are part of
  the protocol.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 19 May 2008 11:22:28 +0400

> returns a suitable SIP error code to the client.
I think your suggested text is better.