Subject: Re: [lemonade] WGLC streaming

From: Alexey Melnikov <[email-masked]>
Date: Sat, 31 Mar 2007 18:39:23 +0100

Neil Cook wrote:

>> 3). In section 2.3
>>
>>>    Clients SHOULD parse the value of mediaServers, (using either the
>>>    value.priv or value.shared: whichever is available and/or
>>>    appropriate), and contact a media server using one of the supplied
>>>    values.  No particular preference order is implied by the  ordering,
>>
>> I would prefer is the order specified by the server is the  preferred 
>> order.
>
> As Dave mentioned, the client may know better. Perhaps I should that  
> that the server lists the preferred order, but the client may choose  
> to ignore the order if it knows better.

Yes, this is what I want.
I would rather not encourage clients to do stupid things, like random 
selection, when the server has preferences and the client doesn't care.

 [...]

>>>    Similarly, the message may well be encoded with a content transfer
>>>    encoding such as base 64.  However, RFC 4240 does not include a
>>>    method for communicating content transfer encoding to the media
>>>    server as part of the announcement service, nor does the URLFETCH
>>>    command include a mechanism for retrieving message parts without
>>>    encoding (c.f. the BINARY [17] extension to IMAP).
>>
>> Would it be better if IMAP URL is extended to allow for binary content
>> fetching?
>
> Well this is a tricky one. I would actually prefer it if it was,  
> because it means I wouldn't have to extend both netann and mscml with  
> c-t-e parameters. What is the likelihood of getting IMAP URL modified  
> to allow binary fetches?

IMAP URL would be easy, potentially no change at all.
However URLFETCH doesn't currently allow fetching of a bodypart as binary.

>> 5). In section 2.6
>>
>> 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; \
>>   content-transfer-encoding=base64 SIP/2.0
>>
>> A curiosity question: does the content of the play parameter has to be
>> surrounded by '"'?
>
> RFC 4240 says not.

Ok.

 [...]

>>>  However, in this case, if
>>>
>>>   the URL supplied in the 'play' parameter of the SIP INVITE  specifies
>>>   an authorization of 'authuser', then the media server SHOULD NOT
>>>   attempt to contact the IMAP server, but SHOULD instead immediately
>>>   return a response code of 404 to the client with a reason phrase of
>>>   'Not authorized to access resource' reason.
>>
>> 7). Flow diagrams in section 2.9 don't show IMAP responses. This might
>> be Ok.
>
> I tried to leave out non-essential responses in the flow diagrams. If  
> anyone has any strong objection that that, please let me know. They  
> are really just to show overall flow, not show every protocol exchange.

Both Dave and myself are in favor of adding main IMAP responses to the 
diagram.

>> 9). In section 5:
>>
>>>   media-servers = ms-tuple *(";" ms-tuple)
>>>
>>>   host = astring
>>
>> If you mean the RFC 3501 "astring" here, then I don't think this is  
>> what
>> you actually want, as it allows for IMAP literals and quoted strings.
>> I suggest you use "host" non-terminal from RFC 3986. But if you follow
>> this suggestion, be aware that "host" requires that IP addresses be
>> enclosed in '[]'.
>> If you don't want that, you need to find more suitable productions in
>> RFC 3986.
>
> Yes, host from RFC 3986 looks good. However, looks like only IPv6  
> addresses need to be enclosed in [].
>
> BTW, what is the form for including ABNF definitions from other RFCs?  
> Do I just copy the whole set of definitions out, or can I reference  
> them in a standard way?

You reference productions from other RFCs by reference. At the top of 
the ABNF section you mention RFCs that define ABNF productions not 
defined in your document.

>> 10). There is no "IANA Considerations" section. One should be added  and
>> contain text about a METADATA annotation registration, as well as the
>> registration of new SIP, etc. parameters.
>
> Yes, I'll move the METADATA annotation stuff into a separate IANA  
> Considerations section.

You don't need to move all METADATA related text to the IANA section, 
only the registration.
Just try to preserve readability of the document.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 31 Mar 2007 18:27:22 +0100

Neil Cook wrote:

>>> I would prefer is the order specified by the server is the  
>>> preferred order.
>>
>> I'm not sure it matters overmuch. It might be that the client can  
>> identify which server is closest better than the server. It really  
>> depends upon what we mean by "preferred".
>>
>> I think that might well be neater, although it depends on which  
>> extension requires more work.
>>
>> I think it'd be clearer if they were there. (Again, this is FETCH  
>> BODY[MIME], rather than FETCH BODYSTRUCTURE).
>
> I'd be okay with adding the IMAP responses if folks think it would  
> make it clearer. Again, the FETCH BODY[MIME] is just to match with  
> the previous example.

Maybe show both, e.g. in 2 different examples?

> I don't think this document is going to be used  as a guide to writing 
> IMAP clients, or how to retrieve body structure.

You might be surprised :-). IMHO, implementors usually use examples from 
RFCs to write their clients. (Except for Dave, of course ;-))

 [...]

>> The Metadata annotation registration is in 2.3, but yes, it needs  to 
>> be moved.
>>
>> Further comments - and please note that the majority of the SIP  
>> stuff goes shooting over my head:
>>
>> In the Security Considerations section, there seems to be a sudden  
>> lack of references. In particular, sips, SIP, RFC4240, RFC4722, and  
>> S/MIME all lack references (although they're in the Normative  
>> References section).
>
> I have been in somewhat of a quandry about that. Do I reference  
> *everytime* I mention another standard?

Yes, usually you do. At least you do the first time you reference a 
standard.

Note that references that are not essential for implementing an RFC are 
put into the Informative References section.

> I got the feeling that by the  end of the doc, if various protocols 
> have been referenced enough,  they probably don't need any more, but 
> I'd be happy to be corrected  on that. Obviously any in that section 
> which haven't been referenced  before should be referenced.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 03 Apr 2007 12:18:32 +0100

On Sat Mar 31 18:27:22 2007, Alexey Melnikov wrote:
> You might be surprised :-). IMHO, implementors usually use examples 
> from RFCs to write their clients. (Except for Dave, of course ;-))

I certainly use the examples more than the text for figuring out the 
overall concepts.

When I read the example with the BODY[1.2.MIME] fetch, I spent a long 
time reading through the text trying to figure out what the client 
needed that wasn't in BODYSTRUCTURE, assuming there must have been 
something forcing the MIME header fetch.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 23 Apr 2007 16:39:25 -0700

The Security Considerations section is a special section.  There are
quite a few people that will review the Security Considerations section
first, and then give a cursory glance over the rest of the document.
For example, we ask the security directorate to review the document.
You can guess where they are going to look first.

Thus it is a good idea when writing your security considerations that
you include explanatory text and references, as if it was an
introduction.

This is a bit like the passive voice issue discussed elsewhere.  When we
write a document, we think of it as a whole, from front to back.  When
we write the security considerations section, it is often after we have
written everything else.  Thus we are thinking of the security
considerations section in the context of the whole document, read last.
However, given we know there are constituencies that will read the
document starting with the security considerations section, we need to
go out of our way to make it stand on its own. 

-----Original Message-----
From: Neil Cook [mailto:[email-masked]] 
Sent: Thursday, March 29, 2007 10:18 AM
To: Dave Cridland
Cc: Enhancements to Internet email to support diverse service
enivronments
Subject: Re: [lemonade] WGLC streaming

[snip]

I have been in somewhat of a quandry about that. Do I reference
*everytime* I mention another standard? I got the feeling that by the
end of the doc, if various protocols have been referenced enough, they
probably don't need any more, but I'd be happy to be corrected on that.
Obviously any in that section which haven't been referenced before
should be referenced.
[snip]

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.

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 23 Apr 2007 16:39:25 -0700

-----Original Message-----
From: Neil Cook [mailto:[email-masked]] 
Sent: Thursday, March 29, 2007 10:18 AM
To: Dave Cridland
Cc: Enhancements to Internet email to support diverse service
enivronments

[snip]