Dave,
Actually, no... It *should* be using BODYSTRUCTURE to find the media type - by the time you know that section 1.2 (or 1.2.MIME) exists, you already know the media type of the part, and its encoding.Should be: C: a122 UID FETCH 24356 BODY[1.2.MIME] S: * 26 FETCH (BODY[1.2.MIME] {62} S: Content-Transfer-Encoding: base64 S: Content-Type: video/mpeg; S: UID 24356 FLAGS (\Seen)) (i.e. an extra space before "UID" and change "{127}" to "{62}"
3). In section 2.3I'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".Clients SHOULD parse the value of mediaServers, (using either theI would prefer is the order specified by the server is the preferred order.
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 think that might well be neater, although it depends on which extension requires more work.Similarly, the message may well be encoded with a content transferWould it be better if IMAP URL is extended to allow for binary content
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).
fetching?
7). Flow diagrams in section 2.9 don't show IMAP responses. This mightI think it'd be clearer if they were there. (Again, this is FETCH BODY[MIME], rather than FETCH BODYSTRUCTURE).
be Ok.
9). In section 5:
I'm concerned with IPv6 behaviour with this production. I'm also thinking that perhaps a URI form would be more suitable, as it allows for more expansion capability. Assuming, that is, that these media services have URIs to them.I think this should be: ms-tuple = host ":" port [":" "authuser"] as the last component is optional.
10). There is no "IANA Considerations" section. One should be added andThe Metadata annotation registration is in 2.3, but yes, it needs to be moved.
contain text about a METADATA annotation registration, as well as the
registration of new SIP, etc. parameters.
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).
The IMAP base specification, and URLAUTH, also has recommendations concerning encryption layers in conjunction with authorized URLs - you may find it better to simply include the security considerations in both RFC3501 and URLAUTH by reference. Typically, you'd do this with this text replacing the first two paragraphs:
"This document proposes the use of URLAUTH [URLAUTH] "pawn tickets", received over IMAP [IMAP], and transmitted over SIP [SIP], possibly within the MSCML payload of IVR [RFC4722]. As such, the security considerations in all these documents apply to this specification.
In summary, as the authorized URLs may grant access to data, implementors of this specification need to consider the following:
Or something similar, anyway.
That's a good idea. I'll try and wordsmith something similar to that.
Section 4: The Great DRM Can Of Worms:
If I were a lawyer, then aside from the fact I'd never read a technical document, I'd be concerned with the phrase "[...] also implicitly gives the creator [of the URLAUTH authorized URL] the right to pass that reference on to any third party it desires." This phrase implies that the document authors believe that transmission of media via email grants the recipient rights to redistribution, which is probably not the view of most people, DRM- fans or not.
Without delving into the precise legal terminology required, I'd say that the use of URLAUTH in this specification is believed to be persuant with, and used only for, the execution of those rights to be expected when media is sent via traditional internet messaging, and causes no duplication of media content which is not essentially provided by the action of sending the message; that is, the use of the content for downloading and viewing, which *is* implicitly granted by the sender of the message, in as much as the sender has the right to grant such rights.
I might also state that any DRM required needs to be implemented within the media type, and moreover to take into account that the use of this specification requires a third party to access the media content in order to provide efficient private streaming.
I'm very much against implementing DRM checks in URLAUTH, which would require me to maintain a somehow perfect list of media types which require DRM checks, and presumably open my employer to DRM related lawsuits should I fail to comply.
As a final comment, I believe this specification needs careful review by a suitable working group (or groups) within the SIP community - could I suggest that the Chairs, or Secretary, arrange this with the RAI review team, or RAI ADs?
Neil.
_______________________________________________ lemonade mailing list lemonade at ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade