A Framework for the Usage of Internet Media Guides (IMGs)
draft-ietf-mmusic-img-framework-09
Yes
(Jon Peterson)
No Objection
(David Kessens)
(Margaret Cullen)
(Russ Housley)
(Scott Hollenbeck)
Abstain
Note: This ballot was opened for revision 09 and is now closed.
Jon Peterson Former IESG member
Yes
Yes
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
(2005-01-20)
Unknown
Reviewed by Spencer Dawkins, Gen-ART Review copied to comment log; mostly wording comments.
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
(was Discuss)
Abstain
Abstain
(2005-10-19)
Unknown
I still believe that addressing the issue below would be useful, but I have moved to abstain in order that something might get published. Here's the original DISCUSS text: In 5.2.2, the document says: We anticipate that the IMG QUERY-RESOLVE operation will be a trivial usage of HTTP, although other transport protocol options may be beneficial to consider too. This seems contrary to what is said in 5.1.1, where the analysis notes that ANNOUNCE and VERIFY won't work in an HTTP-only environment, and so HTTP is not sufficient for a unicast deployment. If the IMG system is going to use multiple protocols (e.g. HTTP for unicast Query-Resolve, SIP Notify for announce), then there will be a reasonable amount of complexity in determining what to do when the different protocols give answers. I'm also surprised, given that Henning is one of the authors, that the document would believe "layered onto HTTP" meant simple; I'd have thought XCAP would have beaten that notion out of him.